Summary: | kernel 2.6.24 regression in libata - 'drive not ready for command' - cd rom related (BenQ and Plextor drives) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maciej Mrozowski <reavertm> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | tapted |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=10239 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maciej Mrozowski
2008-03-16 18:14:00 UTC
upps. about that link to git commit - it may be actually commit intruducing this problem more info: http://readlist.com/lists/vger.kernel.org/linux-kernel/93/465595.html and similar problem here: http://www.gossamer-threads.com/lists/linux/kernel/841704 it seems that 2.6.24 is rather an experimental release (http://kerneltrap.org/mailarchive/linux-kernel/2008/1/24/603479) introducing many new features (like tickless kernel) and some regressions in ide module as well, maybe whole 2.6.24 should be avoided on stable gentoo-sources releases for now (In reply to comment #1) > maybe whole 2.6.24 should be avoided on stable gentoo-sources releases > for now Yah. Same problem here -- 2.6.24 is unusable on at least one of my Gentoo machines. Haven't been game to try it out an any others. Old behaviour (2.6.23): Mar 15 00:57:06 [kernel] hda: PHILIPS DVD+/-RW DVD8801, ATAPI CD/DVD-ROM drive Mar 15 00:57:06 [kernel] hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) Mar 17 18:33:41 [kernel] ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio New behaviour (2.6.24): Mar 17 18:33:41 [kernel] ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio Mar 17 18:33:41 [kernel] hda: PHILIPS DVD+/-RW DVD8801, ATAPI CD/DVD-ROM drive Mar 17 18:33:41 [kernel] hda: UDMA/33 mode selected Mar 17 18:33:41 [kernel] hda: lost interrupt Mar 17 18:33:41 [kernel] hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: task_in_intr: error=0x00 { } Mar 17 18:33:41 [kernel] hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: status error: error=0x00 { } Mar 17 18:33:41 [kernel] hda: drive not ready for command Mar 17 18:33:41 [kernel] hda: ATAPI CD-ROM drive, 0kB Cache Mar 17 18:33:41 [kernel] hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: status error: error=0x00 { } Mar 17 18:33:41 [kernel] hda: drive not ready for command Mar 17 18:33:41 [kernel] hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: status error: error=0x00 { } Mar 17 18:33:41 [kernel] hda: drive not ready for command Mar 17 18:33:41 [kernel] hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: status error: error=0x00 { } Mar 17 18:33:41 [kernel] hda: drive not ready for command Mar 17 18:33:41 [kernel] hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error } Mar 17 18:33:41 [kernel] hda: status error: error=0x00 { } Mar 17 18:33:41 [kernel] hda: drive not ready for command ... repeats continuously. CD-ROM drive unusable -- doesn't even eject. Thanks for the links, hopefully a fix will come through from kernel devs soon. But, I'd really suggest re-masking 2.6.24-3 can either of you confirm that you're hitting the same bug? i.e. reverting the above mentioned commit solves the problem? (In reply to comment #3) > can either of you confirm that you're hitting the same bug? i.e. reverting the > above mentioned commit solves the problem? Yes. I can confirm that reverting that commit fixed the problem for me. Sorry if this is a bit ad-hoc (a reverse patch didn't apply cleanly), and I'm testing this remotely.. But after patching with: pc-306-1 linux # cat rollback.patch --- drivers/ide/ide-probe.c.before 2008-03-18 22:07:21.000000000 +1100 +++ drivers/ide/ide-probe.c 2008-03-18 22:07:50.000000000 +1100 @@ -774,7 +774,7 @@ /* * Need to probe slave device first to make it release PDIAG-. */ - for (unit = MAX_DRIVES - 1; unit >= 0; unit--) { + for (unit = 0; unit < MAX_DRIVES; ++unit) { ide_drive_t *drive = &hwif->drives[unit]; drive->dn = (hwif->channel ? 2 : 0) + unit; (void) probe_for_drive(drive); I no longer get errors in dmesg. And eject eject -t worked fine .. but I can't actually *see* the CD-ROM drive until tomorrow.. ok, thanks, will track the upstream bug I can also confirm, that reverting back this commit fixes this problem with 2.6.24-r3 on my machine with BenQ drive on master channel. Maybe it would be necessary to test and swap drives so that BenQ would be slave and check, whether is there any problem with kernel with reverted commit. So, I just accidentally booted off linux-2.6.24-gentoo-r8 without patching it and encountered the same problem. So I decided to give 2.6.25 a go (linux-2.6.25-gentoo-r4), and the regression seems to be gone. However, the upstream bug does not yet reflect this: http://bugzilla.kernel.org/show_bug.cgi?id=10239 |