Hi,
pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
is written to the device is lost after umount.
I rarely use pktcdvd but at some point it used to work on my system.
This is what I'm doing:
root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
using device /dev/scd0
1029KB internal buffer
setting write speed to 12x
Settings for /dev/scd0:
Fixed packets, size 32
Mode-2 disc
I'm going to do a quick setup of /dev/scd0. The disc is going to be
blanked and formatted with one big track. All data on the device will be
lost!! Press CTRL-C to cancel now.
ENTER to continue.
Initiating quick disc blank
Disc capacity is 275616 blocks (551232KB/538MB)
Formatting track
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=31, type=USPACE
start=288, blocks=32, type=PVDS
start=320, blocks=32, type=LVID
start=352, blocks=32, type=STABLE
start=384, blocks=1024, type=SSPACE
start=1408, blocks=273920, type=PSPACE
start=275328, blocks=31, type=USPACE
start=275359, blocks=1, type=ANCHOR
start=275360, blocks=160, type=USPACE
start=275520, blocks=32, type=STABLE
start=275552, blocks=32, type=RVDS
start=275584, blocks=31, type=USPACE
start=275615, blocks=1, type=ANCHOR
Writing UDF structures to disc
Quick setup complete!
root@dreamland:/tmp# pktsetup pkt0 /dev/scd0
pktcdvd: writer pktcdvd0 mapped to sr0
root@dreamland:/tmp# mount -t udf -o rw,noatime /dev/pktcdvd/pkt0 /cdrom
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 0kB available on disc
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
root@dreamland:/tmp# touch /cdrom/test
root@dreamland:/tmp# ll /cdrom
total 0
drwxr-xr-x 2 root root 40 2007-01-30 18:18 lost+found
-rw-r--r-- 1 root root 0 2007-01-30 20:42 test
root@dreamland:/tmp# umount /cdrom
root@dreamland:/tmp# mount -t udf -o rw,noatime /dev/pktcdvd/pkt0 /cdrom
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 0kB available on disc
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
root@dreamland:/tmp# ll /cdrom
total 0
drwxr-xr-x 2 root root 40 2007-01-30 18:18 lost+found
As you can see the file is gone. Also notice that pktcdvd says:
pktcdvd: 0kB available on disc
which sounds very strange. The drive is this one:
scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
The disk:
root@dreamland:/tmp# cdrwtool -d /dev/scd0 -i
using device /dev/scd0
1029KB internal buffer
setting write speed to 12x
DISC INFO:
erasable : Yes
border = 3
Disc status = 2
number of first track = 1
number of sessions = 1
number of tracks = 1
status of last track = 1
uru = 0
did_v = 1
dbc_v = 0
disc type = 32
disc_id = 9773913
lead_in = 255:255:255 (1166880)
lead_out = 255:255:255 (1166880)
OPC entries = 0
TRACK INFO:
Track 1
track_number = 1
session_number = 1
damage = 0
copy = 0
track_mode = 7
Rt = 1
blank = 0
packet = 1
fp = 1
data_mode = 2
lra_v = 0
nwa_v = 0
track_start = 0
next_writable = 0
last_recorded = 0
free_blocks = 0
packet_size = 32
track_size = 275616 (551232KB)
I've tried different media with the same result. Furthermore I can
correctly write an ISO9660 fs on these cdrw disks.
Luca
--
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!
On Jan 30 2007 20:53, Luca Tettamanti wrote:
>Hi,
>pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
Did it work previously?
>is written to the device is lost after umount.
>I rarely use pktcdvd but at some point it used to work on my system.
>
>This is what I'm doing:
>
>root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
>scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
In case you are using ide-scsi: try without.
Jan
--
Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
>
> On Jan 30 2007 20:53, Luca Tettamanti wrote:
> >Hi,
> >pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
>
> Did it work previously?
Yup, It used to work but since I rarely use it I don't remember which
kernel version worked for me.
>
> >is written to the device is lost after umount.
> >I rarely use pktcdvd but at some point it used to work on my system.
> >
> >This is what I'm doing:
> >
> >root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> >scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
>
> In case you are using ide-scsi: try without.
It's libata jmicron driver. Shall I try the "old" PATA driver on the
next reboot?
Luca
--
"Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi"
Sun Tzu -- L'arte della guerra
On Jan 30 2007 21:36, Luca Tettamanti wrote:
>Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
>>
>> On Jan 30 2007 20:53, Luca Tettamanti wrote:
>> >Hi,
>> >pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
>>
>> Did it work previously?
>
>Yup, It used to work but since I rarely use it I don't remember which
>kernel version worked for me.
Hm, maybe you can take a guess.
>> >is written to the device is lost after umount.
>> >I rarely use pktcdvd but at some point it used to work on my system.
>> >
>> >This is what I'm doing:
>> >
>> >root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
>> >scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
>>
>> In case you are using ide-scsi: try without.
>
>It's libata jmicron driver. Shall I try the "old" PATA driver on the
>next reboot?
If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
welcome.
Jan
--
Hi Jeff, linux-ide,
I'm having troubles with libata and UDF on RW media. See below.
Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> On Jan 30 2007 21:36, Luca Tettamanti wrote:
> >Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
> >>
> >> On Jan 30 2007 20:53, Luca Tettamanti wrote:
> >> >Hi,
> >> >pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> >>
> >> Did it work previously?
> >
> >Yup, It used to work but since I rarely use it I don't remember which
> >kernel version worked for me.
>
> Hm, maybe you can take a guess.
I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
> >> >is written to the device is lost after umount.
> >> >I rarely use pktcdvd but at some point it used to work on my system.
> >> >
> >> >This is what I'm doing:
> >> >
> >> >root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> >> >scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
> >>
> >> In case you are using ide-scsi: try without.
> >
> >It's libata jmicron driver. Shall I try the "old" PATA driver on the
> >next reboot?
>
> If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
> welcome.
With the legacy IDE driver it works fine.
The unit is DVD-RAM capable so the firmware should handle random writes
fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
lose files. So I guess it has something to do with libata.
So to recap, after formatting the disk with UDF:
* libata
- mount with pktcdvd: all files are lost upon umount
- mount scd0 w/out pktcdvd: all files are lost upon umount
- write the disk with cdrecord: OK
pktcdvd reports wrong capacity:
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 0kB available on disc
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
* legacy IDE driver
- mount with pktcdvd: OK
- mount hda w/out pktcdvd: corrupts FS (duh)
- write the disk with cdrecord: OK
pktcdvd reports correct capacity:
pktcdvd: writer pktcdvd0 mapped to hda
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 551232kB available on disc
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 22:19 (103c)
The HW is a JMicron controller:
02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
(one of the 2 has PATA ports)
driven either by libata (CONFIG_PATA_JMICRON):
PCI: Enabling device 0000:02:00.1 (0000 -> 0001)
ACPI: PCI Interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:02:00.1 to 64
ata9: PATA max UDMA/100 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 19
ata10: PATA max UDMA/100 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 19
scsi8 : pata_jmicron
ata9.00: ATAPI, max UDMA/33
ata9.01: ATAPI, max UDMA/33
ata9.00: configured for UDMA/33
ata9.01: configured for UDMA/33
scsi9 : pata_jmicron
ATA: abnormal status 0x7F on port 0xA807
scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 8:0:0:0: Attached scsi CD-ROM sr0
sr 8:0:0:0: Attached scsi generic sg1 type 5
scsi 8:0:1:0: CD-ROM WAITEC ALADAR/1 B1.5 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 16x/40x writer cd/rw xa/form2 cdda tray
sr 8:0:1:0: Attached scsi CD-ROM sr1
sr 8:0:1:0: Attached scsi generic sg2 type 5
or by the legacy driver (CONFIG_BLK_DEV_JMICRON):
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
JMB361: IDE controller at PCI slot 0000:02:00.1
PCI: Enabling device 0000:02:00.1 (0000 -> 0001)
ACPI: PCI Interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 18
JMB361: chipset revision 2
JMB361: 100% native mode on irq 18
PCI: Setting latency timer of device 0000:02:00.1 to 64
ide0: BM-DMA at 0xa400-0xa407, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xa408-0xa40f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4167B, ATAPI CD/DVD-ROM drive
hdb: WAITEC ALADAR/1, ATAPI CD/DVD-ROM drive
ide0 at 0xac00-0xac07,0xa882 on irq 18
Probing IDE interface ide1...
JMB361: IDE controller at PCI slot 0000:02:00.0
PCI: Device 0000:02:00.0 not available because of resource collisions
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
JMB361: BIOS configuration fixed.
JMB361: chipset revision 2
JMB361: 100% native mode on irq 16
JMB361: dma_base is invalid
ide2: JMB361 Bus-Master DMA disabled (BIOS)
JMB361: dma_base is invalid
ide3: JMB361 Bus-Master DMA disabled (BIOS)
Probing IDE interface ide2...
Probing IDE interface ide3...
ALI15X3: IDE controller at PCI slot 0000:05:02.1
ACPI: PCI Interrupt 0000:05:02.1[A] -> GSI 23 (level, low) -> IRQ 19
ALI15X3: chipset revision 198
ALI15X3: 100% native mode on irq 19
ALI15X3: too many IDE interfaces, no room in table
ALI15X3: too many IDE interfaces, no room in table
(hum, must increase MAX_HWIF)
ALI15X3: neither IDE port enabled (BIOS)
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
Luca
--
Not an editor command: Wq
Luca Tettamanti wrote:
> Hi Jeff, linux-ide,
> I'm having troubles with libata and UDF on RW media. See below.
>
> Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
>> On Jan 30 2007 21:36, Luca Tettamanti wrote:
>>> Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
>>>> On Jan 30 2007 20:53, Luca Tettamanti wrote:
>>>>> Hi,
>>>>> pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
>>>> Did it work previously?
>>> Yup, It used to work but since I rarely use it I don't remember which
>>> kernel version worked for me.
>> Hm, maybe you can take a guess.
>
> I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
>
>>>>> is written to the device is lost after umount.
>>>>> I rarely use pktcdvd but at some point it used to work on my system.
>>>>>
>>>>> This is what I'm doing:
>>>>>
>>>>> root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
>>>>> scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
>>>> In case you are using ide-scsi: try without.
>>> It's libata jmicron driver. Shall I try the "old" PATA driver on the
>>> next reboot?
>> If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
>> welcome.
>
> With the legacy IDE driver it works fine.
> The unit is DVD-RAM capable so the firmware should handle random writes
> fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
> lose files. So I guess it has something to do with libata.
>
> So to recap, after formatting the disk with UDF:
>
> * libata
> - mount with pktcdvd: all files are lost upon umount
> - mount scd0 w/out pktcdvd: all files are lost upon umount
> - write the disk with cdrecord: OK
>
> pktcdvd reports wrong capacity:
>
> pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> pktcdvd: Max. media speed: 4
> pktcdvd: write speed 4x
> pktcdvd: 0kB available on disc
> UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
>
> * legacy IDE driver
> - mount with pktcdvd: OK
> - mount hda w/out pktcdvd: corrupts FS (duh)
> - write the disk with cdrecord: OK
>
> pktcdvd reports correct capacity:
>
> pktcdvd: writer pktcdvd0 mapped to hda
> pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> pktcdvd: Max. media speed: 4
> pktcdvd: write speed 4x
> pktcdvd: 551232kB available on disc
> UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 22:19 (103c)
>
> The HW is a JMicron controller:
> 02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
> 02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
hmmm, definitely interesting behavior.
Would you mind putting this info into a bugzilla.kernel.org report, so
that it is not lost? This bug will likely go into a heavy ATAPI
debugging session that is coming in a few weeks, but not immediately :/
Jeff
Hi all.
I don't know if this report can be useful, but this problem does not
show up in my setup.
I tried multiple times to copy 10MB files (unmounting and remounting
every time) and verified with md5sum the results and everything is
correct.
Details:
* kernel version: 2.6.20-rc6-g93544047
* driver: ata_piix (only a PATA hard disk and a DVD writer)
* writer: TSSTcorp CD/DVDW TS-L532M HR08 PQ: 0 ANSI: 5).
* udftools version: udftools-1.0.0b3-7.fc6
Regards,
Fabio
On 1/31/07, Jeff Garzik <[email protected]> wrote:
> Luca Tettamanti wrote:
> > Hi Jeff, linux-ide,
> > I'm having troubles with libata and UDF on RW media. See below.
> >
> > Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> >> On Jan 30 2007 21:36, Luca Tettamanti wrote:
> >>> Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
> >>>> On Jan 30 2007 20:53, Luca Tettamanti wrote:
> >>>>> Hi,
> >>>>> pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> >>>> Did it work previously?
> >>> Yup, It used to work but since I rarely use it I don't remember which
> >>> kernel version worked for me.
> >> Hm, maybe you can take a guess.
> >
> > I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
> >
> >>>>> is written to the device is lost after umount.
> >>>>> I rarely use pktcdvd but at some point it used to work on my system.
> >>>>>
> >>>>> This is what I'm doing:
> >>>>>
> >>>>> root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> >>>>> scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
> >>>> In case you are using ide-scsi: try without.
> >>> It's libata jmicron driver. Shall I try the "old" PATA driver on the
> >>> next reboot?
> >> If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
> >> welcome.
> >
> > With the legacy IDE driver it works fine.
> > The unit is DVD-RAM capable so the firmware should handle random writes
> > fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
> > lose files. So I guess it has something to do with libata.
> >
> > So to recap, after formatting the disk with UDF:
> >
> > * libata
> > - mount with pktcdvd: all files are lost upon umount
> > - mount scd0 w/out pktcdvd: all files are lost upon umount
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports wrong capacity:
> >
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 0kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
> >
> > * legacy IDE driver
> > - mount with pktcdvd: OK
> > - mount hda w/out pktcdvd: corrupts FS (duh)
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports correct capacity:
> >
> > pktcdvd: writer pktcdvd0 mapped to hda
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 551232kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 22:19 (103c)
> >
> > The HW is a JMicron controller:
> > 02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
> > 02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
>
> hmmm, definitely interesting behavior.
>
> Would you mind putting this info into a bugzilla.kernel.org report, so
> that it is not lost? This bug will likely go into a heavy ATAPI
> debugging session that is coming in a few weeks, but not immediately :/
>
> Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 1/31/07, Jeff Garzik <[email protected]> wrote:
> Luca Tettamanti wrote:
> > Hi Jeff, linux-ide,
> > I'm having troubles with libata and UDF on RW media. See below.
> >
> > Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> >> On Jan 30 2007 21:36, Luca Tettamanti wrote:
> >>> Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
> >>>> On Jan 30 2007 20:53, Luca Tettamanti wrote:
> >>>>> Hi,
> >>>>> pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> >>>> Did it work previously?
> >>> Yup, It used to work but since I rarely use it I don't remember which
> >>> kernel version worked for me.
> >> Hm, maybe you can take a guess.
> >
> > I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
> >
> >>>>> is written to the device is lost after umount.
> >>>>> I rarely use pktcdvd but at some point it used to work on my system.
> >>>>>
> >>>>> This is what I'm doing:
> >>>>>
> >>>>> root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> >>>>> scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
> >>>> In case you are using ide-scsi: try without.
> >>> It's libata jmicron driver. Shall I try the "old" PATA driver on the
> >>> next reboot?
> >> If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
> >> welcome.
> >
> > With the legacy IDE driver it works fine.
> > The unit is DVD-RAM capable so the firmware should handle random writes
> > fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
> > lose files. So I guess it has something to do with libata.
> >
> > So to recap, after formatting the disk with UDF:
> >
> > * libata
> > - mount with pktcdvd: all files are lost upon umount
> > - mount scd0 w/out pktcdvd: all files are lost upon umount
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports wrong capacity:
> >
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 0kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c)
> >
> > * legacy IDE driver
> > - mount with pktcdvd: OK
> > - mount hda w/out pktcdvd: corrupts FS (duh)
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports correct capacity:
> >
> > pktcdvd: writer pktcdvd0 mapped to hda
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 551232kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 22:19 (103c)
> >
> > The HW is a JMicron controller:
> > 02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
> > 02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
>
> hmmm, definitely interesting behavior.
>
> Would you mind putting this info into a bugzilla.kernel.org report, so
> that it is not lost?
Done, ID is 7910.
Luca
On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
> Luca Tettamanti wrote:
> >Hi Jeff, linux-ide,
> >I'm having troubles with libata and UDF on RW media. See below.
> >
> >Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> >>On Jan 30 2007 21:36, Luca Tettamanti wrote:
> >>>Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
> >>>>On Jan 30 2007 20:53, Luca Tettamanti wrote:
> >>>>>Hi,
> >>>>>pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> >>>>Did it work previously?
> >>>Yup, It used to work but since I rarely use it I don't remember which
> >>>kernel version worked for me.
> >>Hm, maybe you can take a guess.
> >
> >I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
> >
> >>>>>is written to the device is lost after umount.
> >>>>>I rarely use pktcdvd but at some point it used to work on my system.
> >>>>>
> >>>>>This is what I'm doing:
> >>>>>
> >>>>>root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> >>>>>scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0
> >>>>>ANSI: 5
> >>>>In case you are using ide-scsi: try without.
> >>>It's libata jmicron driver. Shall I try the "old" PATA driver on the
> >>>next reboot?
> >>If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
> >>welcome.
> >
> >With the legacy IDE driver it works fine.
> >The unit is DVD-RAM capable so the firmware should handle random writes
> >fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
> >lose files. So I guess it has something to do with libata.
> >
> >So to recap, after formatting the disk with UDF:
> >
> >* libata
> > - mount with pktcdvd: all files are lost upon umount
> > - mount scd0 w/out pktcdvd: all files are lost upon umount
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports wrong capacity:
> >
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 0kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF',
> > timestamp 2007/01/30 18:18 (103c)
> >
> >* legacy IDE driver
> > - mount with pktcdvd: OK
> > - mount hda w/out pktcdvd: corrupts FS (duh)
> > - write the disk with cdrecord: OK
> >
> > pktcdvd reports correct capacity:
> >
> > pktcdvd: writer pktcdvd0 mapped to hda
> > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > pktcdvd: Max. media speed: 4
> > pktcdvd: write speed 4x
> > pktcdvd: 551232kB available on disc
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF',
> > timestamp 2007/01/30 22:19 (103c)
> >
> >The HW is a JMicron controller:
> >02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
> >Controller (rev 02)
> >02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
> >Controller (rev 02)
>
> hmmm, definitely interesting behavior.
>
> Would you mind putting this info into a bugzilla.kernel.org report, so
> that it is not lost? This bug will likely go into a heavy ATAPI
> debugging session that is coming in a few weeks, but not immediately :/
Is this related to #7810 (which is caused by Christoph's patches) or is
this issue another 2.6.20-rc pktcdvd regression?
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> Hi,
> pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> is written to the device is lost after umount.
> I rarely use pktcdvd but at some point it used to work on my system.
>
> This is what I'm doing:
>
> root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> using device /dev/scd0
> 1029KB internal buffer
> setting write speed to 12x
> Settings for /dev/scd0:
> Fixed packets, size 32
> Mode-2 disc
>...
Does 2.6.20-rc7 work?
If no, does it work after applying the attached patch?
If no, does 2.6.19.2 work?
> Luca
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
Il Thu, Feb 01, 2007 at 12:10:13AM +0100, Adrian Bunk ha scritto:
> On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
> > Luca Tettamanti wrote:
> > >Hi Jeff, linux-ide,
> > >I'm having troubles with libata and UDF on RW media. See below.
> > >
> > >Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
> > >>On Jan 30 2007 21:36, Luca Tettamanti wrote:
> > >>>Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
> > >>>>On Jan 30 2007 20:53, Luca Tettamanti wrote:
> > >>>>>Hi,
> > >>>>>pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > >>>>Did it work previously?
> > >>>Yup, It used to work but since I rarely use it I don't remember which
> > >>>kernel version worked for me.
> > >>Hm, maybe you can take a guess.
> > >
> > >I can bisect pktcdvd.c if necessary, but it seems that it's innocent.
> > >
> > >>>>>is written to the device is lost after umount.
> > >>>>>I rarely use pktcdvd but at some point it used to work on my system.
> > >>>>>
> > >>>>>This is what I'm doing:
> > >>>>>
> > >>>>>root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > >>>>>scsi 8:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0
> > >>>>>ANSI: 5
> > >>>>In case you are using ide-scsi: try without.
> > >>>It's libata jmicron driver. Shall I try the "old" PATA driver on the
> > >>>next reboot?
> > >>If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is
> > >>welcome.
> > >
> > >With the legacy IDE driver it works fine.
> > >The unit is DVD-RAM capable so the firmware should handle random writes
> > >fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still
> > >lose files. So I guess it has something to do with libata.
> > >
> > >So to recap, after formatting the disk with UDF:
> > >
> > >* libata
> > > - mount with pktcdvd: all files are lost upon umount
> > > - mount scd0 w/out pktcdvd: all files are lost upon umount
> > > - write the disk with cdrecord: OK
> > >
> > > pktcdvd reports wrong capacity:
> > >
> > > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > > pktcdvd: Max. media speed: 4
> > > pktcdvd: write speed 4x
> > > pktcdvd: 0kB available on disc
> > > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF',
> > > timestamp 2007/01/30 18:18 (103c)
> > >
> > >* legacy IDE driver
> > > - mount with pktcdvd: OK
> > > - mount hda w/out pktcdvd: corrupts FS (duh)
> > > - write the disk with cdrecord: OK
> > >
> > > pktcdvd reports correct capacity:
> > >
> > > pktcdvd: writer pktcdvd0 mapped to hda
> > > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > > pktcdvd: Max. media speed: 4
> > > pktcdvd: write speed 4x
> > > pktcdvd: 551232kB available on disc
> > > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF',
> > > timestamp 2007/01/30 22:19 (103c)
> > >
> > >The HW is a JMicron controller:
> > >02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
> > >Controller (rev 02)
> > >02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
> > >Controller (rev 02)
> >
> > hmmm, definitely interesting behavior.
> >
> > Would you mind putting this info into a bugzilla.kernel.org report, so
> > that it is not lost? This bug will likely go into a heavy ATAPI
> > debugging session that is coming in a few weeks, but not immediately :/
>
> Is this related to #7810 (which is caused by Christoph's patches) or is
> this issue another 2.6.20-rc pktcdvd regression?
To me it looks unrelated to #7810. In my case files are "written" to the
disk but they disappear after umount, I don't get any OOPS (nothing at
all in the log).
I'm not sure it's a regression either. As I said I rarely use pktcdvd,
it's possible that the last time I used it I still had the old
motherboard with VIA IDE controller.
Luca
--
Software is like sex; it's better when it's free.
Linus Torvalds
Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > Hi,
> > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > is written to the device is lost after umount.
> > I rarely use pktcdvd but at some point it used to work on my system.
> >
> > This is what I'm doing:
> >
> > root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > using device /dev/scd0
> > 1029KB internal buffer
> > setting write speed to 12x
> > Settings for /dev/scd0:
> > Fixed packets, size 32
> > Mode-2 disc
> >...
>
> Does 2.6.20-rc7 work?
> If no, does it work after applying the attached patch?
> If no, does 2.6.19.2 work?
Git current + the following patch works.
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index 6246219..7c95c76 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct bio **list_head, struct bio
> */
> static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *cgc)
> {
> - request_queue_t *q = bdev_get_queue(pd->bdev);
> + char sense[SCSI_SENSE_BUFFERSIZE];
> + request_queue_t *q;
> struct request *rq;
> - int ret = 0;
> -
> - rq = blk_get_request(q, (cgc->data_direction == CGC_DATA_WRITE) ?
> - WRITE : READ, __GFP_WAIT);
> -
> - if (cgc->buflen) {
> - if (blk_rq_map_kern(q, rq, cgc->buffer, cgc->buflen, __GFP_WAIT))
> - goto out;
> - }
> + DECLARE_COMPLETION_ONSTACK(wait);
> + int err = 0;
>
> - rq->cmd_len = COMMAND_SIZE(rq->cmd[0]);
> - memcpy(rq->cmd, cgc->cmd, CDROM_PACKET_SIZE);
> - if (sizeof(rq->cmd) > CDROM_PACKET_SIZE)
> - memset(rq->cmd + CDROM_PACKET_SIZE, 0, sizeof(rq->cmd) - CDROM_PACKET_SIZE);
> + q = bdev_get_queue(pd->bdev);
>
> + rq = blk_get_request(q, (cgc->data_direction == CGC_DATA_WRITE) ? WRITE : READ,
> + __GFP_WAIT);
> + rq->errors = 0;
> + rq->rq_disk = pd->bdev->bd_disk;
> + rq->bio = NULL;
> + rq->buffer = NULL;
> rq->timeout = 60*HZ;
> + rq->data = cgc->buffer;
> + rq->data_len = cgc->buflen;
> + rq->sense = sense;
> + memset(sense, 0, sizeof(sense));
> + rq->sense_len = 0;
> rq->cmd_type = REQ_TYPE_BLOCK_PC;
> rq->cmd_flags |= REQ_HARDBARRIER;
> if (cgc->quiet)
> rq->cmd_flags |= REQ_QUIET;
> + memcpy(rq->cmd, cgc->cmd, CDROM_PACKET_SIZE);
> + if (sizeof(rq->cmd) > CDROM_PACKET_SIZE)
> + memset(rq->cmd + CDROM_PACKET_SIZE, 0, sizeof(rq->cmd) - CDROM_PACKET_SIZE);
> + rq->cmd_len = COMMAND_SIZE(rq->cmd[0]);
> +
> + rq->ref_count++;
> + rq->end_io_data = &wait;
> + rq->end_io = blk_end_sync_rq;
> + elv_add_request(q, rq, ELEVATOR_INSERT_BACK, 1);
> + generic_unplug_device(q);
> + wait_for_completion(&wait);
> +
> + if (rq->errors)
> + err = -EIO;
>
> - blk_execute_rq(rq->q, pd->bdev->bd_disk, rq, 0);
> - ret = rq->errors;
> -out:
> blk_put_request(rq);
> - return ret;
> + return err;
> }
>
> /*
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f02f48a..6fe1e82 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -998,14 +998,25 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
> int count;
>
> /*
> - * We used to not use scatter-gather for single segment request,
> + * if this is a rq->data based REQ_BLOCK_PC, setup for a non-sg xfer
> + */
> + if (blk_pc_request(req) && !req->bio) {
> + cmd->request_bufflen = req->data_len;
> + cmd->request_buffer = req->data;
> + req->buffer = req->data;
> + cmd->use_sg = 0;
> + return 0;
> + }
> +
> + /*
> + * we used to not use scatter-gather for single segment request,
> * but now we do (it makes highmem I/O easier to support without
> * kmapping pages)
> */
> cmd->use_sg = req->nr_phys_segments;
>
> /*
> - * If sg table allocation fails, requeue request later.
> + * if sg table allocation fails, requeue request later.
> */
> sgpnt = scsi_alloc_sgtable(cmd, GFP_ATOMIC);
> if (unlikely(!sgpnt)) {
> @@ -1013,21 +1024,24 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
> return BLKPREP_DEFER;
> }
>
> - req->buffer = NULL;
> cmd->request_buffer = (char *) sgpnt;
> + cmd->request_bufflen = req->nr_sectors << 9;
> if (blk_pc_request(req))
> cmd->request_bufflen = req->data_len;
> - else
> - cmd->request_bufflen = req->nr_sectors << 9;
> + req->buffer = NULL;
>
> /*
> * Next, walk the list, and fill in the addresses and sizes of
> * each segment.
> */
> count = blk_rq_map_sg(req->q, req, cmd->request_buffer);
> +
> + /*
> + * mapped well, send it off
> + */
> if (likely(count <= cmd->use_sg)) {
> cmd->use_sg = count;
> - return BLKPREP_OK;
> + return 0;
> }
>
> printk(KERN_ERR "Incorrect number of segments after building list\n");
> @@ -1057,27 +1071,6 @@ static int scsi_issue_flush_fn(request_queue_t *q, struct gendisk *disk,
> return -EOPNOTSUPP;
> }
>
> -static struct scsi_cmnd *scsi_get_cmd_from_req(struct scsi_device *sdev,
> - struct request *req)
> -{
> - struct scsi_cmnd *cmd;
> -
> - if (!req->special) {
> - cmd = scsi_get_command(sdev, GFP_ATOMIC);
> - if (unlikely(!cmd))
> - return NULL;
> - req->special = cmd;
> - } else {
> - cmd = req->special;
> - }
> -
> - /* pull a tag out of the request if we have one */
> - cmd->tag = req->tag;
> - cmd->request = req;
> -
> - return cmd;
> -}
> -
> static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
> {
> BUG_ON(!blk_pc_request(cmd->request));
> @@ -1090,37 +1083,9 @@ static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
> scsi_io_completion(cmd, cmd->request_bufflen);
> }
>
> -static int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
> +static void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd)
> {
> - struct scsi_cmnd *cmd;
> -
> - cmd = scsi_get_cmd_from_req(sdev, req);
> - if (unlikely(!cmd))
> - return BLKPREP_DEFER;
> -
> - /*
> - * BLOCK_PC requests may transfer data, in which case they must
> - * a bio attached to them. Or they might contain a SCSI command
> - * that does not transfer data, in which case they may optionally
> - * submit a request without an attached bio.
> - */
> - if (req->bio) {
> - int ret;
> -
> - BUG_ON(!req->nr_phys_segments);
> -
> - ret = scsi_init_io(cmd);
> - if (unlikely(ret))
> - return ret;
> - } else {
> - BUG_ON(req->data_len);
> - BUG_ON(req->data);
> -
> - cmd->request_bufflen = 0;
> - cmd->request_buffer = NULL;
> - cmd->use_sg = 0;
> - req->buffer = NULL;
> - }
> + struct request *req = cmd->request;
>
> BUILD_BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
> memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
> @@ -1136,138 +1101,154 @@ static int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
> cmd->allowed = req->retries;
> cmd->timeout_per_command = req->timeout;
> cmd->done = scsi_blk_pc_done;
> - return BLKPREP_OK;
> -}
> -
> -/*
> - * Setup a REQ_TYPE_FS command. These are simple read/write request
> - * from filesystems that still need to be translated to SCSI CDBs from
> - * the ULD.
> - */
> -static int scsi_setup_fs_cmnd(struct scsi_device *sdev, struct request *req)
> -{
> - struct scsi_cmnd *cmd;
> - struct scsi_driver *drv;
> - int ret;
> -
> - /*
> - * Filesystem requests must transfer data.
> - */
> - BUG_ON(!req->nr_phys_segments);
> -
> - cmd = scsi_get_cmd_from_req(sdev, req);
> - if (unlikely(!cmd))
> - return BLKPREP_DEFER;
> -
> - ret = scsi_init_io(cmd);
> - if (unlikely(ret))
> - return ret;
> -
> - /*
> - * Initialize the actual SCSI command for this request.
> - */
> - drv = *(struct scsi_driver **)req->rq_disk->private_data;
> - if (unlikely(!drv->init_command(cmd))) {
> - scsi_release_buffers(cmd);
> - scsi_put_command(cmd);
> - return BLKPREP_KILL;
> - }
> -
> - return BLKPREP_OK;
> }
>
> static int scsi_prep_fn(struct request_queue *q, struct request *req)
> {
> struct scsi_device *sdev = q->queuedata;
> - int ret = BLKPREP_OK;
> + struct scsi_cmnd *cmd;
> + int specials_only = 0;
>
> /*
> - * If the device is not in running state we will reject some
> - * or all commands.
> + * Just check to see if the device is online. If it isn't, we
> + * refuse to process any commands. The device must be brought
> + * online before trying any recovery commands
> */
> + if (unlikely(!scsi_device_online(sdev))) {
> + sdev_printk(KERN_ERR, sdev,
> + "rejecting I/O to offline device\n");
> + goto kill;
> + }
> if (unlikely(sdev->sdev_state != SDEV_RUNNING)) {
> - switch (sdev->sdev_state) {
> - case SDEV_OFFLINE:
> - /*
> - * If the device is offline we refuse to process any
> - * commands. The device must be brought online
> - * before trying any recovery commands.
> - */
> - sdev_printk(KERN_ERR, sdev,
> - "rejecting I/O to offline device\n");
> - ret = BLKPREP_KILL;
> - break;
> - case SDEV_DEL:
> - /*
> - * If the device is fully deleted, we refuse to
> - * process any commands as well.
> - */
> + /* OK, we're not in a running state don't prep
> + * user commands */
> + if (sdev->sdev_state == SDEV_DEL) {
> + /* Device is fully deleted, no commands
> + * at all allowed down */
> sdev_printk(KERN_ERR, sdev,
> "rejecting I/O to dead device\n");
> - ret = BLKPREP_KILL;
> - break;
> - case SDEV_QUIESCE:
> - case SDEV_BLOCK:
> - /*
> - * If the devices is blocked we defer normal commands.
> - */
> - if (!(req->cmd_flags & REQ_PREEMPT))
> - ret = BLKPREP_DEFER;
> - break;
> - default:
> - /*
> - * For any other not fully online state we only allow
> - * special commands. In particular any user initiated
> - * command is not allowed.
> - */
> - if (!(req->cmd_flags & REQ_PREEMPT))
> - ret = BLKPREP_KILL;
> - break;
> + goto kill;
> }
> -
> - if (ret != BLKPREP_OK)
> - goto out;
> + /* OK, we only allow special commands (i.e. not
> + * user initiated ones */
> + specials_only = sdev->sdev_state;
> }
>
> - switch (req->cmd_type) {
> - case REQ_TYPE_BLOCK_PC:
> - ret = scsi_setup_blk_pc_cmnd(sdev, req);
> - break;
> - case REQ_TYPE_FS:
> - ret = scsi_setup_fs_cmnd(sdev, req);
> - break;
> - default:
> + /*
> + * Find the actual device driver associated with this command.
> + * The SPECIAL requests are things like character device or
> + * ioctls, which did not originate from ll_rw_blk. Note that
> + * the special field is also used to indicate the cmd for
> + * the remainder of a partially fulfilled request that can
> + * come up when there is a medium error. We have to treat
> + * these two cases differently. We differentiate by looking
> + * at request->cmd, as this tells us the real story.
> + */
> + if (blk_special_request(req) && req->special)
> + cmd = req->special;
> + else if (blk_pc_request(req) || blk_fs_request(req)) {
> + if (unlikely(specials_only) && !(req->cmd_flags & REQ_PREEMPT)){
> + if (specials_only == SDEV_QUIESCE ||
> + specials_only == SDEV_BLOCK)
> + goto defer;
> +
> + sdev_printk(KERN_ERR, sdev,
> + "rejecting I/O to device being removed\n");
> + goto kill;
> + }
> +
> /*
> - * All other command types are not supported.
> - *
> - * Note that these days the SCSI subsystem does not use
> - * REQ_TYPE_SPECIAL requests anymore. These are only used
> - * (directly or via blk_insert_request) by non-SCSI drivers.
> + * Now try and find a command block that we can use.
> */
> + if (!req->special) {
> + cmd = scsi_get_command(sdev, GFP_ATOMIC);
> + if (unlikely(!cmd))
> + goto defer;
> + } else
> + cmd = req->special;
> +
> + /* pull a tag out of the request if we have one */
> + cmd->tag = req->tag;
> + } else {
> blk_dump_rq_flags(req, "SCSI bad req");
> - ret = BLKPREP_KILL;
> - break;
> + goto kill;
> }
> +
> + /* note the overloading of req->special. When the tag
> + * is active it always means cmd. If the tag goes
> + * back for re-queueing, it may be reset */
> + req->special = cmd;
> + cmd->request = req;
> +
> + /*
> + * FIXME: drop the lock here because the functions below
> + * expect to be called without the queue lock held. Also,
> + * previously, we dequeued the request before dropping the
> + * lock. We hope REQ_STARTED prevents anything untoward from
> + * happening now.
> + */
> + if (blk_fs_request(req) || blk_pc_request(req)) {
> + int ret;
>
> - out:
> - switch (ret) {
> - case BLKPREP_KILL:
> - req->errors = DID_NO_CONNECT << 16;
> - break;
> - case BLKPREP_DEFER:
> /*
> - * If we defer, the elv_next_request() returns NULL, but the
> - * queue must be restarted, so we plug here if no returning
> - * command will automatically do that.
> + * This will do a couple of things:
> + * 1) Fill in the actual SCSI command.
> + * 2) Fill in any other upper-level specific fields
> + * (timeout).
> + *
> + * If this returns 0, it means that the request failed
> + * (reading past end of disk, reading offline device,
> + * etc). This won't actually talk to the device, but
> + * some kinds of consistency checking may cause the
> + * request to be rejected immediately.
> */
> - if (sdev->device_busy == 0)
> - blk_plug_device(q);
> - break;
> - default:
> - req->cmd_flags |= REQ_DONTPREP;
> +
> + /*
> + * This sets up the scatter-gather table (allocating if
> + * required).
> + */
> + ret = scsi_init_io(cmd);
> + switch(ret) {
> + /* For BLKPREP_KILL/DEFER the cmd was released */
> + case BLKPREP_KILL:
> + goto kill;
> + case BLKPREP_DEFER:
> + goto defer;
> + }
> +
> + /*
> + * Initialize the actual SCSI command for this request.
> + */
> + if (blk_pc_request(req)) {
> + scsi_setup_blk_pc_cmnd(cmd);
> + } else if (req->rq_disk) {
> + struct scsi_driver *drv;
> +
> + drv = *(struct scsi_driver **)req->rq_disk->private_data;
> + if (unlikely(!drv->init_command(cmd))) {
> + scsi_release_buffers(cmd);
> + scsi_put_command(cmd);
> + goto kill;
> + }
> + }
> }
>
> - return ret;
> + /*
> + * The request is now prepped, no need to come back here
> + */
> + req->cmd_flags |= REQ_DONTPREP;
> + return BLKPREP_OK;
> +
> + defer:
> + /* If we defer, the elv_next_request() returns NULL, but the
> + * queue must be restarted, so we plug here if no returning
> + * command will automatically do that. */
> + if (sdev->device_busy == 0)
> + blk_plug_device(q);
> + return BLKPREP_DEFER;
> + kill:
> + req->errors = DID_NO_CONNECT << 16;
> + return BLKPREP_KILL;
> }
>
> /*
Correct capacity is reported:
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 551232kB available on disc
and writing works fine.
While tracking this bug I've enabled lockdep, which complains when I
create the device (pktsetup ptk0 /dev/scd0); the warning appears also
with vanilla kernel:
pktcdvd: writer pktcdvd0 mapped to sr0
=============================================
[ INFO: possible recursive locking detected ]
2.6.20-rc7 #24
---------------------------------------------
vol_id/5364 is trying to acquire lock:
(&bdev->bd_mutex){--..}, at: [<b017e587>] do_open+0x64/0x280
but task is already holding lock:
(&bdev->bd_mutex){--..}, at: [<b017e587>] do_open+0x64/0x280
other info that might help us debug this:
2 locks held by vol_id/5364:
#0: (&bdev->bd_mutex){--..}, at: [<b017e587>] do_open+0x64/0x280
#1: (&ctl_mutex#2){--..}, at: [<f1a69bfb>] pkt_open+0x1a/0xcaa [pktcdvd]
stack backtrace:
[<b0136a69>] __lock_acquire+0x11e/0xa09
[<b02f17e3>] __mutex_unlock_slowpath+0x105/0x127
[<b0137635>] lock_acquire+0x56/0x6e
[<b017e587>] do_open+0x64/0x280
[<b02f1b83>] mutex_lock_nested+0xf8/0x27c
[<b017e587>] do_open+0x64/0x280
[<b017e587>] do_open+0x64/0x280
[<b017a427>] __find_get_block+0x158/0x162
[<b017e7fe>] __blkdev_get+0x5b/0x66
[<b017e81b>] blkdev_get+0x12/0x14
[<f1a69c6e>] pkt_open+0x8d/0xcaa [pktcdvd]
[<b02f317b>] _spin_unlock+0x25/0x3b
[<b02f17e3>] __mutex_unlock_slowpath+0x105/0x127
[<b0136545>] trace_hardirqs_on+0x11e/0x141
[<b0165486>] do_lookup+0x4f/0x143
[<b016db3b>] dput+0x2c/0x12c
[<b016d61f>] __d_lookup+0x6a/0x10b
[<b0172567>] lookup_mnt+0x10/0x37
[<b016d61f>] __d_lookup+0x6a/0x10b
[<b02f317b>] _spin_unlock+0x25/0x3b
[<b016d6a3>] __d_lookup+0xee/0x10b
[<b0165486>] do_lookup+0x4f/0x143
[<b016db3b>] dput+0x2c/0x12c
[<b0166e9a>] __link_path_walk+0xa13/0xb57
[<b024a2b5>] kobj_lookup+0x33/0x14d
[<b017e587>] do_open+0x64/0x280
[<b02f1ce1>] mutex_lock_nested+0x256/0x27c
[<b0136364>] mark_held_locks+0x46/0x62
[<b02f1ce1>] mutex_lock_nested+0x256/0x27c
[<b02f1ce1>] mutex_lock_nested+0x256/0x27c
[<b0136545>] trace_hardirqs_on+0x11e/0x141
[<b02f1cff>] mutex_lock_nested+0x274/0x27c
[<b017e587>] do_open+0x64/0x280
[<b017e5b4>] do_open+0x91/0x280
[<b017e92d>] blkdev_open+0x0/0x4d
[<b017e952>] blkdev_open+0x25/0x4d
[<b015ddc8>] __dentry_open+0x101/0x1b9
[<b015defa>] nameidata_to_filp+0x24/0x33
[<b015df3b>] do_filp_open+0x32/0x39
[<b02f317b>] _spin_unlock+0x25/0x3b
[<b015dcbd>] get_unused_fd+0xb3/0xbd
[<b015df84>] do_sys_open+0x42/0xc3
[<b015e03e>] sys_open+0x1c/0x1e
[<b0102ee4>] syscall_call+0x7/0xb
=======================
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 4
pktcdvd: write speed 4x
pktcdvd: 551232kB available on disc
Luca
--
The trouble with computers is that they do what you tell them,
not what you want.
D. Cohen
On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[email protected]> wrote:
> Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > Hi,
> > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > is written to the device is lost after umount.
> > > I rarely use pktcdvd but at some point it used to work on my system.
> > >
> > > This is what I'm doing:
> > >
> > > root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > > using device /dev/scd0
> > > 1029KB internal buffer
> > > setting write speed to 12x
> > > Settings for /dev/scd0:
> > > Fixed packets, size 32
> > > Mode-2 disc
> > >...
> >
> > Does 2.6.20-rc7 work?
> > If no, does it work after applying the attached patch?
> > If no, does 2.6.19.2 work?
>
> Git current + the following patch works.
>
> > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > index 6246219..7c95c76 100644
> > --- a/drivers/block/pktcdvd.c
> > +++ b/drivers/block/pktcdvd.c
> > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct bio **list_head, struct bio
> > */
> > static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *cgc)
> > {
> > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > + char sense[SCSI_SENSE_BUFFERSIZE];
Where did this patch come from?
On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[email protected]> wrote:
>
> > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > Hi,
> > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > > is written to the device is lost after umount.
> > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > >
> > > > This is what I'm doing:
> > > >
> > > > root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > > > using device /dev/scd0
> > > > 1029KB internal buffer
> > > > setting write speed to 12x
> > > > Settings for /dev/scd0:
> > > > Fixed packets, size 32
> > > > Mode-2 disc
> > > >...
> > >
> > > Does 2.6.20-rc7 work?
> > > If no, does it work after applying the attached patch?
> > > If no, does 2.6.19.2 work?
> >
> > Git current + the following patch works.
> >
> > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > index 6246219..7c95c76 100644
> > > --- a/drivers/block/pktcdvd.c
> > > +++ b/drivers/block/pktcdvd.c
> > > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct bio **list_head, struct bio
> > > */
> > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *cgc)
> > > {
> > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > + char sense[SCSI_SENSE_BUFFERSIZE];
>
> Where did this patch come from?
It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
and 406c9b605cbc45151c03ac9a3f95e9acf050808c
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[email protected]> wrote:
> On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[email protected]> wrote:
> >
> > > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > > Hi,
> > > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > > > is written to the device is lost after umount.
> > > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > > >
> > > > > This is what I'm doing:
> > > > >
> > > > > root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > > > > using device /dev/scd0
> > > > > 1029KB internal buffer
> > > > > setting write speed to 12x
> > > > > Settings for /dev/scd0:
> > > > > Fixed packets, size 32
> > > > > Mode-2 disc
> > > > >...
> > > >
> > > > Does 2.6.20-rc7 work?
> > > > If no, does it work after applying the attached patch?
> > > > If no, does 2.6.19.2 work?
> > >
> > > Git current + the following patch works.
> > >
> > > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > > index 6246219..7c95c76 100644
> > > > --- a/drivers/block/pktcdvd.c
> > > > +++ b/drivers/block/pktcdvd.c
> > > > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct bio **list_head, struct bio
> > > > */
> > > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *cgc)
> > > > {
> > > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > > + char sense[SCSI_SENSE_BUFFERSIZE];
> >
> > Where did this patch come from?
>
> It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
> and 406c9b605cbc45151c03ac9a3f95e9acf050808c
>
Oh. That's
[SCSI] untangle scsi_prep_fn
and
[PATCH] Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev
so this is a post-2.6.18 regression, yes?
do we know why this is happening?
On Thu, Feb 01, 2007 at 08:07:12PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[email protected]> wrote:
>
> > On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[email protected]> wrote:
> > >
> > > > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > > > Hi,
> > > > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > > > > is written to the device is lost after umount.
> > > > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > > > >
> > > > > > This is what I'm doing:
> > > > > >
> > > > > > root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q
> > > > > > using device /dev/scd0
> > > > > > 1029KB internal buffer
> > > > > > setting write speed to 12x
> > > > > > Settings for /dev/scd0:
> > > > > > Fixed packets, size 32
> > > > > > Mode-2 disc
> > > > > >...
> > > > >
> > > > > Does 2.6.20-rc7 work?
> > > > > If no, does it work after applying the attached patch?
> > > > > If no, does 2.6.19.2 work?
> > > >
> > > > Git current + the following patch works.
> > > >
> > > > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > > > index 6246219..7c95c76 100644
> > > > > --- a/drivers/block/pktcdvd.c
> > > > > +++ b/drivers/block/pktcdvd.c
> > > > > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct bio **list_head, struct bio
> > > > > */
> > > > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *cgc)
> > > > > {
> > > > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > > > + char sense[SCSI_SENSE_BUFFERSIZE];
> > >
> > > Where did this patch come from?
> >
> > It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
> > and 406c9b605cbc45151c03ac9a3f95e9acf050808c
> >
>
> Oh. That's
>
> [SCSI] untangle scsi_prep_fn
> and
> [PATCH] Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev
>
> so this is a post-2.6.18 regression, yes?
No, a post-2.6.19 regression.
> do we know why this is happening?
No.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed