libata PATA patch update

libata PATA patch update

[Alan Cox]

I've posted a new patch versus 2.6.17-rc3 up at the usual location.

http://zeniv.linux.org.uk/~alan/IDE

This has a lot less in it that touches the core libata code as the
majority of the changes for the core are now merged. I'm still working
down various bug reports and there are bigger changes to do with simplex
that are known but not yet resolved.

There are a couple of things still not yet dealt with in the core,
notably some of the speed management and serialization code but most of
it is there.

Driver support is now more extensive than the old drivers/ide code
although the degree of testing is much lower and there will be plenty of
small bugs left to knock out of the tuning code.

Bug reports/patches/comments welcome

Alan

Re: libata PATA patch update

[Meelis Roos]

AC> I've posted a new patch versus 2.6.17-rc3 up at the usual location.

pata_cs5535 doesn't compile at all:

  CC      drivers/scsi/pata_artop.o
drivers/scsi/pata_artop.c: In function 'artop_init_one':
drivers/scsi/pata_artop.c:433: warning: 'info' may be used uninitialized in this function
  CC      drivers/scsi/pata_atiixp.o
drivers/scsi/pata_atiixp.c: In function 'atiixp_set_dmamode':
drivers/scsi/pata_atiixp.c:122: warning: 'wanted_pio' may be used uninitialized in this function
  CC      drivers/scsi/pata_cmd64x.o
  CC      drivers/scsi/pata_cs5520.o
  CC      drivers/scsi/pata_cs5530.o
  CC      drivers/scsi/pata_cs5535.o
drivers/scsi/pata_cs5535.c: In function 'cs5535_probe_reset':
drivers/scsi/pata_cs5535.c:102: error: 'cs5535p_probe_init' undeclared (first use in this function)
drivers/scsi/pata_cs5535.c:102: error: (Each undeclared identifier is reported only once
drivers/scsi/pata_cs5535.c:102: error: for each function it appears in.)
make[2]: *** [drivers/scsi/pata_cs5535.o] Error 1

-- 
Meelis Roos

Re: libata PATA patch update

[Kevin Radloff]

On 5/8/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> I've posted a new patch versus 2.6.17-rc3 up at the usual location.

Thanks for the update. I'm still getting the same oops when inserting
a CF card, though:

pccard: PCMCIA card inserted into slot 1
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcffff 0xdc000-0xfffff
cs: memory probe 0x50000000-0x53ffffff: excluding 0x50000000-0x53ffffff
cs: memory probe 0x60000000-0x60ffffff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
cs: memory probe 0xd0200000-0xd02fffff: excluding 0xd0200000-0xd021ffff
pcmcia: registering new device pcmcia1.0
ata3: PATA max PIO0 cmd 0x3100 ctl 0x310E bmdma 0x0 irq 0
setup_irq: irq handler mismatch
 <b012a6ae> setup_irq+0xfb/0x10e   <b02414f6> ata_interrupt+0x0/0x13e
 <b012a72d> request_irq+0x6c/0x88   <b0240ce8> ata_device_add+0x2b8/0x559
 <f01a9b8c> pcmcia_request_io+0xa3/0xc0 [pcmcia]   <f02314d4>
pcmcia_init_one+0x482/0x4e2 [pata_pcmcia]
 <f01a917e> pcmcia_device_probe+0x7b/0x109 [pcmcia]   <b023350e>
__driver_attach+0x0/0x59
 <b0233471> driver_probe_device+0x42/0x8b   <b0233544> __driver_attach+0x36/0x59
 <b0232f9c> bus_for_each_dev+0x33/0x55   <b02333db> driver_attach+0x11/0x13
 <b023350e> __driver_attach+0x0/0x59   <b0232cc6> bus_add_driver+0x64/0xfa
 <f01a8d1f> pcmcia_register_driver+0x4a/0xab [pcmcia]   <b0128815>
sys_init_module+0x1221/0x13ae
 <b0102aeb> syscall_call+0x7/0xb
BUG: unable to handle kernel NULL pointer dereference at virtual
address 00000000
 printing eip:
b0233b54
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: pata_pcmcia ipt_LOG xt_limit xt_state
iptable_filter ip_conntrack i915 drm fuj02b1_acpi joydev snd_intel8x0
snd_intel8x0m snd_ac97_codec snd_ac97_bus pcmcia firmware_class sg
snd_pcm_oss snd_mixer_oss uhci_hcd ehci_hcd snd_pcm snd_timer ohci1394
ieee1394 sr_mod psmouse yenta_socket rsrc_nonstatic pcmcia_core
usbcore 8139too mii crc32 snd soundcore snd_page_alloc evdev cdrom
CPU:    0
EIP:    0060:[<b0233b54>]    Not tainted VLI
EFLAGS: 00010206   (2.6.17-rc3-ck3-ide1-fu-mw #1)
EIP is at make_class_name+0x29/0x88
eax: 00000000   ebx: ffffffff   ecx: ffffffff   edx: 00000009
esi: b02efb2c   edi: 00000000   ebp: 00000000   esp: b18c3b98
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 2412, threadinfo=b18c3000 task=eea3b070)
Stack: <0>ef3fa9f8 ef3fa9f8 b02efb2c b02efb34 b02efac0 b0233d2d
00000000 00000000
       ef3fa9f8 00000246 ef3fa800 ef3fa828 b0233dc8 ef3fa8d0 b02376b4 ef3faa90
       ee432140 00003100 0000310e b023e697 00000000 b0240f12 b18c3c4c ee432140
Call Trace:
 <b0233d2d> class_device_del+0x6f/0x102   <b0233dc8>
class_device_unregister+0x8/0x10
 <b02376b4> scsi_remove_host+0xe5/0xf0   <b023e697> ata_host_remove+0xe/0x18
 <b0240f12> ata_device_add+0x4e2/0x559   <f01a9b8c>
pcmcia_request_io+0xa3/0xc0 [pcmcia]
 <f02314d4> pcmcia_init_one+0x482/0x4e2 [pata_pcmcia]   <f01a917e>
pcmcia_device_probe+0x7b/0x109 [pcmcia]
 <b023350e> __driver_attach+0x0/0x59   <b0233471> driver_probe_device+0x42/0x8b
 <b0233544> __driver_attach+0x36/0x59   <b0232f9c> bus_for_each_dev+0x33/0x55
 <b02333db> driver_attach+0x11/0x13   <b023350e> __driver_attach+0x0/0x59
 <b0232cc6> bus_add_driver+0x64/0xfa   <f01a8d1f>
pcmcia_register_driver+0x4a/0xab [pcmcia]
 <b0128815> sys_init_module+0x1221/0x13ae   <b0102aeb> syscall_call+0x7/0xb
Code: d0 c3 55 31 ed 57 56 53 83 cb ff 83 ec 04 89 d9 89 04 24 8b 40
44 8b 38 89 e8 f2 ae f7 d1 49 8b 04 24 89 ca 89 d9 8b 78 08 89 e8 <f2>
ae f7 d1 49 8d 44 0a 02 ba d0 00 00 00 e8 b9 d9 f0 ff ba f4
EIP: [<b0233b54>] make_class_name+0x29/0x88 SS:ESP 0068:b18c3b98

--
Kevin 'radsaq' Radloff
radsaq@gmail.com
http://thesaq.com/

Re: libata PATA patch update

[Alan Cox]

On Llu, 2006-05-08 at 13:29 -0400, Kevin Radloff wrote:
> On 5/8/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > I've posted a new patch versus 2.6.17-rc3 up at the usual location.
> 
> Thanks for the update. I'm still getting the same oops when inserting
> a CF card, though:

Different oops I think 8) I've fixed that one now although it may well
be that ide2 once I release it now oopses where it did before the PCMCIA
change rather than where it did this time.

Alan

Re: libata PATA patch update

[Kevin Radloff]

On 5/9/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Llu, 2006-05-08 at 13:29 -0400, Kevin Radloff wrote:
> > Thanks for the update. I'm still getting the same oops when inserting
> > a CF card, though:
>
> Different oops I think 8) I've fixed that one now although it may well
> be that ide2 once I release it now oopses where it did before the PCMCIA
> change rather than where it did this time.

Ahh, yes.. no longer through alloc_io_space. And the setup_irq
message/trace is new. ;)

Is there anything I can do to help debug this?

--
Kevin 'radsaq' Radloff
radsaq@gmail.com
http://thesaq.com/

Re: libata PATA patch update

[Matthieu CASTET]

Hi Alan,

Le Mon, 08 May 2006 17:06:40 +0100, Alan Cox a écrit :

> I've posted a new patch versus 2.6.17-rc3 up at the usual location.
> 
> http://zeniv.linux.org.uk/~alan/IDE
> 
Aren't there a bug in via cable detect ?

The via ide driver do
pci_read_config_dword(dev, VIA_UDMA_TIMING, &u);
for (i = 24; i >= 0; i -= 8)
                                if (((u >> i) & 0x10) ||
                                    (((u >> i) & 0x20) &&
                                     (((u >> i) & 7) < 6))) {
                                        /* BIOS 80-wire bit or
                                         * UDMA w/ < 60ns/cycle
                                         */
                                        vdev->via_80w |= (1 << (1 - (i >> 4)));
                                }
