Hey folks,
I think I may have found a bug in the Linux IDE subsystem
introduced in 2.4.21 and still present in 2.4.22.
SHORT SYNOPSIS: I played with various combinations of drivers, and no
matter what I do I can only get ONE of the IDE controllers in my machine
recognized at a time. I find this in both 2.4.21 and 2.4.22.
Howerver, 2.4.20 and prior were NOT affected.
Anyway, I have 4 IDE disks in my system, each of which is one its own
chain, so I'm using both the onboard controller as well as a PCI IDE card.
Thus my system looks like this:
On-Board IDE
IDE0 Primary: HD
Secondary: -
IDE1 Primary: DVD
Secondary: -
PCI Card IDE
IDE2 Primary: CDRW
Secondary: -
IDE3 Primary: ZIP
Secondary: -
My On-Board is, according to lspci, a:
VIA VT82C586/B/686A/B PIPC Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
My PCI card is, according to lspci, a:
CMD Technology Inc PCI0649 (rev 02)
Up until (and including) 2.4.20, my kernel IDE configuration has always
looked like
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
The noteworthy thing about the above is that I'm NOT enabling CMD64X -- the
CMD640 has always handled the CMD649 PCI IDE controller just fine.
As of 2.4.21, this configuration no longer works -- which is not necessarily
a bug. I'm almost there, stay with me. =)
So the PCI IDE card isn't recognized with the above configuration. So I decided
to enable the CMD64X driver. This caused my PCI IDE card to be recognized BUT
as a side effect, my onboard controller was *NOT* recognized!! At this point
I had built the CMD64X driver into the kernel.
So my next experiment was to build CMD64X as a module instead. At this point
the PCI IDE controller wasn't recognized on boot -- as expected. I then
manually loaded the CMD64X driver and it .. "unrecognized" my onboard
controller *reassigning* ide0 and ide1 to the chains on the PCI card and no
longer seeing the onboard controller (and thus unable to find the HD, and...)
That, I believe is a bug in ... possibly the driver, or possibly the IDE
subsystem, I'm not sure.
Some other general information that might be useful:
Debian Unstable
lspci -v of onboard:
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master
IDE (rev 06) (prog-if 8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at c000 [size=16]
Capabilities: [c0] Power Management version 2
lspci -v of PCI IDE:
00:0a.0 RAID bus controller: CMD Technology Inc PCI0649 (rev 02)
Subsystem: CMD Technology Inc PCI0649
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at d800 [size=8]
I/O ports at dc00 [size=4]
I/O ports at e000 [size=8]
I/O ports at e400 [size=4]
I/O ports at e800 [size=16]
Expansion ROM at <unassigned> [disabled] [size=512K]
Capabilities: [60] Power Management version 2
All kernels are stock kernel.org kernels.
If I can provide any more information, run any tests, or be of any help, please
let me know. Any help or thoughts you can provide would be much appreciated.
Thanks,
--
Phil Dibowitz [email protected]
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
On Tuesday 09 of September 2003 00:51, Phil Dibowitz wrote:
> Hey folks,
>
> I think I may have found a bug in the Linux IDE subsystem
> introduced in 2.4.21 and still present in 2.4.22.
Nope, user error :-).
> SHORT SYNOPSIS: I played with various combinations of drivers, and no
> matter what I do I can only get ONE of the IDE controllers in my machine
> recognized at a time. I find this in both 2.4.21 and 2.4.22.
> Howerver, 2.4.20 and prior were NOT affected.
<...>
> Up until (and including) 2.4.20, my kernel IDE configuration has always
> looked like
>
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECD=m
> CONFIG_BLK_DEV_IDEFLOPPY=m
> CONFIG_BLK_DEV_IDESCSI=m
> CONFIG_BLK_DEV_CMD640=y
> CONFIG_BLK_DEV_CMD640_ENHANCED=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_BLK_DEV_ADMA=y
> CONFIG_BLK_DEV_PIIX=y
> CONFIG_PIIX_TUNING=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_BLK_DEV_IDE_MODES=y
>
> The noteworthy thing about the above is that I'm NOT enabling CMD64X -- the
> CMD640 has always handled the CMD649 PCI IDE controller just fine.
Nope, your CMD649 was handled by generic PCI IDE driver.
> As of 2.4.21, this configuration no longer works -- which is not
> necessarily a bug. I'm almost there, stay with me. =)
Assumption that current .config will work with future kernel versions is *false*.
Just add these two lines to your .config:
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_CMD64X=y
> So the PCI IDE card isn't recognized with the above configuration. So I decided
> to enable the CMD64X driver. This caused my PCI IDE card to be recognized BUT
> as a side effect, my onboard controller was *NOT* recognized!! At this point
> I had built the CMD64X driver into the kernel.
Your VIA IDE controller was handled by generic IDE chipset driver which
did probe devices *after* PCI controllers are probed, so CMD649 took
ide0 and ide1 first.
--bartlomiej
Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 09 of September 2003 00:51, Phil Dibowitz wrote:
>
>>Hey folks,
>>
>>I think I may have found a bug in the Linux IDE subsystem
>>introduced in 2.4.21 and still present in 2.4.22.
>
>
> Nope, user error :-).
I thought there was a reasonable chance of that! =)
> Nope, your CMD649 was handled by generic PCI IDE driver.
Ah, OK. Makes sense.
>>As of 2.4.21, this configuration no longer works -- which is not
>>necessarily a bug. I'm almost there, stay with me. =)
>
> Assumption that current .config will work with future kernel versions is *false*.
Agreed. I said that wasn't a bug. =)
> Just add these two lines to your .config:
> CONFIG_BLK_DEV_VIA82CXXX=y
> CONFIG_BLK_DEV_CMD64X=y
Doh!! Didn't see the VIA driver down there at the bottom. Double doh! My
appologies, I should have been able to figure that out.
That works quite well, thank you! Still have a question though...
> Your VIA IDE controller was handled by generic IDE chipset driver which
> did probe devices *after* PCI controllers are probed, so CMD649 took
> ide0 and ide1 first.
But, what about the case when I built in the generic driver, but made
the CMD649 driver a module, and loaded it after boot. That shouldn't
have *changed* what ide0 and ide1 are, right? I had ide0 and ide1
assigned, did a modprobe, and CMD649 changed what ide0 adn ide1 where,
and then forgot about the previous ones.. like all of a sudden it told
the generic driver "no, no, you were wrong, there's no VIA chipset here,
go back to sleep."
I may well be misunderstanding something precedence in the kernel here,
but I figured while I'm bugging you, I might as well get the full picture.
Thanks for your time!
--
Phil Dibowitz [email protected]
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
On Tuesday 09 of September 2003 16:33, Phil Dibowitz wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 09 of September 2003 00:51, Phil Dibowitz wrote:
> >>Hey folks,
> >>
> >>I think I may have found a bug in the Linux IDE subsystem
> >>introduced in 2.4.21 and still present in 2.4.22.
> >
> > Nope, user error :-).
>
> I thought there was a reasonable chance of that! =)
>
> > Nope, your CMD649 was handled by generic PCI IDE driver.
>
> Ah, OK. Makes sense.
>
> >>As of 2.4.21, this configuration no longer works -- which is not
> >>necessarily a bug. I'm almost there, stay with me. =)
> >
> > Assumption that current .config will work with future kernel versions is
> > *false*.
>
> Agreed. I said that wasn't a bug. =)
>
> > Just add these two lines to your .config:
> > CONFIG_BLK_DEV_VIA82CXXX=y
> > CONFIG_BLK_DEV_CMD64X=y
>
> Doh!! Didn't see the VIA driver down there at the bottom. Double doh! My
> appologies, I should have been able to figure that out.
>
> That works quite well, thank you! Still have a question though...
No problem, thanks for report.
> > Your VIA IDE controller was handled by generic IDE chipset driver which
> > did probe devices *after* PCI controllers are probed, so CMD649 took
> > ide0 and ide1 first.
>
> But, what about the case when I built in the generic driver, but made
> the CMD649 driver a module, and loaded it after boot. That shouldn't
> have *changed* what ide0 and ide1 are, right? I had ide0 and ide1
> assigned, did a modprobe, and CMD649 changed what ide0 adn ide1 where,
> and then forgot about the previous ones.. like all of a sudden it told
> the generic driver "no, no, you were wrong, there's no VIA chipset here,
> go back to sleep."
Hmm. please send me dmesg.
--bartlomiej
> I may well be misunderstanding something precedence in the kernel here,
> but I figured while I'm bugging you, I might as well get the full picture.
>
> Thanks for your time!
Bartlomiej Zolnierkiewicz wrote:
>>But, what about the case when I built in the generic driver, but made
>>the CMD649 driver a module, and loaded it after boot. That shouldn't
>>have *changed* what ide0 and ide1 are, right? I had ide0 and ide1
>>assigned, did a modprobe, and CMD649 changed what ide0 adn ide1 where,
>>and then forgot about the previous ones.. like all of a sudden it told
>>the generic driver "no, no, you were wrong, there's no VIA chipset here,
>>go back to sleep."
>
>
> Hmm. please send me dmesg.
>
I'm happy to. Assumably you want both a Dmesg of my new working kernel,
and a dmesg of above described kernel? Note that the dmesg from the
later kernel be before loading the CMD64X modules, because when I do
that, I loose my hard drive. Therefore it'll look mostly like my working
one, except with no ide2 and ide3.
I've gone ahead and posted the current working dmesg here:
http://www.phildev.net/dmesg-working
I'll have to do the non-working kernel when I get back from work. I'll
drop a line when I get that posted.
Thanks,
--
Phil Dibowitz [email protected]
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
Bartlomiej Zolnierkiewicz wrote:
>>But, what about the case when I built in the generic driver, but made
>>the CMD649 driver a module, and loaded it after boot. That shouldn't
>>have *changed* what ide0 and ide1 are, right? I had ide0 and ide1
>>assigned, did a modprobe, and CMD649 changed what ide0 adn ide1 where,
>>and then forgot about the previous ones.. like all of a sudden it told
>>the generic driver "no, no, you were wrong, there's no VIA chipset here,
>>go back to sleep."
>
>
> Hmm. please send me dmesg.
OK,
I've posted the following:
GOOD WORKING CONFIG
http://phildev.net/config-working
GOOD WORKING DMESG
http://phildev.net/dmesg-working
NON WORKING CONFIG
http://phildev.net/config-bad
NON WORKING DMESG
http://phildev.net/dmesg-bad
As a recap...
For the non-working config, when I boot, the onboard VIA is recognized
by the generic IDE driver, and then I did the dmesg, and then I
modprobed CMD64X and it **reasigned** ide0 and ide1 to the PCI IDE
card's chains and the original ide0 and ide1 disappeared, I therefore
lost my hard drive, and the machine becomes unresponsive. I think that
**might** be a bug in the CMD64X driver?
If I can provide more info, please let me know. I've kept the other
kernel around so that I may boot into it if need be.
And as I said before, compiling hte VIA and CMD drivers both into the
works fine on my machine, and I appreciate help getting that working,
but I would like to either understand the above behavior, or know its a
bug, or...
Thanks again for all your help. It really is much appreciated.
--
Phil Dibowitz [email protected]
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759