Summary: | CD-ROM Interrupt Problems with 2.6.12-gentoo-r4 kernel | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Lloyd <dmlloyd> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | VERIFIED UPSTREAM | ||
Severity: | normal | CC: | kernel-stuff |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=4920 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
This evil patch fixes my CD-ROM woes, for better or worse.
The fateful dmesg output dmesg output from 2.6.13-rc3 |
Description
David Lloyd
2005-07-16 21:33:16 UTC
Created attachment 63583 [details, diff]
This evil patch fixes my CD-ROM woes, for better or worse.
For the love of all things good, don't submit this to linus.
Created attachment 63584 [details]
The fateful dmesg output
Note the point where I removed the CD module, edited, and reloaded it.
(In reply to comment #0) > I noticed during a Pink Floyd-related emergency that my CD-ROM drive was no longer recognized by my kernel (linux-2.6.12-gentoo-r4). This is a misstatement... I should have said, "my CD-ROM drive was no longer able to read audio CDs". Don't know what I was thinking, duh. Is this reproducable in vanilla-sources-2.6.13_rc3? I'll check it out tonight. hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01) hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01) hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01) hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01) etc. It's back!! will attach dmesg. Created attachment 63782 [details]
dmesg output from 2.6.13-rc3
Ok, looks like an upstream bug. Please file this at http://bugzilla.kernel.org and post the new bug URL here. Ok, well for future reference I guess I will go stright to the main kernel bug list... and since Gentoo aren't following the standard model of supporting their own gentoo-sources kernels, I might as well simply stop using them since it's nothing but a bother for an end-user to have to switch to mainline every time a bug crops up. Also, I see no point in me as an end-user following up on this any further. You can close this bug if you like, or continue tracking it on your own. Just to reply to the previous comment, I feel somewhere you have misunderstood our stance. We strong support our kernels, and any bug which we find, we work on to resolve and submit the fix upstream. When the bug itself relies in the main kernel tree the bug being on gentoo.org is problematic since the awareness upstream has not been raised. If we are able, we will of course fix this locally, note on the upstream bug and contribute as per normal. If you feel this is the incorrect way to approach this then please let me know, either via the bug report or privately via email and I will try and address the issues you bring up. Fair comment, but we do try to support gentoo-sources as best we can. In this case, I tried to reproduce the bug, on my out-of-action laptop, and on my server PC which has a CDROM which hasn't been used for a long time. I searched around looking for people with the same problem as you. I looked at the source code incase anything obvious stands out. If you'd have said 2.6.13-rc3 solved the problem, I'd have spent time reviewing the changes, in search for the solution. When I'd found it, I'd queue it for inclusion in gentoo-sources. Others facing the same problem would then benefit too. If the problem still existed in 2.6.13-rc3 (which it does) then we are at least in a position to report it upstream. If you'll post the bug URL here, I'll tag this bug and monitor it like I do to about 15 other upstream problems that Gentoo have reported. I'll contribute to the upstream bugs if I can. I'll backport any patches that are written there to gentoo-sources. You're correct in saying that reporting a bug to us will usually involve switching over to a clean mainline kernel, and that in most cases, we don't actually fix the problem ourselves - rather, we inform upstream, backport patches, figure out what change caused the problem, etc. However, if the reporter cooperates, we'll almost always get a problem fixed within a decent timeframe. Plus, I think you'll find that you'll have a similar experience on the kernel bugzilla. If someone has a patch, they'll want you to test it, which may well involve changing kernel. Hope that clarifies our stance a little. *** Bug 100764 has been marked as a duplicate of this bug. *** upstream bug closed due to inactivity |