80w = (vdev->via_80w >> hwif->channel) & 1;

upper bit are for channel 0 and lower bit for channel 1.
the pata driver do
pci_read_config_dword(pdev, 0x50, &ata66);
80w = ata66 & (0x1010 << (16 * ap->hard_port_no))
upper bit are for channel 1 and lower bit for channel 0.

at boot VIA_UDMA_TIMING is 0xf1f1e6e6 for a 80w cable on channel 0 and 40w
cable on channel 1.
Pata driver set my UDMA100 disk at UDMA33.

Matthieu.

PS : any idea in order to allow to work my cdrw drive, that don't return
interrupt when setting xfermode ?

Re: libata PATA patch update

[matthieu castet]

Hi,
matthieu castet wrote:
> Hi,
> 
> Alan Cox wrote:
> 
>> On Llu, 2006-05-08 at 23:57 +0200, Matthieu CASTET wrote:
>>
> 
>>
>>> PS : any idea in order to allow to work my cdrw drive, that don't return
>>> interrupt when setting xfermode ?
>>
>>
>>
>> The real question is "why is it not returning an interrupt", as it is
>> required to do so unless nIEN masking is active. Handling that is a
>> matter for the libata core itself and depends on what Jeff has planned,
>> but I'm still a bit bothered that it may not be a drive problem but a
>> bug in the via pata driver.
> 
> You seem right : I tried the drive on the sil680 and it works [1].
> The same config (only one slave drive channel 1) fails [2].
> What is strange it that there is the same problem with the old via ide 
> driver and hdparm -X [3].
> Have you any hint what could I try ?
> 

It seems there is really a bug in the timing code.
I attach the lspci diff (from ide to pata) and the viaideinfo one


Matthieu

  00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00
  10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  20: 01 fc 00 00 00 00 00 00 00 00 00 00 06 11 71 05
  30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00
  40: 0b f2 09 35 18 1c c0 00 20 20 20 20 ff 00 20 20
-50: e6 e6 e1 e1 0c 00 00 00 a8 a8 a8 a8 00 00 00 00
+50: 27 27 27 27 0c 00 00 00 a8 a8 a8 a8 00 00 00 00
  60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
  70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
-80: 00 40 ed 3f 00 00 00 00 00 00 00 00 00 00 00 00
+80: 00 f0 b9 01 00 00 00 00 00 50 a9 01 00 00 00 00
  90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


@@ -16,7 +16,7 @@
  Post Write Buffer:            yes                 yes
  Enabled:                      yes                 yes
  Simplex only:                  no                  no
-Cable Type:                   80w                 40w
+Cable Type:                   40w                 40w
  -------------------drive0----drive1----drive2----drive3-----
  Transfer Mode:       UDMA      UDMA      UDMA      UDMA
  Address Setup:      120ns     120ns     120ns     120ns
@@ -24,5 +24,5 @@
  Cmd Recovery:        30ns      30ns      30ns      30ns
  Data Active:         90ns      90ns      90ns      90ns
  Data Recovery:       30ns      30ns      30ns      30ns
-Cycle Time:          22ns      22ns      60ns      60ns
-Transfer Rate:   88.8MB/s  88.8MB/s  33.3MB/s  33.3MB/s
+Cycle Time:          67ns      67ns      67ns      67ns
+Transfer Rate:   29.6MB/s  29.6MB/s  29.6MB/s  29.6MB/s

Re: libata PATA patch update

[Rene Herman]

Alan Cox wrote:

> I've posted a new patch versus 2.6.17-rc3 up at the usual location.

Am currently running with this on AMD756. Both channels have 80w cables.

===
libata version 1.20 loaded.
pata_amd 0000:00:07.1: version 0.1.7
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003
88:107f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1: dev 0 configured for UDMA/66
scsi0 : pata_amd
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
88:0407
ata2: dev 0 ATAPI, max UDMA/33
ata2: dev 1 cfg 49:0b00 82:4218 83:4000 84:4000 85:4218 86:0000 87:4000
88:101f
ata2: dev 1 ATAPI, max UDMA/66
ata2: dev 0 configured for UDMA/33
ata2: dev 1 configured for UDMA/33
scsi1 : pata_amd
   Vendor: PLEXTOR   Model: CD-R   PREMIUM    Rev: 1.06
   Type:   CD-ROM                             ANSI SCSI revision: 05
   Vendor: PLEXTOR   Model: DVD-ROM PX-116A   Rev: 1.00
   Type:   CD-ROM                             ANSI SCSI revision: 05
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
  sda: sda1 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 > sda2
