Kernel Bug Tracker – Bug 9590
CMD646 & cdrom: drive appears confused & drive not ready for command
Last modified: 2008-01-02 14:21:51 UTC
Subject : CMD646 & cdrom: drive appears confused & drive not ready for command
Submitter : Meelis Roos <email@example.com>
References : http://lkml.org/lkml/2007/12/16/99
Handled-By : Andrew Morton <firstname.lastname@example.org>
Refael, please turn off "Regression" flag because there is no confirmation yet that this is a regression.
[ I tried to do it myself but... "You tried to change the Regression field from
1, but only the assignee or reporter of the bug, or a sufficiently empowered
user may change that field." - kernel bugzilla is FPOS holds... sigh... ]
PS1 The problem seems to be caused by hald stupidity... :(
PS2 I'm in the process of re-writting ide-cd right now (57 patches and counting, not yet posted) and I see a possible fix for this particular problem - attached, may not apply/work etc. We _really_ need to put ide-cd into debuggable & maintainable state before investing more time into handling bugreports (but it is if course worth to keep them logged)...
Update: Sorry Meelis, I was too optimistic - the possible fix already depends on 3 patches from the ide-cd re-write alone (not counting patches from IDE tree)...
Please be patient, I hope to finish this patch series soon (== before Christmas).
Anyway - back to patches...
Should have been:
Tried 2.6.23, so far it behaves fine, so it really seems to be a regression.
How can it be a hal stupidity - hal just polls the device, why would a driver make the driver confused? Yes, hal is dumbt to poll it every 2 sec but this hould not break it.
> Tried 2.6.23, so far it behaves fine, so it really seems to be a regression.
Thanks for update. I went through post-2.6.23 ide-cd and cmd646 commits but unfortunately there are no likely "guilty" candidates. Would it be possible to narrow the problem down? (For starters it would be useful to know if 2.6.24-rc1 is OK, then you would need to proceed with git-bisect).
> How can it be a hal stupidity - hal just polls the device, why would a driver
> make the driver confused? Yes, hal is dumbt to poll it every 2 sec but this
> hould not break it.
Yeah, that is what I was referring to. You are of course right that it shouldn't confuse the drive and that it is a bug that needs fixing.
I booted up the latest 2.6.24-rc6+git kernel (with the CMD646 updates
applied) and the problem has not reappeared in 2 days 53 min uptime.
Will see again on January 2 but so far it seems it has been fixed.
Yep, no errors in 5 days uptime.
I think that it is thanks to a recent cmd646 regression bugfix:
Author: Bartlomiej Zolnierkiewicz <email@example.com>
Date: Mon Dec 24 15:23:44 2007 +0100
cmd64x: fix hwif->chipset setup
commit 528a572daea90aa41db92683e5a8756acef514c4 ("ide: add ->chipset field
to ide_pci_device_t") broke hwif->chipset setup (it is now set to ide_cmd646
for CMD648 instead of CMD646). It seems that the breakage happend while
I was moving patches around (cmd64x_chipsets entries for CMD646 and CMD648
are identical except for 'name' field). Fix it and bump driver version.
Cc: Sergei Shtylyov <firstname.lastname@example.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <email@example.com>
[ the bug was found by accident while I was fixing some other stuff ]
Thanks for confirmation and sorry for breaking it in the first place.