Hi,
I suffer from unreliable cdrom operations (failing DAE and burn sessions)
with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
Additionally, the syslog is continuesly spammed with:
Feb 12 00:03:22 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
Feb 12 00:57:52 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
Feb 12 01:36:21 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
Feb 12 01:38:49 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
Feb 12 08:06:07 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
I drove that devices on a pdc20268 based Promise Ultra TX/2 100 card for
some time, which had some IDE/ATAPI issues documented. After exchanging
that PCI card with a "Silicon Image PCI0680 based one, the problem persists.
Is there any firmware/atapi protocol problem known with these drives?
These are the offenders:
42: IDE 02.0: 10602 CD-ROM (DVD)
[Created at block.222]
UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL
Unique ID: 90A1.yYhZwSaKZZ6
Parent ID: ejN_.zzJBQoyZsp8
SysFS ID: /block/hdc
SysFS BusID: 1.0
SysFS Device Link: /devices/pci0000:00/0000:00:0e.0/0000:02:06.0/ide1/1.0
Hardware Class: cdrom
Model: "PLEXTOR DVDR PX-608AL"
Vendor: "PLEXTOR"
Device: "DVDR PX-608AL"
Revision: "1.01"
Serial ID: "GDDL000676UE"
Driver: "SiI_IDE", "ide-cdrom"
Driver Modules: "siimage", "ide_cd"
Device File: /dev/hdc
Device Files: /dev/hdc, /dev/disk/by-path/pci-0000:02:06.0-ide-0:0
Device Number: block 22:0
Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
Drive status: no medium
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #34 (Unknown mass storage controller)
Drive Speed: 24
43: IDE 04.0: 10602 CD-ROM (DVD)
[Created at block.222]
UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL_0
Unique ID: 3Ng9.rKN6BMng3oC
Parent ID: ejN_.zzJBQoyZsp8
SysFS ID: /block/hde
SysFS BusID: 2.0
SysFS Device Link: /devices/pci0000:00/0000:00:0e.0/0000:02:06.0/ide2/2.0
Hardware Class: cdrom
Model: "PLEXTOR DVDR PX-608AL"
Vendor: "PLEXTOR"
Device: "DVDR PX-608AL"
Revision: "1.01"
Serial ID: "GGDL007101UE"
Driver: "SiI_IDE", "ide-cdrom"
Driver Modules: "siimage", "ide_cd"
Device File: /dev/hde
Device Files: /dev/hde, /dev/disk/by-path/pci-0000:02:06.0-ide-1:0
Device Number: block 33:0
Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
Drive status: no medium
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #34 (Unknown mass storage controller)
Drive Speed: 24
hanging on this controller (now):
44: PCI 206.0: 0180 Unknown mass storage controller
[Created at pci.286]
UDI: /org/freedesktop/Hal/devices/pci_1095_680
Unique ID: ejN_.zzJBQoyZsp8
Parent ID: vuMS.8LoPsVNGJbF
SysFS ID: /devices/pci0000:00/0000:00:0e.0/0000:02:06.0
SysFS BusID: 0000:02:06.0
Hardware Class: storage
Model: "Silicon Image PCI0680 Ultra ATA-133 Host Controller"
Vendor: pci 0x1095 "Silicon Image, Inc."
Device: pci 0x0680 "PCI0680 Ultra ATA-133 Host Controller"
SubVendor: pci 0x1095 "Silicon Image, Inc."
SubDevice: pci 0x0680
Revision: 0x02
Driver: "SiI_IDE"
Driver Modules: "siimage"
I/O Ports: 0x9c00-0x9c07 (rw)
I/O Ports: 0x9800-0x9803 (rw)
I/O Ports: 0x9400-0x9407 (rw)
I/O Ports: 0x9000-0x9003 (rw)
I/O Ports: 0x8c00-0x8c0f (rw)
Memory Range: 0xfdfff000-0xfdfff0ff (rw,non-prefetchable)
Memory Range: 0xf4000000-0xf407ffff (ro,prefetchable,disabled)
IRQ: 169 (1767334 events)
Module Alias: "pci:v00001095d00000680sv00001095sd00000680bc01sc80i00"
Driver Info #0:
Driver Status: siimage is active
Driver Activation Cmd: "modprobe siimage"
Driver Info #1:
Driver Status: pata_sil680 is active
Driver Activation Cmd: "modprobe pata_sil680"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #30 (PCI bridge)
Any hints are highly appreciated.
Pete
On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> Hi,
>
> I suffer from unreliable cdrom operations (failing DAE and burn sessions)
> with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
^^^^
Hi,
can please you test this with a more recent kernel. Yours is almost ancient -
from Sep. 2006.
Thanks.
--
Regards/Gru?,
Boris.
Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > Hi,
> >
> > I suffer from unreliable cdrom operations (failing DAE and burn
> > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
>
> ^^^^
> Hi,
>
> can please you test this with a more recent kernel. Yours is almost
> ancient - from Sep. 2006.
Sure, sorry. Here we go:
Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
~> uname -a
Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
Thanks for caring,
Pete
On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
[Added Bart to CC]
> Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > Hi,
> > >
> > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> >
> > ^^^^
> > Hi,
> >
> > can please you test this with a more recent kernel. Yours is almost
> > ancient - from Sep. 2006.
>
> Sure, sorry. Here we go:
>
> Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> Trying to recover by ending request.
> Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> Trying to recover by ending request.
>
> ~> uname -a
> Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
Actually the interrupt handler in ide-cd got rewritten and you're still using the
old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before
the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1
or wait until 2.6.25 is released in case you don't want to try hazardous materials
such as an -rc kernel[*] :).
Bart?
*. As a matter of fact it runs quite smoothly on my machines.
--
Regards/Gru?,
Boris.
Am Donnerstag, 14. Februar 2008 schrieb Borislav Petkov:
> On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
>
> [Added Bart to CC]
>
> > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > > Hi,
> > > >
> > > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> > >
> > > ^^^^
> > > Hi,
> > >
> > > can please you test this with a more recent kernel. Yours is almost
> > > ancient - from Sep. 2006.
> >
> > Sure, sorry. Here we go:
> >
> > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused
> > (ireason = 0x01). Trying to recover by ending request.
> > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused
> > (ireason = 0x01). Trying to recover by ending request.
> >
> > ~> uname -a
> > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon
> > i386 GNU/Linux
>
> Actually the interrupt handler in ide-cd got rewritten and you're still
> using the old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went
> into mainline before the 2.6.25-rc1 so we'll be able to test the new one
> only when you try out 2.6.25-rc1 or wait until 2.6.25 is released in case
> you don't want to try hazardous materials such as an -rc kernel[*] :).
Hrm, I highly depend on that system being reliable?, thus I would prefer a
diff, if feasible at all. That way, any breakage may be embanked to PATA.
OTOH, I'm willing to help to get down to the issue (knowing that this is the
only way to finally get rid of it).
Thanks,
Pete
?) As a matter of fact, I suffered from way to many regressions in essential
subsystems (kernel, X, nss_ldap) lately, not to speak from the usual
calamities in peripheral areas of such complex beasts.
On Thursday 14 February 2008, Borislav Petkov wrote:
> On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
>
> [Added Bart to CC]
>
> > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > > Hi,
> > > >
> > > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> > >
> > > ^^^^
> > > Hi,
> > >
> > > can please you test this with a more recent kernel. Yours is almost
> > > ancient - from Sep. 2006.
> >
> > Sure, sorry. Here we go:
> >
> > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > Trying to recover by ending request.
> > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > Trying to recover by ending request.
> >
> > ~> uname -a
> > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
>
> Actually the interrupt handler in ide-cd got rewritten and you're still using the
> old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before
> the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1
> or wait until 2.6.25 is released in case you don't want to try hazardous materials
> such as an -rc kernel[*] :).
>
> Bart?
>
> *. As a matter of fact it runs quite smoothly on my machines.
2.6.25-rc1-git1 if you are using IDE.
however it may still have this problem
if (ireason == 0) {
write = 1;
xferfunc = HWIF(drive)->atapi_output_bytes;
} else if (ireason == 2 || (ireason == 1 &&
(blk_fs_request(rq) || blk_pc_request(rq)))) {
we problably need to call ide_cd_check_ireason() also for REQ_TYPE_ATA_PC
requests and remove (blk_fs_request(rq) || blk_pc_request(rq) here
write = 0;
xferfunc = HWIF(drive)->atapi_input_bytes;
} else {
printk(KERN_ERR "%s: %s: The drive "
"appears confused (ireason = 0x%02x). "
"Trying to recover by ending request.\n",
drive->name, __FUNCTION__, ireason);
goto end_request;
}
Bart
On 2/14/08, Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Thursday 14 February 2008, Borislav Petkov wrote:
> > On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
> >
> > [Added Bart to CC]
> >
> > > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > > > Hi,
> > > > >
> > > > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> > > >
> > > > ^^^^
> > > > Hi,
> > > >
> > > > can please you test this with a more recent kernel. Yours is almost
> > > > ancient - from Sep. 2006.
> > >
> > > Sure, sorry. Here we go:
> > >
> > > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > Trying to recover by ending request.
> > > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > Trying to recover by ending request.
> > >
> > > ~> uname -a
> > > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
> >
> > Actually the interrupt handler in ide-cd got rewritten and you're still using the
> > old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before
> > the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1
> > or wait until 2.6.25 is released in case you don't want to try hazardous materials
> > such as an -rc kernel[*] :).
> >
> > Bart?
> >
> > *. As a matter of fact it runs quite smoothly on my machines.
>
> 2.6.25-rc1-git1 if you are using IDE.
>
> however it may still have this problem
>
> if (ireason == 0) {
> write = 1;
> xferfunc = HWIF(drive)->atapi_output_bytes;
> } else if (ireason == 2 || (ireason == 1 &&
> (blk_fs_request(rq) || blk_pc_request(rq)))) {
>
> we problably need to call ide_cd_check_ireason() also for REQ_TYPE_ATA_PC
> requests and remove (blk_fs_request(rq) || blk_pc_request(rq) here
>
> write = 0;
> xferfunc = HWIF(drive)->atapi_input_bytes;
> } else {
> printk(KERN_ERR "%s: %s: The drive "
> "appears confused (ireason = 0x%02x). "
> "Trying to recover by ending request.\n",
> drive->name, __FUNCTION__, ireason);
> goto end_request;
> }
>
> Bart
>
Hans-Peter,
i will prepare a patch against 2.6.24 for you to try later.
Thanks,
Boris.
On Thu, Feb 14, 2008 at 02:42:58PM +0100, Boris Petkov wrote:
> On 2/14/08, Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> > On Thursday 14 February 2008, Borislav Petkov wrote:
> > > On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
> > >
> > > [Added Bart to CC]
> > >
> > > > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> > > > >
> > > > > ^^^^
> > > > > Hi,
> > > > >
> > > > > can please you test this with a more recent kernel. Yours is almost
> > > > > ancient - from Sep. 2006.
> > > >
> > > > Sure, sorry. Here we go:
> > > >
> > > > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > > Trying to recover by ending request.
> > > > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > > Trying to recover by ending request.
> > > >
> > > > ~> uname -a
> > > > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
> > >
> > > Actually the interrupt handler in ide-cd got rewritten and you're still using the
> > > old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before
> > > the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1
> > > or wait until 2.6.25 is released in case you don't want to try hazardous materials
> > > such as an -rc kernel[*] :).
> > >
> > > Bart?
> > >
> > > *. As a matter of fact it runs quite smoothly on my machines.
> >
> > 2.6.25-rc1-git1 if you are using IDE.
> >
> > however it may still have this problem
> >
> > if (ireason == 0) {
> > write = 1;
> > xferfunc = HWIF(drive)->atapi_output_bytes;
> > } else if (ireason == 2 || (ireason == 1 &&
> > (blk_fs_request(rq) || blk_pc_request(rq)))) {
> >
> > we problably need to call ide_cd_check_ireason() also for REQ_TYPE_ATA_PC
> > requests and remove (blk_fs_request(rq) || blk_pc_request(rq) here
> >
> > write = 0;
> > xferfunc = HWIF(drive)->atapi_input_bytes;
> > } else {
> > printk(KERN_ERR "%s: %s: The drive "
> > "appears confused (ireason = 0x%02x). "
> > "Trying to recover by ending request.\n",
> > drive->name, __FUNCTION__, ireason);
> > goto end_request;
> > }
> >
> > Bart
> >
> Hans-Peter,
>
> i will prepare a patch against 2.6.24 for you to try later.
Hi,
i thought that backporting ide-cd to 2.6.24 would be self-contained but the
problem is that it pulls in changes made in the block layer (ll_rw_blk.c splitup)
and if i pull those also in the patch, i can't guarantee the stability of your
system. Besides, this turns pretty fast into a chained pulling which will result
into a subset of 2.6.25-rc1 applied ontop of your 2.6.24.1 kernel so the only
alternative is to wait after 2.6.25 has been released and tackle the problem then.
--
Regards/Gru?,
Boris.
On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
[ Added Bart to CC: ]
Hi Brad,
> Borislav Petkov wrote:
>
> > > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > Trying to recover by ending request.
> > > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01).
> > > Trying to recover by ending request.
> > >
> > > ~> uname -a
> > > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux
> >
> > Actually the interrupt handler in ide-cd got rewritten and you're still using the
> > old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before
> > the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1
> > or wait until 2.6.25 is released in case you don't want to try hazardous materials
> > such as an -rc kernel[*] :).
>
> I have exactly the same problem. I have a two-month old PC with a
> Gigabyte P35-DS4
> motherboard, which has the Intel P35 chipset with ICH10 south bridge and
> additional JMicron IDE/SATA controller. I have two SATA-II hard disks
> and a sole
> IDE device, a Pioneer DVR-115D DVD-ROM, hooked up to the JMicron IDE port.
> The motherboard also has an embedded Realtek RTL8111/8168B gigabit
> ethernet controller.
>
> The motherboard/bios assigns both the JMicron IDE controller and the Realtek
> controller to the same interrupt - typically '15'. There's nothing in
> the bios that
> allows me to move one away from the other. I can 'reserve' or block IRQs, but
> that only shifts them both to another interrupt.
well the driver probes the bios for that data and assigns the irq line it gets
from it.
> Similarly, no matter what I do with the Linux kernel, using boot parameters such
> as 'acpi=off', 'noapic', 'nolapic' and the like, I can never get the
> kernel to use
> different interrupts for these two controllers. A 'cat
> /proc/interrupts' always shows
> them sharing their IRQ:
>
> # grep ide /proc/interrupts
> 17: 58077 4 98999 129160 IO-APIC-fasteoi ide0, eth0
>
> With the IDE driver compiled into the kernel any access to the DVD is fine
> until I start using the network. Upon any network activity I get the 'confused'
> messages and more:
>
> kernel: hda: cdrom_pc_intr: The drive appears confused (ireason =
> 0x01). Trying to recover by ending request.
> last message repeated 3 times
> kernel: ide: failed opcode was: unknown
> kernel: hda: drive not ready for command
> kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
>
> KDE even kindly pops up a window telling me that someone has inserted a (ghost)
> DVD disc, would I care to play it? :-(
>
> I know nothing of modern/PCI hardware and their interrupt magic, but it seemed
> to me that the IDE driver was erroneously picking up the interrupts destined for
> the Realtek NIC and thinking they were for it. Unfortunately there seemed to be
> no way for me to separate the two or get the IDE driver its own IRQ, either via
> the PC's bios or linux kernel boot parameters.
>
> When I saw the recent message from Hans-Peter Jansen about this exact
> problem, and Boris's comment that something in interrupt land for the
> CD driver had been fixed, I thought the latest version of the kernel would
> rectify matters. I installed the 2.6.25-rc2 kernel from kernel.org
> but the problem
> is still there.
Can you please send me your whole boot log of 2.6.25-rc2? Thanks.
>
> As a workaround I've disabled IDE entirely in my kernel build and am using
> sr_mod to present the DVD as /dev/sr0.
>
> As a result of all this I've got several novice questions relating to
> this matter.
> I don't know if this mailing list is an appropriate place to ask them
> .. my apologies
> if not. Any quick references to reference material would be appreciated.
>
> Given all the kernel parameters to change IRQ routing and turn ACPI actions
> up, down and sideways, is there any way to tell it to assign an explicit
> IRQ to a device? Or have it that the IDE driver doesn't share? I thought
> CONFIG_IDEPCI_SHARE_IRQ might have something to do with it, but fiddling
> the value for that had no effect. It 'feels' to me that all these IRQs seem to
> be highly adjustable by the kernel, so I was hoping there'd be a way to
> let the IDE driver have one to itself.
>
> Is there any way to leave the IDE driver compiled into the kernel but tell
> it to leave the DVD-ROM drive alone, so sr_mod can claim it rather than
> ide-cd? I couldn't do it with my kernel, but I think Ubuntu (7.10) does
> manage it. I tried various kernel boot parameters like 'hda=scsi' or
> 'hda=ide-scsi' but nothing seemed to work. It would be nice to be able
> to use IDE hard disks while leaving the DVD-ROM to sr_mod until this
> problem is resolved.
since your cdrom seems to be hda from what i've seen above, try booting with
'hda=noprobe' or maybe 'hda=none' to see which one turns the probing off for
you. See Documentation/ide.txt for details.
>
> Is there a primer/guide somewhere on how the modules all inter-relate
> in the kernel? When IDE is compiled I see 'ide0' sharing IRQ17 with
> 'eth0' in /proc/interrupts. When IDE is disabled it's replaced with
> 'libata' (which DOESN'T have any problems sharing). I'm just curious
> as to why 'libata' isn't seen when IDE is taking front stage; does it
> sit underneath somehow? Similarly I'm a bit fuzzy on how sr_mod
> sits on top of 'cdrom' while 'ide-cd' uses both 'cdrom' and ide-core.
> I'm just curious on how they all work together. Does the 'cdrom'
> module talk straight to the DVD-ROM hardware or does it go though
> libata? I always thought it used IDE.
Roughly speaking, cdrom.c is the unified cdrom layer that delivers common
functionality to all the cdrom devices. ide-cd and others are the low-level
device drivers that offer drive-specific functionality only. In case you wanna
know more about it, see Documentation/cdrom/cdrom-standard.tex (might want to
convert it to something more readable) and read the section on stackable kernel
modules in Linux Device Drivers, 3 ed.
>
> My apologies if this post is at too simple/high a level for the wizards
> present. I thought the feedback on 2.6.25-rc2 might be useful.
>
> Thanks,
>
>
> Brad
--
Regards/Gru?,
Boris.
On Sunday 24 February 2008, Borislav Petkov wrote:
> On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
[...]
> > kernel: hda: cdrom_pc_intr: The drive appears confused (ireason =
> > 0x01). Trying to recover by ending request.
> > last message repeated 3 times
> > kernel: ide: failed opcode was: unknown
> > kernel: hda: drive not ready for command
> > kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[...]
> > When I saw the recent message from Hans-Peter Jansen about this exact
> > problem, and Boris's comment that something in interrupt land for the
> > CD driver had been fixed, I thought the latest version of the kernel would
> > rectify matters. I installed the 2.6.25-rc2 kernel from kernel.org
> > but the problem
> > is still there.
Does the following patch help?
[ It makes ireason handling for REQ_TYPE_ATA_PC requests be the same as
for other request types so "ireason == 1" quirk is used if needed. ]
---
drivers/ide/ide-cd.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
Index: b/drivers/ide/ide-cd.c
===================================================================
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
* and attempt to recover if there are problems. Returns 0 if everything's
* ok; nonzero if the request has been terminated.
*/
-static
-int ide_cd_check_ireason(ide_drive_t *drive, int len, int ireason, int rw)
+static int ide_cd_check_ireason(ide_drive_t *drive, struct request *rq,
+ int len, int ireason, int rw)
{
/*
* ireason == 0: the drive wants to receive data from us
@@ -701,6 +701,9 @@ int ide_cd_check_ireason(ide_drive_t *dr
drive->name, __FUNCTION__, ireason);
}
+ if (rq->cmd_type == REQ_TYPE_ATA_PC)
+ rq->cmd_flags |= REQ_FAILED;
+
cdrom_end_request(drive, 0);
return -1;
}
@@ -1071,11 +1074,11 @@ static ide_startstop_t cdrom_newpc_intr(
/*
* check which way to transfer data
*/
- if (blk_fs_request(rq) || blk_pc_request(rq)) {
- if (ide_cd_check_ireason(drive, len, ireason, write))
- return ide_stopped;
+ if (ide_cd_check_ireason(drive, rq, len, ireason, write))
+ return ide_stopped;
- if (blk_fs_request(rq) && write == 0) {
+ if (blk_fs_request(rq)) {
+ if (write == 0) {
int nskip;
if (ide_cd_check_transfer_size(drive, len)) {
@@ -1101,16 +1104,9 @@ static ide_startstop_t cdrom_newpc_intr(
if (ireason == 0) {
write = 1;
xferfunc = HWIF(drive)->atapi_output_bytes;
- } else if (ireason == 2 || (ireason == 1 &&
- (blk_fs_request(rq) || blk_pc_request(rq)))) {
+ } else {
write = 0;
xferfunc = HWIF(drive)->atapi_input_bytes;
- } else {
- printk(KERN_ERR "%s: %s: The drive "
- "appears confused (ireason = 0x%02x). "
- "Trying to recover by ending request.\n",
- drive->name, __FUNCTION__, ireason);
- goto end_request;
}
/*
On Mon, Feb 25, 2008 at 3:34 AM, Borislav Petkov
<[email protected]> wrote:
> On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
> >
> > There's nothing in the bios that allows me to move one away from
> > the other. I can 'reserve' or block IRQs, but that only shifts them
> > both to another interrupt.
>
> well the driver probes the bios for that data and assigns the irq line it gets
> from it.
Oh. I thought from all the 'IRQ routing/balancing' and the like in the
kernel there might be a way to switch things around, give the
Realtek driver a different IRQ than the one being used by the ide driver.
Just my crossed-fingers hope.
> Can you please send me your whole boot log of 2.6.25-rc2? Thanks.
It's attached as file 'dmesg.bug.out'.
> since your cdrom seems to be hda from what i've seen above, try booting with
> 'hda=noprobe' or maybe 'hda=none' to see which one turns the probing off for
> you. See Documentation/ide.txt for details.
I tried both options, but in both cases there was no difference; the ide_cd_mod
module was still loaded and the 'confused' message still popped up.
I did four boots/tests of the 2.6.25-rc2 kernel, with and without those
boot parameters ... on all four I had the 'confused' message several times:
hda: cdrom_newpc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.
but in one - the boot with hda=noprobe - I got pages of these
error messages right after:
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ATAPI reset complete
hda: cdrom_decode_status: status=0xc0 { Busy }
ide: failed opcode was: unknown
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete
...
and the system essentially hung. I don't know if that was due to the
'hda=noprobe' or if that extra sensitivity is seen only every now and then.
Bart wrote:
> Does the following patch help?
>
> [ It makes ireason handling for REQ_TYPE_ATA_PC requests be the same as
> for other request types so "ireason == 1" quirk is used if needed. ]
I tried to apply the patch but failed; I probably did something wrong.
I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
log:
root:/usr/src/linux-2.6.25-rc2# pwd
/usr/src/linux-2.6.25-rc2
root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
Index: b/drivers/ide/ide-cd.c
===================================================================
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
* and attempt to recover if there are problems. Returns 0 if everything's
...
...
root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
patching file drivers/ide/ide-cd.c
Hunk #1 FAILED at 670.
Hunk #2 FAILED at 701.
Hunk #3 FAILED at 1074.
Hunk #4 FAILED at 1104.
4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej
Since it found drivers/ide/ide-cd.c I guess I got the '-p' level right (?),
and that's about the sum total of my 'patch' experience to date.
Sorry. Can you tell me what I did wrong?
Cheers,
Brad
On Mon, Feb 25, 2008 at 11:58:57AM +1000, Brad Rosser wrote:
> On Mon, Feb 25, 2008 at 3:34 AM, Borislav Petkov
> <[email protected]> wrote:
> > On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
> > >
> > > There's nothing in the bios that allows me to move one away from
> > > the other. I can 'reserve' or block IRQs, but that only shifts them
> > > both to another interrupt.
> >
> > well the driver probes the bios for that data and assigns the irq line it gets
> > from it.
>
> Oh. I thought from all the 'IRQ routing/balancing' and the like in the
> kernel there might be a way to switch things around, give the
> Realtek driver a different IRQ than the one being used by the ide driver.
> Just my crossed-fingers hope.
>
> > Can you please send me your whole boot log of 2.6.25-rc2? Thanks.
>
> It's attached as file 'dmesg.bug.out'.
>
> > since your cdrom seems to be hda from what i've seen above, try booting with
> > 'hda=noprobe' or maybe 'hda=none' to see which one turns the probing off for
> > you. See Documentation/ide.txt for details.
>
> I tried both options, but in both cases there was no difference; the ide_cd_mod
> module was still loaded and the 'confused' message still popped up.
>
> I did four boots/tests of the 2.6.25-rc2 kernel, with and without those
> boot parameters ... on all four I had the 'confused' message several times:
>
> hda: cdrom_newpc_intr: The drive appears confused (ireason = 0x01).
> Trying to recover by ending request.
Well, this sounds strange. Are you sure you're entering the boot options
correctly on the kernel command line? Which is your boot loader? I just booted
my machine with 'hdc=noprobe' (hdc is my cdrom drive) and here's what i get:
...
[ 0.304774] Probing IDE interface ide0...
[ 0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive
[ 0.613977] Switched to NOHz mode on CPU #1
[ 0.773368] Switched to NOHz mode on CPU #0
[ 0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive
[ 0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[ 0.874506] hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
[ 0.874506] hda: UDMA/33 mode selected
[ 0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[ 0.874620] hdb: UDMA/100 mode selected
[ 0.874744] Probing IDE interface ide1...
-->
[ 0.877750] hdc: ide_wait_not_busy() skipped
-->
[ 1.136180] hdd: IC35L120AVV207-0, ATA DISK drive
[ 1.186959] hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[ 1.186959] hdd: host side 80-wire cable detection failed, limiting max speed to UDMA33
[ 1.186959] hdd: UDMA/33 mode selected
[ 1.186959] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[ 1.194971] ide1 at 0x170-0x177,0x376 on irq 15
[ 1.206876] Probing IDE interface ide2...
[ 1.720661] Probing IDE interface ide3...
[ 2.233564] Probing IDE interface ide4...
[ 2.746462] Probing IDE interface ide5...
[ 3.259395] hda: max request size: 128KiB
[ 3.259571] hda: 39876480 sectors (20416 MB) w/418KiB Cache, CHS=39560/16/63
[ 3.259571] hda: cache flushes not supported
[ 3.259571] hda: hda1 hda2 hda3
[ 3.269291] hdb: max request size: 512KiB
[ 3.269511] hdb: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63
[ 3.269962] hdb: cache flushes supported
[ 3.270078] hdb: hdb1
[ 3.280914] hdd: max request size: 512KiB
[ 3.281247] hdd: 241254720 sectors (123522 MB) w/1821KiB Cache, CHS=16383/255/63
[ 3.281729] hdd: cache flushes supported
[ 3.281729] hdd: hdd1
[ 3.296760] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
...
so it seems you should check whether your kernel is receiving the 'hda=noprobe'
boot option at all, or something along that path is going wrong...
[...]
> I tried to apply the patch but failed; I probably did something wrong.
> I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
> log:
>
> root:/usr/src/linux-2.6.25-rc2# pwd
> /usr/src/linux-2.6.25-rc2
> root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
> Index: b/drivers/ide/ide-cd.c
> ===================================================================
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
> * and attempt to recover if there are problems. Returns 0 if everything's
> ...
> ...
> root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
> patching file drivers/ide/ide-cd.c
> Hunk #1 FAILED at 670.
> Hunk #2 FAILED at 701.
> Hunk #3 FAILED at 1074.
> Hunk #4 FAILED at 1104.
> 4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej
>
> Since it found drivers/ide/ide-cd.c I guess I got the '-p' level right (?),
> and that's about the sum total of my 'patch' experience to date.
> Sorry. Can you tell me what I did wrong?
are you sure you're _really_ using 2.6.25-rc2? Applying the patch against that
kernel works just fine, no fuzziness or even rejects. Care to try out on a fresh
kernel source tarball? After all, building a kernel with your quad core cpu won't
take that long :-) when using make -j8 or something in that order.
--
Regards/Gru?,
Boris.
Hi Boris,
> Well, this sounds strange. Are you sure you're entering the boot options
> correctly on the kernel command line? Which is your boot loader? I just booted
> my machine with 'hdc=noprobe' (hdc is my cdrom drive) and here's what i get:
>
> ...
> [ 0.304774] Probing IDE interface ide0...
> [ 0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive
> [ 0.613977] Switched to NOHz mode on CPU #1
> [ 0.773368] Switched to NOHz mode on CPU #0
> [ 0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive
> [ 0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 0.874506] hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
> [ 0.874506] hda: UDMA/33 mode selected
> [ 0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 0.874620] hdb: UDMA/100 mode selected
> [ 0.874744] Probing IDE interface ide1...
> so it seems you should check whether your kernel is receiving the 'hda=noprobe'
> boot option at all, or something along that path is going wrong...
I'm entering the option 'hda=noprobe' (as one example) right after my boot
label in LILO. The dmesg output I attached last time was a boot of straight
2.6.25-rc2 without any options; I've attached 'dmesg.noprobe.out' which is
the result of a boot with 'hda=noprobe'.
I must have done something stupid, but I can't see what; if you look at this
line from the dmesg output:
Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900
md=0,/dev/sda5,/dev/sdb5 hda=noprobe
... it would suggest the option 'hda=noprobe' was entered correctly?
> > I tried to apply the patch but failed; I probably did something wrong.
> > I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> > and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
> > log:
>
> are you sure you're _really_ using 2.6.25-rc2? Applying the patch against that
> kernel works just fine, no fuzziness or even rejects. Care to try out on a fresh
> kernel source tarball? After all, building a kernel with your quad core cpu won't
> take that long :-) when using make -j8 or something in that order.
Heh. This is my first new machine in 8 years, and I couldn't wait to start
using multiple cores. I was quick to discover the '-j' option ... but I only
do '-j 4'. Anyway ... I'd downloaded the full baseline linux-2.6.24.tar.bz2,
unpacked it, and then ran the patch patch-2.6.25-rc2.bz2 against it. That
patch ran perfectly. And I was in the right directory when I ran Bart's patch,
as I listed in my earlier e-mail! All indications were that I was running the
2.6.25-rc2 kernel as required, I thought.
Well, I see that rc3 is out; maybe I'll give that a shot.
Brad
On Monday 25 February 2008, Brad Rosser wrote:
[...]
> Bart wrote:
>
> > Does the following patch help?
> >
> > [ It makes ireason handling for REQ_TYPE_ATA_PC requests be the same as
> > for other request types so "ireason == 1" quirk is used if needed. ]
>
> I tried to apply the patch but failed; I probably did something wrong.
> I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
> log:
>
> root:/usr/src/linux-2.6.25-rc2# pwd
> /usr/src/linux-2.6.25-rc2
> root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
> Index: b/drivers/ide/ide-cd.c
> ===================================================================
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
> * and attempt to recover if there are problems. Returns 0 if everything's
> ...
> ...
> root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
> patching file drivers/ide/ide-cd.c
> Hunk #1 FAILED at 670.
> Hunk #2 FAILED at 701.
> Hunk #3 FAILED at 1074.
> Hunk #4 FAILED at 1104.
> 4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej
Same command works just fine for me with 2.6.25-rc2/3.
It could be that the patch got damaged somewhere on the way
(to eleminate this possibility I'm attaching it to this mail).
Thanks,
Bart
On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote:
> Hi Boris,
>
> > Well, this sounds strange. Are you sure you're entering the boot options
> > correctly on the kernel command line? Which is your boot loader? I just booted
> > my machine with 'hdc=noprobe' (hdc is my cdrom drive) and here's what i get:
> >
> > ...
> > [ 0.304774] Probing IDE interface ide0...
> > [ 0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive
> > [ 0.613977] Switched to NOHz mode on CPU #1
> > [ 0.773368] Switched to NOHz mode on CPU #0
> > [ 0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive
> > [ 0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> > [ 0.874506] hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
> > [ 0.874506] hda: UDMA/33 mode selected
> > [ 0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> > [ 0.874620] hdb: UDMA/100 mode selected
> > [ 0.874744] Probing IDE interface ide1...
>
> > so it seems you should check whether your kernel is receiving the 'hda=noprobe'
> > boot option at all, or something along that path is going wrong...
>
> I'm entering the option 'hda=noprobe' (as one example) right after my boot
> label in LILO. The dmesg output I attached last time was a boot of straight
> 2.6.25-rc2 without any options; I've attached 'dmesg.noprobe.out' which is
> the result of a boot with 'hda=noprobe'.
>
> I must have done something stupid, but I can't see what; if you look at this
> line from the dmesg output:
>
> Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900
> md=0,/dev/sda5,/dev/sdb5 hda=noprobe
>
> ... it would suggest the option 'hda=noprobe' was entered correctly?
ok, let's try something else: change the line "#if 0" to "#if 1" at the
beginning of kernel/params.c, it looks like:
#if 0
#define DEBUGP printk
#else
#define DEBUGP(fmt, a...)
#endif
rebuild your kernel, and reboot with it. Then, please send me that boot log to
see whether the kernel command line is being received from the boot loader and
what exactly is getting parsed. Thanks.
> > > I tried to apply the patch but failed; I probably did something wrong.
> > > I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> > > and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
> > > log:
> >
> > are you sure you're _really_ using 2.6.25-rc2? Applying the patch against that
> > kernel works just fine, no fuzziness or even rejects. Care to try out on a fresh
> > kernel source tarball? After all, building a kernel with your quad core cpu won't
> > take that long :-) when using make -j8 or something in that order.
>
> Heh. This is my first new machine in 8 years, and I couldn't wait to start
> using multiple cores. I was quick to discover the '-j' option ... but I only
> do '-j 4'. Anyway ... I'd downloaded the full baseline linux-2.6.24.tar.bz2,
> unpacked it, and then ran the patch patch-2.6.25-rc2.bz2 against it. That
> patch ran perfectly. And I was in the right directory when I ran Bart's patch,
> as I listed in my earlier e-mail! All indications were that I was running the
> 2.6.25-rc2 kernel as required, I thought.
>
> Well, I see that rc3 is out; maybe I'll give that a shot.
Please see whether you can apply the patch Bart just sent and if that still gets
mangled and cannot be applied, consider making those changes to ide-cd.c by hand
- after all, there are only several lines that need to be changed so it won't
take that long.
Thanks.
--
Regards/Gru?,
Boris.
Hello Boris, Bart,
On Tue, Feb 26, 2008 at 12:45 AM, Borislav Petkov
<[email protected]> wrote:
>
> On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote:
> >
> > ... it would suggest the option 'hda=noprobe' was entered correctly?
>
> ok, let's try something else: change the line "#if 0" to "#if 1" at the
> beginning of kernel/params.c, it looks like:
>
> #if 0
> #define DEBUGP printk
> #else
> #define DEBUGP(fmt, a...)
> #endif
>
> rebuild your kernel, and reboot with it. Then, please send me that boot log to
> see whether the kernel command line is being received from the boot loader and
> what exactly is getting parsed. Thanks.
Boris, I've done that; the output is in attached file dmesg.debug.out.
It looks to me that the kernel still found the IDE DVD drive (hda) ...
in addition
to the system messages when the system was up I found the ide_cd_mod
module loaded on top of 'cdrom' as normal.
> Please see whether you can apply the patch Bart just sent and if that still gets
> mangled and cannot be applied, consider making those changes to ide-cd.c by hand
> - after all, there are only several lines that need to be changed so it won't
> take that long.
Bart, I was able to apply that patch file you attached with no problems, and the
behaviour of the patched kernel changed as follows:
- no more 'confused' messages, nor the rush of other critical messages
that accompanied a system hang on one out of four tests yesterday.
- However, a new message that popped up twice; once after a few seconds
of network activity, and then about 15-20 seconds afterwards:
hda: ide_cd_check_ireason: wrong transfer direction!
hda: ide_cd_check_ireason: wrong transfer direction!
- also, I'm pretty sure that performance of both network and DVD drive suffered.
As to the last ... my new PC, on which I'm doing all this testing, has a gigabit
Realtek NIC. It's hooked up via null UTP cable to my older machine which has
a 100Mb/s card. ethtool shows that they both auto-negotiate to run at 100Mb/s
full duplex. When I run my network test (pumping through /dev/zero across ssh
from the old machine to the new) the network stats tell me that I'm getting
10MB/s out of the link, which is what I would expect.
With the patched 2.6.25-rc2 kernel running with no activity reading the DVD
but the network going flat out (on the old PC's end) I noted that I was only
getting only 8.0 or 8.1 MB/sec, rather than the 10 MB/sec I've seen in the other
tests.. There was no other network traffic or cpu load on the machine(s).
Then, when I mounted a DVD disc and did a 'wc /mnt/*' of its contents
an iostat showed me that I was getting only about 6MB/sec out of the DVD
drive, which is less than I'd expect. As soon as I killed the network send
iostat's report zoomed up to roughly 10MB/sec. So it seemed to me that,
in addition to the 'wrong direction' messages, I was losing some performance
on both the NIC and the DVD drive.
Regards to you both,
Brad
On Tue, Feb 26, 2008 at 06:32:41PM +1000, Brad Rosser wrote:
Hi Brad,
> Hello Boris, Bart,
>
> On Tue, Feb 26, 2008 at 12:45 AM, Borislav Petkov
> <[email protected]> wrote:
> >
> > On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote:
> > >
> > > ... it would suggest the option 'hda=noprobe' was entered correctly?
> >
> > ok, let's try something else: change the line "#if 0" to "#if 1" at the
> > beginning of kernel/params.c, it looks like:
> >
> > #if 0
> > #define DEBUGP printk
> > #else
> > #define DEBUGP(fmt, a...)
> > #endif
> >
> > rebuild your kernel, and reboot with it. Then, please send me that boot log to
> > see whether the kernel command line is being received from the boot loader and
> > what exactly is getting parsed. Thanks.
>
> Boris, I've done that; the output is in attached file dmesg.debug.out.
it seems that your boot loader is not supplying the kernel with the boot params
properly as can be seen from the excerpt below:
...
Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe
Parsing ARGS: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe
Unknown argument: calling c03670ce
Unknown argument: calling c03670ce
Unknown argument: calling c03670ce
Unknown argument: calling c03670ce
md: Will configure md0 (super-block) from /dev/sda5,/dev/sdb5, below.
Unknown argument: calling c03670ce
...
and, as a result, the probing of hda still takes place.
> It looks to me that the kernel still found the IDE DVD drive (hda) ...
> in addition
> to the system messages when the system was up I found the ide_cd_mod
> module loaded on top of 'cdrom' as normal.
>
> > Please see whether you can apply the patch Bart just sent and if that still gets
> > mangled and cannot be applied, consider making those changes to ide-cd.c by hand
> > - after all, there are only several lines that need to be changed so it won't
> > take that long.
>
> Bart, I was able to apply that patch file you attached with no problems, and the
> behaviour of the patched kernel changed as follows:
>
> - no more 'confused' messages, nor the rush of other critical messages
> that accompanied a system hang on one out of four tests yesterday.
>
> - However, a new message that popped up twice; once after a few seconds
> of network activity, and then about 15-20 seconds afterwards:
>
> hda: ide_cd_check_ireason: wrong transfer direction!
> hda: ide_cd_check_ireason: wrong transfer direction!
Bart, can we assume here that some of the nic interrupts somehow get handled by
ide-cd or something gets mixed up there?
> - also, I'm pretty sure that performance of both network and DVD drive suffered.
>
> As to the last ... my new PC, on which I'm doing all this testing, has a gigabit
> Realtek NIC. It's hooked up via null UTP cable to my older machine which has
> a 100Mb/s card. ethtool shows that they both auto-negotiate to run at 100Mb/s
> full duplex. When I run my network test (pumping through /dev/zero across ssh
> from the old machine to the new) the network stats tell me that I'm getting
> 10MB/s out of the link, which is what I would expect.
>
> With the patched 2.6.25-rc2 kernel running with no activity reading the DVD
> but the network going flat out (on the old PC's end) I noted that I was only
> getting only 8.0 or 8.1 MB/sec, rather than the 10 MB/sec I've seen in the other
> tests.. There was no other network traffic or cpu load on the machine(s).
>
> Then, when I mounted a DVD disc and did a 'wc /mnt/*' of its contents
> an iostat showed me that I was getting only about 6MB/sec out of the DVD
> drive, which is less than I'd expect. As soon as I killed the network send
> iostat's report zoomed up to roughly 10MB/sec. So it seemed to me that,
> in addition to the 'wrong direction' messages, I was losing some performance
> on both the NIC and the DVD drive.
--
Regards/Gru?,
Boris.
Hi,
On Tuesday 26 February 2008, Borislav Petkov wrote:
> On Tue, Feb 26, 2008 at 06:32:41PM +1000, Brad Rosser wrote:
> Hi Brad,
>
> > Hello Boris, Bart,
> >
> > On Tue, Feb 26, 2008 at 12:45 AM, Borislav Petkov
> > <[email protected]> wrote:
> > >
> > > On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote:
> > > >
> > > > ... it would suggest the option 'hda=noprobe' was entered correctly?
> > >
> > > ok, let's try something else: change the line "#if 0" to "#if 1" at the
> > > beginning of kernel/params.c, it looks like:
> > >
> > > #if 0
> > > #define DEBUGP printk
> > > #else
> > > #define DEBUGP(fmt, a...)
> > > #endif
> > >
> > > rebuild your kernel, and reboot with it. Then, please send me that boot log to
> > > see whether the kernel command line is being received from the boot loader and
> > > what exactly is getting parsed. Thanks.
> >
> > Boris, I've done that; the output is in attached file dmesg.debug.out.
>
> it seems that your boot loader is not supplying the kernel with the boot params
> properly as can be seen from the excerpt below:
>
> ...
> Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe
> Parsing ARGS: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe
> Unknown argument: calling c03670ce
> Unknown argument: calling c03670ce
> Unknown argument: calling c03670ce
> Unknown argument: calling c03670ce
> md: Will configure md0 (super-block) from /dev/sda5,/dev/sdb5, below.
> Unknown argument: calling c03670ce
> ...
>
> and, as a result, the probing of hda still takes place.
>
> > It looks to me that the kernel still found the IDE DVD drive (hda) ...
> > in addition
> > to the system messages when the system was up I found the ide_cd_mod
> > module loaded on top of 'cdrom' as normal.
> >
> > > Please see whether you can apply the patch Bart just sent and if that still gets
> > > mangled and cannot be applied, consider making those changes to ide-cd.c by hand
> > > - after all, there are only several lines that need to be changed so it won't
> > > take that long.
> >
> > Bart, I was able to apply that patch file you attached with no problems, and the
> > behaviour of the patched kernel changed as follows:
> >
> > - no more 'confused' messages, nor the rush of other critical messages
> > that accompanied a system hang on one out of four tests yesterday.
> >
> > - However, a new message that popped up twice; once after a few seconds
> > of network activity, and then about 15-20 seconds afterwards:
> >
> > hda: ide_cd_check_ireason: wrong transfer direction!
> > hda: ide_cd_check_ireason: wrong transfer direction!
>
> Bart, can we assume here that some of the nic interrupts somehow get handled by
> ide-cd or something gets mixed up there?
I'm aware of one potential deficiency with shared PCI IRQs:
disable_irq()+enable_irq() usage in ide_do_request() (can be fixed by not
starting the new request from ide_intr() and instead waiting for block layer
to do it) but it doesn't seem to be related...
Besides ide-cd shouldn't get the control if the device is still BUSY...
[ I find it weird that all previous error messages contained ireason == 0x01
while "wrong transfer direction" is triggered by ireason == 0x00/0x02 ? ]
> > - also, I'm pretty sure that performance of both network and DVD drive suffered.
> >
> > As to the last ... my new PC, on which I'm doing all this testing, has a gigabit
> > Realtek NIC. It's hooked up via null UTP cable to my older machine which has
> > a 100Mb/s card. ethtool shows that they both auto-negotiate to run at 100Mb/s
> > full duplex. When I run my network test (pumping through /dev/zero across ssh
> > from the old machine to the new) the network stats tell me that I'm getting
> > 10MB/s out of the link, which is what I would expect.
> >
> > With the patched 2.6.25-rc2 kernel running with no activity reading the DVD
> > but the network going flat out (on the old PC's end) I noted that I was only
> > getting only 8.0 or 8.1 MB/sec, rather than the 10 MB/sec I've seen in the other
> > tests.. There was no other network traffic or cpu load on the machine(s).
Is there any background process polling DVD drive? haldeamon?
If so please stop it and see if it helps.
> > Then, when I mounted a DVD disc and did a 'wc /mnt/*' of its contents
> > an iostat showed me that I was getting only about 6MB/sec out of the DVD
> > drive, which is less than I'd expect. As soon as I killed the network send
> > iostat's report zoomed up to roughly 10MB/sec. So it seemed to me that,
> > in addition to the 'wrong direction' messages, I was losing some performance
> > on both the NIC and the DVD drive.
Thanks for testing it. I merged the patch since it is an improvement over the
old behavior and it is easier to look for full fix with it applied.
Bart