sd 0:0:0:0: Attached scsi disk sda
===

It seems to be working nicely. The hdparm -t result is slightly lower
than with the old IDE driver. With the default settings, the old IDE
driver gives me 49.4/5 MB/s, and 50.6/7 after a hdparm -a 1024. With
default setting the new driver gives me 46.6/7 MB/s, and 48.8/9 after
that same hdparm -a 1024. Higher than -a 1024 does not seem to matter
with either driver. The numbers are close, but completely repeatable.

CD and DVD ROMs are also working fine, including readcd and CDDA. This
is what cdparanoia has to say about sr0:

===
Checking /dev/sr0 for cdrom...
         Testing /dev/sr0 for cooked ioctl() interface
                 /dev/sr0 is not a cooked ioctl CDROM.
         Testing /dev/sr0 for SCSI interface
                 generic device: /dev/sg1
                 ioctl device: /dev/sr0

Found an accessible SCSI CDROM drive.
Looking at revision of the SG interface in use...
         SG interface version 3.5.33; OK.

CDROM model sensed sensed: PLEXTOR CD-R   PREMIUM 1.06

Checking for SCSI emulation...
         Drive is ATAPI (using SCSI host adaptor emulation)
         Couldn't disable kernel command translation layer

Checking for MMC style command set...
         Drive is MMC style
         DMA scatter/gather table entries: 127
         table entry size: 32768 bytes
         maximum theoretical transfer: 1769 sectors
         Setting default read size to 13 sectors (30576 bytes).

Verifying CDDA command set...
         Expected command set reads OK.
===

The "couldn't disable kernel command translation layer" bit is probably
expected?

It does have somwhat higher system times during ripping. The old IDE
driver, with cdparanoia -v -z -B, gives me some 30% user and 10-15%
system. This driver gets me 15-25% user and 15-20 % system. Lower user
times though, so I guess that might just be a protocol difference?

In any case, it seems that this driver is also not using DMA for CDDA? I 
am using slackware 10.2 (vanilla) "cdparanoia III release 9.8 (March 23, 
2001)". A while ago someone on this list pointed to some patches for 
SG_IO use with cdparanoia but this made my machine highly unstable. 
Would you like me to retest with this new driver? If so, any specific 
version of cdparanoia?

DVD is fine. UDMA33 though, although the drive is capable of UDMA66:

===
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
88:0407
ata2: dev 0 ATAPI, max UDMA/33
ata2: dev 1 cfg 49:0b00 82:4218 83:4000 84:4000 85:4218 86:0000 87:4000
88:101f
ata2: dev 1 ATAPI, max UDMA/66
ata2: dev 0 configured for UDMA/33
ata2: dev 1 configured for UDMA/33
===

The old IDE driver does set it to UDMA66 after an ide1=ata66, and after
the recently merged patch to amd74xx to "only do disk side cable
detection". I assumed it was that same problem, but I see that
amd_early_probe_init() also assumes 80w cables on amd756 same as amd74xx
does. Do I need to tell it something additionally to make it do UDMA66?

This is what the drive itself says, through the old IDE driver:

===
/dev/hdd:

  Model=PLEXTOR DVD-ROM PX-116A, FwRev=1.00, SerialNo=
  Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
  RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
  BuffType=unknown, BuffSize=0kB, MaxMultSect=0
  (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
  IORDY=yes, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
  PIO modes:  pio0 pio1 pio2 pio3 pio4
  DMA modes:  mdma0 mdma1 mdma2
  UDMA modes: udma0 udma1 udma2 udma3 *udma4
  AdvancedPM=no
  Drive conforms to: device does not report version:

  * signifies the current active mode
===

Hope this was a useful report...

Rene.

Re: libata PATA patch update

[Alan Cox]

On Maw, 2006-05-09 at 01:48 +0200, Rene Herman wrote:
> The "couldn't disable kernel command translation layer" bit is probably
> expected?

I think so yes.

> In any case, it seems that this driver is also not using DMA for CDDA? I 

It should use whatever the sr.c SCSI CD driver code uses when doing
CDDA, and it isn't directly a part of the driver (although there are
hooks so drivers can filter/control what ATAPI can be done with DMA).

> am using slackware 10.2 (vanilla) "cdparanoia III release 9.8 (March 23, 
> 2001)". A while ago someone on this list pointed to some patches for 
> SG_IO use with cdparanoia but this made my machine highly unstable. 
> Would you like me to retest with this new driver? If so, any specific 
> version of cdparanoia?

I would be interested to know what happens if you try this, version
doesn't matter.

> DVD is fine. UDMA33 though, although the drive is capable of UDMA66:

The core code sets both drives to the same speed on the cable. The old
-ac code fixed this but I've not pushed that change over (in part
because it will naturally happen now as other changes go in).

Thus dev1 is pulling dev0 down to UDMA33 for now.

> The old IDE driver does set it to UDMA66 after an ide1=ata66, and after
> the recently merged patch to amd74xx to "only do disk side cable
> detection". I assumed it was that same problem, but I see that

That change is in the libata driver as well so should not be a problem.

> Hope this was a useful report...

Much appreciated,

Alan

Re: libata PATA patch update

[Rene Herman]

Alan Cox wrote:

>> am using slackware 10.2 (vanilla) "cdparanoia III release 9.8 (March 23, 
>> 2001)". A while ago someone on this list pointed to some patches for 
>> SG_IO use with cdparanoia but this made my machine highly unstable. 
>> Would you like me to retest with this new driver? If so, any specific 
>> version of cdparanoia?
> 
> I would be interested to know what happens if you try this, version
> doesn't matter.

Did so. Took vanilla cdparanoia-III-alpha9.8 from:

http://downloads.xiph.org/releases/cdparanoia/cdparanoia-III-alpha9.8.src.tgz

and then applied the labels and sgio patches from:

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/cdparanoia-alpha9.8-24.src.rpm

Unfortunately, the only difference with regular cdparanoia seems to be 
that info bit. Now it's just:

===
Checking /dev/cdrom for cdrom...

CDROM model sensed sensed: PLEXTOR CD-R   PREMIUM 1.06


Checking for SCSI emulation...
         Drive is ATAPI (using SCSI host adaptor emulation)

Checking for MMC style command set...
         Drive is MMC style
Verifying CDDA command set...
         Expected command set reads OK.
===

Nothing about the SG interface and no "Couldn't disable kernel command 
translation layer" bit therefore. It gives me the exact same times 
regular cdparanoia does; 15-25% user, 15-20% system. This might be 
expected; it seems not unlikely in fact that the SG_IO patch would only 
be expected to do something for usage through the IDE driver. Added Jens 
Axboe to the CC...

I rechecked that it does indeed make a difference for the IDE driver and 
it does. Almost immediate timeout/lockups again, as I reported once before:

http://lkml.org/lkml/2006/1/10/373

This does seem to be drive dependent -- I do not get this when ripping 
from my DVD-ROM drive (hdd, sr1). There is also no difference in times 
though between normal and patched cdparanoia on hdd, so as a summary of 
what this SG_IO patch is doing for me, "nothing useful" will do nicely.

Oh well; in any case, in the context of this pata test, no regressions!

Rene.

Re: libata PATA patch update

[Rene Herman]

Rene Herman wrote:

> CD and DVD ROMs are also working fine, including readcd and CDDA.

Well, other than spamming the kernel message buffer into oblivion. Must
have missed these last time around but cdparanoia (regular cdparanoia)
triggers tons and tons of these, with both sr0 (hdc, a CD-RW) and sr1
(hdd, DVD-ROM):

sg_write: data in/out 56/56 bytes for SCSI command 0x12--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 26/26 bytes for SCSI command 0x5a--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 106 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 1087 messages suppressed.
sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 1147 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly

Rene.

Re: libata PATA patch update

[Rene Herman]

Rene Herman wrote:

>> CD and DVD ROMs are also working fine, including readcd and CDDA.
> 
> Well, other than spamming the kernel message buffer into oblivion. Must
> have missed these last time around

Confirmed. Realised I was on 2.6.17-rc4-ide1 now, and 2.6.17-rc3-ide1 last
time, but I just downgraded and these messages are indeed also present on
2.6.17-rc3-ide1.

> but cdparanoia (regular cdparanoia) triggers tons and tons of these, with
> both sr0 (hdc, a CD-RW) and sr1 (hdd, DVD-ROM):
> 
> sg_write: data in/out 56/56 bytes for SCSI command 0x12--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 26/26 bytes for SCSI command 0x5a--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
>   program cdparanoia not setting count and/or reply_len properly
> printk: 106 messages suppressed.
> sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing 
> data in;
>   program cdparanoia not setting count and/or reply_len properly
> printk: 1087 messages suppressed.
> sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing 
> data in;
>   program cdparanoia not setting count and/or reply_len properly
> printk: 1147 messages suppressed.
> sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing 
> data in;
>   program cdparanoia not setting count and/or reply_len properly

Rene.