Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Mon, 13 Mar 2006 10:28:57 -0500 Anthony DeRobertis [EMAIL PROTECTED] wrote: Jonas Smedegaard wrote: I believe it is important for yaird to apply same strict logic to all Linux kernels, official or not. Seems perfectly reasonable to me. Thanks. I think the following has been discovered: 1. The ide-generic requirement was added by the modular IDE patch, which Debian included in its kernels. (Thus, kernel.org kernels never had it) 2. The ide-generic requirement is gone as of 2.6.15. I suspect a resolution that satisfies everyone is possible given the above two items. I agree. Do you consider the following a reasonable resolution?: From changelog for yaird 0.0.12-5: * Drop ide-generic workarounds added in 0.0.12-2. This closes: bug#345067 (thanks especially to Jurij Smakov [EMAIL PROTECTED] bug#for his thorough analysis, and to others patiently helping resolve the issues involved). The workarounds turned out to be only needed together with a Debian-specific modular-ide kernel patch (and then needed always - not only with specific drivers). The modular-ide patch has been in use for quite some time but was dropped shortly after the yaird workaround got applied, and since yaird has not yet been part of an official Debian release it is safe to not maintain support for the broken modular-ide patch. From changelog of yaird 0.0.12-6: * Add NEWS item warning about dropped ide-generic workaround, and suggesting a manual alternative (not adding README, as the need for this info should be only temporary). (special note to Sven: no need to reply to this email unless you have _new_ stuff to add. And if you do, then please do not cc me). Regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpdsppUxlEw0.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Version: 0.0.12-5 On Mon, 13 Mar 2006 13:51:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, Ah - for some reason my bug-closing hint in changelog was ignored. How very annoying... - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpXtToDD1i1z.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote: Version: 0.0.12-5 On Mon, 13 Mar 2006 13:51:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, Ah - for some reason my bug-closing hint in changelog was ignored. How very annoying... Probably because you didn't upload it or something ? The -5 upload is not listed in http://packages.qa.debian.org/y/yaird.html, and the -7 upload which is listed doesn't include the -5 and -6 changelog entries, nor did i see those in the mailing list. Not sure what happened about this, but thanks for fixing this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Jonas Smedegaard wrote: Do you consider the following a reasonable resolution?: Sounds fine to me. Though it looks like your changelog entry has been mangled a little: bug#345067 (thanks especially to Jurij Smakov [EMAIL PROTECTED] bug#for -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Tue, 14 Mar 2006 12:07:14 -0500 Anthony DeRobertis [EMAIL PROTECTED] wrote: Jonas Smedegaard wrote: Do you consider the following a reasonable resolution?: Sounds fine to me. Great. :-) Though it looks like your changelog entry has been mangled a little: bug#345067 (thanks especially to Jurij Smakov [EMAIL PROTECTED] bug#for Ah, yes. I can thank the stupid quoting logic of my MUA, Sylpheed, for that one. :-P - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp7Kte256kdE.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote: Version: 0.0.12-5 On Mon, 13 Mar 2006 13:51:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, Ah - for some reason my bug-closing hint in changelog was ignored. How very annoying... BTW, thanks for not crediting the research i did in the changelog entry, and only mentioning Jurij, and then publicly blaming me in the -6 changelog entry. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Tue, 14 Mar 2006 19:55:48 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote: Version: 0.0.12-5 On Mon, 13 Mar 2006 13:51:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, Ah - for some reason my bug-closing hint in changelog was ignored. How very annoying... BTW, thanks for not crediting the research i did in the changelog entry, and only mentioning Jurij, and then publicly blaming me in the -6 changelog entry. Your repeatitive pointing out what big a fool I am gave me the impression that you yourself was handling your own credit. If you are unaware of what I am talking about then have a look at this: http://wiki.debian.org/LinuxKernelIdeProblem?action=diffrev2=23rev1=15 The issue is solved thanks to folks figuring out the kernel actually behave and behaved earlier, not folks claiming that there is no problem. - Jonas P.S. I know, I shouldn't even respond to a message like the above, feeding this irrelevant non-technical fight. sorry - couldn't resist. -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpDq42yEqX0P.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Tue, Mar 14, 2006 at 09:09:45PM +0100, Jonas Smedegaard wrote: On Tue, 14 Mar 2006 19:55:48 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote: Version: 0.0.12-5 On Mon, 13 Mar 2006 13:51:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, Ah - for some reason my bug-closing hint in changelog was ignored. How very annoying... BTW, thanks for not crediting the research i did in the changelog entry, and only mentioning Jurij, and then publicly blaming me in the -6 changelog entry. Your repeatitive pointing out what big a fool I am gave me the impression that you yourself was handling your own credit. If you are unaware of what I am talking about then have a look at this: http://wiki.debian.org/LinuxKernelIdeProblem?action=diffrev2=23rev1=15 The issue is solved thanks to folks figuring out the kernel actually behave and behaved earlier, not folks claiming that there is no problem. Yeah, sure, and before jurij had a look, i didn't spent many hours looking at the code, and following it in detail, and trying to convince you about the issue. I want to remember you that i proposed to do exactly that in erkelenz and was plainly refused, and that normally it should be your responsability as the maintainer of the package to do so. I know, I shouldn't even respond to a message like the above, feeding this irrelevant non-technical fight. sorry - couldn't resist. You know, this is exactly the problem, and i am not the first who thinks it is difficult to work with you on such issues, maybe you should reconsider your part in this, too, don't you think ? At the start of each of those days, i tried to be positive and gave info and looked at the code, and invested time to solve the issue, but invariably as the day passed and you stayed staunch in your refusal to hearing any kind of reason, i went over the border again. This happened not one time, but 4 days in a row. You cannot say that i didn't show positive behavior, and tried to solve the issue. If i where not convinced that you are not a bad guy, i would say that you voluntarily forced me into going over the border, just to ridicoulous me. So i think there was a serious communication problem here, but putting all the blame on me and not aknowledging the work i did to solve the bug is abysmal behavior. I will not post again on this, and i hope that some of the others here will have a word or two with you about this. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
For info, ... It seems that i am to get blamed for everything that went badly after all, and it is perfectly normal for jonas not to aknowledge the effort i put into solving this issue, while he was just ignoring it and putting out random crazy theories for not acting. I am disgusted with how how jonas handled this, and i am not all so happy how all others basically let this happen, and still see me as the evil flammer, and jonas as the good guy, and nobody ever said a word to him about his behavior. I lost many hours to investigate the issue, hours i could have used for RL work instead, and that is all i get over this, i am sorry, and i did get almost no support, except from two persons who will recognize themselves, so i am leaving for some time now, as i have matters of personal nature to handle, and all this frustration lost with so little return is not worth it. Just an (anonymized) quote so as to show you that not everyone is blinded by jonas and his shiny wiki-writing skills : 00:06 *** i had issues with jonas in his *** package long time ago and he is very difficult to talk about issues. So, it has been nice to work on the kernel, but every time jonas got involved, now, but also when i was working on the ramdisk generator issue, it quickly degenerated into a disgusting flamewar. It may be partially my fault, but please go over the events, and the irc logs if you keep them, and don't put all the blame on me. I hope to be able to help again in the (near) future with kernel packaging, once i have time to lose again, and did overcome the personal issues, and maybe by then people will not be so quick to blame me on everything. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Mon, 13 Mar 2006 08:28:12 +0100 Sven Luther [EMAIL PROTECTED] wrote: jonas believes it is more important to not break whatever the user may do, rather than have good support for official kernels, No, I believe those use cases are equally important. I believe it is important for yaird to apply same strict logic to all Linux kernels, official or not. Imagine the tool make failing to compile some software, and you were told that Debian make was optimized for official Debian sourcecode, so the solution is to only use tarballs distributed through Debian. Or the mysql daemon crashing if fed specific SQL commands, and Debian just made sure to not use those commands in official software. That's what your patch was about, Sven: Relaxing the internal logic of yaird for powerpc where you knew it would not hurt - if only the kernels was built by your! - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpDIZrDvqRwO.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Mon, 13 Mar 2006 13:13:42 +0100 Sven Luther [EMAIL PROTECTED] wrote: So, basically, you applied a workaround patch without caution and without understanding fully the issue, while strongly refused when i did the same, and furthermore in a much less intrusive way. Thank you for admitting that much. - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpQiHs1Cej0Z.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Mon, Mar 13, 2006 at 01:34:11PM +0100, Jonas Smedegaard wrote: On Mon, 13 Mar 2006 13:13:42 +0100 Sven Luther [EMAIL PROTECTED] wrote: So, basically, you applied a workaround patch without caution and without understanding fully the issue, while strongly refused when i did the same, and furthermore in a much less intrusive way. Thank you for admitting that much. If you had read the early bug reports, the patch was clearly marked as a quick reversal of the problematic patch, to get the machine booting on pegasos and other powerpc machines with ide pci cards using those drivers, while we took the time to dig at the issue really, and awaited comment from Erik. I think you even commented on that claim (to dismiss my patch though) earlier. Notice that on wednesday, this bug will be open since 3 month, if i am not wrong, and as far as i can see, we are not nearer to getting a fixed yaird than we where then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Jonas Smedegaard wrote: I believe it is important for yaird to apply same strict logic to all Linux kernels, official or not. Seems perfectly reasonable to me. I think the following has been discovered: 1. The ide-generic requirement was added by the modular IDE patch, which Debian included in its kernels. (Thus, kernel.org kernels never had it) 2. The ide-generic requirement is gone as of 2.6.15. I suspect a resolution that satisfies everyone is possible given the above two items. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 09:48:11AM -0500, Anthony DeRobertis wrote: Sven Luther wrote: That means that jonas's fear of breaking self-built kernels is vastly unfunded, and that he should remove those hacks, include a mention of the broken kernels in the README file, and maybe propose a fixed yaird to stable-proposed-updates or something. yaird is not in stable. Alternatively, we could propose a fixed kenrel to stable-proposed-update which removes the herbert-xu modular ide patch. 2.6.8 initrds are not, AFAIK, ever built with yaird. Please not that these two claims are indeed true, but jonas believes it is more important to not break whatever the user may do, rather than have good support for official kernels, and it is thus not excluded that he likes to support people building sarge kernels with yaird, which should be possible. I think it was jurij who tried to do exactly this earlier last week, so i think that it is a possible use-case, altough weird. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, 10 Mar 2006 19:52:42 -0800 (PST) Jurij Smakov [EMAIL PROTECTED] wrote: On Fri, 10 Mar 2006, Jonas Smedegaard wrote: If modular-ide is the sole source of trouble here, then what worked in 2.6.14-4 and earlier? The bugreports seem to indicate that things broke in 2.6.14-5 that worked in 2.6.14-4. And it seems nothing related else than linux-2.6 changed then - not yaird and not kernel-package. I have compared the 2.6.14-4 and 2.6.14-5 linux-2.6 packages. The configs used to build the kernel are almost identical, and the 3 patches added in 2.6.14-5 do not touch anything in the IDE subsystem at all. Both have the modular IDE patch applied. File lists of /lib/modules/[version]/kernel/drivers/ide are exactly the same. Thus, it is pretty unlikely that kernel is the cause of problems with ide-generic. Thanks for clarifying. Are the binary packages available somewhere? It can then be confirmed if postinst (dependent on the version of kernel-package used at packaging time) is identical in those packages - both favoring yaird. Yaird, on the other hand, contains some relevant changes between the last known working version (0.0.11-12) and the broken one (0.0.12-1). Bingo! 0.0.12-1 drops a loose ide-generic workaround, and fixes the yaird bug of sometimes not failing as it should - causing those bugreports to be fatal as dpkg didn't roll back when yaird generated broken images. 0.0.12-2 adds the non-loose ide-generic workaround that hurts Pegasos. The bugreports clearly talk about 0.0.12-1 being used. I was blinded by yaird changelog saying 0.0.12-2 was done only 24 minutes after 0.0.12-1. I guess 0.0.12-2 was not uploaded right away for some reason (probably I wanted to test more and got distracted by real life). Ok, I am now convinced that the yaird ide workarounds (not only for via but also piix and amd) was needed only for Debian-specific modular-ide patch that is now dropped so will not be officially released together with yaird. I will drop the workarounds completely, and believe it will not weaken the strict yaird logic. Thanks alot for all your help and patience with resolving this! - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpxNeHNX9r53.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Thu, 9 Mar 2006, Steve Langasek wrote: What version of the kernel was this analysis done with? The workaround in yaird is explicitly commented as existing for the benefit of older kernel versions; can you assure us that this aspect of the driver design is unchanged from 2.6.8 through 2.6.15? My testing confirms, that 2.6.8 from Debian fails to boot if ide-generic module is not included in initrd: [..] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx pivot_root: No such file or directory /sbin/init: 432: cannot open /dev/console: No such file Kernel panic: Attempted to kill init! When ide-generic is included (it is loaded after all the native ide modules), the kernel boots fine. The reason is that in the Debian 2.6.8 sources the ide-generic initialization procedure contains the call to ide_scan_pcibus(), which actually does the detection of PCI IDE devices. Function probe_for_hwifs() in ide.c contains a call to ide_scan_pcibus() as well, but there it is only called if ide.c is built-in, and not a part of a module (it normally goes into ide-core). So, in Debian's 2.6.8 loading of ide-generic is really essential, and it should be loaded after all the native modules, which just register PCI drivers for specific chipsets. Note that the upstream kernel source does not operate like this. ide-generic does NOT contain a call to ide_scan_pcibus(), this situation is the result of Debian-specific patches, in particular modular IDE patch, originally introduced by Herbert Xu. That patch has been dropped starting with the release of 2.6.15-1 Debian kernel packages, according to changelog. Since then ide_scan_pcibus() in probe_for_hwifs() (which is called by ide_init()) is performed always, irrespectively of whether it is built as a module or not, and there is no call to ide_scan_pcibus() in ide-generic.c. So, if there is a native driver for chipset, it will always work, independently of whether ide-generic is loaded afterwards or not. To summarize: in some cases ide-generic has to be loaded last by initrd to get it to work (when kernel is built from the Debian kernel source, including the modular IDE patch). When it is built from the vanilla source, it is completely optional, given that native drivers exist, but nice to include as a last-resort option if it is present. Unfortunately, I don't see a way to distinguish between these two cases at the time of initrd generation (even though there might be some nm or objdump trick to do that). Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 12:00:50AM -0800, Jurij Smakov wrote: When ide-generic is included (it is loaded after all the native ide modules), the kernel boots fine. The reason is that in the Debian 2.6.8 sources the ide-generic initialization procedure contains the call to ide_scan_pcibus(), which actually does the detection of PCI IDE devices. Function probe_for_hwifs() in ide.c contains a call to ide_scan_pcibus() as well, but there it is only called if ide.c is built-in, and not a part of a module (it normally goes into ide-core). So, in Debian's 2.6.8 loading of ide-generic is really essential, and it should be loaded after all the native modules, which just register PCI drivers for specific chipsets. Note that the upstream kernel source does not operate like this. ide-generic does NOT contain a call to ide_scan_pcibus(), this situation is the result of Debian-specific patches, in particular modular IDE patch, originally introduced by Herbert Xu. Oh, ... So, if i understood you right, this bug was introduced with Herbert Xu's modular IDE patch, and it was ever present only in debian kernel sources, and was dropped for 2.6.15. This means that right now, apart from snapshot.debian.org, it is available exclusively in sarge's 2.6.8 kernel-source package, which is supposed to be used with sarge's initrd-tools anyway, or other sarge ramdisk generation tools. That means that jonas's fear of breaking self-built kernels is vastly unfunded, and that he should remove those hacks, include a mention of the broken kernels in the README file, and maybe propose a fixed yaird to stable-proposed-updates or something. Alternatively, we could propose a fixed kenrel to stable-proposed-update which removes the herbert-xu modular ide patch. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 09:12:42AM +0100, Sven Luther wrote: On Fri, Mar 10, 2006 at 12:00:50AM -0800, Jurij Smakov wrote: When ide-generic is included (it is loaded after all the native ide modules), the kernel boots fine. The reason is that in the Debian 2.6.8 sources the ide-generic initialization procedure contains the call to ide_scan_pcibus(), which actually does the detection of PCI IDE devices. Function probe_for_hwifs() in ide.c contains a call to ide_scan_pcibus() as well, but there it is only called if ide.c is built-in, and not a part of a module (it normally goes into ide-core). So, in Debian's 2.6.8 loading of ide-generic is really essential, and it should be loaded after all the native modules, which just register PCI drivers for specific chipsets. Note that the upstream kernel source does not operate like this. ide-generic does NOT contain a call to ide_scan_pcibus(), this situation is the result of Debian-specific patches, in particular modular IDE patch, originally introduced by Herbert Xu. Oh, ... So, if i understood you right, this bug was introduced with Herbert Xu's modular IDE patch, and it was ever present only in debian kernel sources, and was dropped for 2.6.15. This means that right now, apart from snapshot.debian.org, it is available exclusively in sarge's 2.6.8 kernel-source package, which is supposed to be used with sarge's initrd-tools anyway, or other sarge ramdisk generation tools. That means that jonas's fear of breaking self-built kernels is vastly unfunded, and that he should remove those hacks, include a mention of the broken kernels in the README file, and maybe propose a fixed yaird to stable-proposed-updates or something. Alternatively, we could propose a fixed kenrel to stable-proposed-update which removes the herbert-xu modular ide patch. Oh, yaird is not part of sarge or any previous release. So the question is if we need to support people wanting to use etch/sid yaird with the official sarge kernel, and second if we have to do so at the detriment of the other official kernels. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 08:10:12AM +0100, Sven Luther wrote: I've done a little poking of my own at sysfs based on the comments in the yaird code. I can confirm that it is possible for a PCI IDE driver to be listed as associated with a PCI device without actually being the driver used to access the device. This happens on my alpha, where ide-generic must be used due to bugs in the cmd64x driver, yet running modprobe cmd64x does show this driver associated with the PCI device: $ ls -l /sys/devices/pci\:00/\:00\:0b.0/driver lrwxrwxrwx 1 root root 0 2006-03-09 19:46 /sys/devices/pci:00/:00:0b.0/driver - ../../../bus/pci/drivers/CMD64x_IDE Mmm. When this was happening, could you use and mount partition on this device ? And when doing so, do you know which of ide-generic or cmd64x would be used to read the drive ? Are you suggesting that loading cmd64x has changed which driver is associated with /dev/hda, even though the machine has partitions mounted from it at the time? And again, is the right thing to do here, not to fix those cmd64x bugs ? Um, that's completely missing the point. The point of this exercise was to try to rule out a possible explanation for the yaird workaround. Which I did. However, /sys/block/hda/device still points to the right place, and it's my understanding that /sys/block is what yaird walks, so this still is no explanation for how someone could have mis-identified a bug in this area. How does it find the device and then the driver starting from block ? $ readlink /sys/block/hda/device ../../devices/ide0/0.0 $ So we should expect yaird to only load ide-generic on this system, since cmd64x, while loaded, is not associated with the root device (according to sysfs or otherwise). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 12:40:26AM -0800, Steve Langasek wrote: On Fri, Mar 10, 2006 at 08:10:12AM +0100, Sven Luther wrote: I've done a little poking of my own at sysfs based on the comments in the yaird code. I can confirm that it is possible for a PCI IDE driver to be listed as associated with a PCI device without actually being the driver used to access the device. This happens on my alpha, where ide-generic must be used due to bugs in the cmd64x driver, yet running modprobe cmd64x does show this driver associated with the PCI device: $ ls -l /sys/devices/pci\:00/\:00\:0b.0/driver lrwxrwxrwx 1 root root 0 2006-03-09 19:46 /sys/devices/pci:00/:00:0b.0/driver - ../../../bus/pci/drivers/CMD64x_IDE Mmm. When this was happening, could you use and mount partition on this device ? And when doing so, do you know which of ide-generic or cmd64x would be used to read the drive ? Are you suggesting that loading cmd64x has changed which driver is associated with /dev/hda, even though the machine has partitions mounted from it at the time? No, i am wondering what /sys/devices/pci:00/:00:0b.0/driver was pointing too previous to cm64x being loaded. It seems strange to me that it will not point to what is actually used. Maybe you could just give a ls -l output of the device and block pointers to the module, in all possible cases ( only cmd64x or ide-generic loaded, both loaded in both order) ? And again, is the right thing to do here, not to fix those cmd64x bugs ? Um, that's completely missing the point. The point of this exercise was to try to rule out a possible explanation for the yaird workaround. Which I did. He, ... BTW, did you see Jurij's post, which tracked back all those trouble to the recently dropped Herbert-Xu-modular-ide patch ? However, /sys/block/hda/device still points to the right place, and it's my understanding that /sys/block is what yaird walks, so this still is no explanation for how someone could have mis-identified a bug in this area. How does it find the device and then the driver starting from block ? $ readlink /sys/block/hda/device ../../devices/ide0/0.0 This is the ide-generic node, right ? So we should expect yaird to only load ide-generic on this system, since cmd64x, while loaded, is not associated with the root device (according to sysfs or otherwise). Seems logical, i still wonder aboutthe device driver link above, since it somehow says that cm64x is responsible for this device. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 09:49:18AM +0100, Sven Luther wrote: Mmm. When this was happening, could you use and mount partition on this device ? And when doing so, do you know which of ide-generic or cmd64x would be used to read the drive ? Are you suggesting that loading cmd64x has changed which driver is associated with /dev/hda, even though the machine has partitions mounted from it at the time? No, i am wondering what /sys/devices/pci:00/:00:0b.0/driver was pointing too previous to cm64x being loaded. Nothing: there is no driver associated with the PCI device. And again, is the right thing to do here, not to fix those cmd64x bugs ? Um, that's completely missing the point. The point of this exercise was to try to rule out a possible explanation for the yaird workaround. Which I did. He, ... BTW, did you see Jurij's post, which tracked back all those trouble to the recently dropped Herbert-Xu-modular-ide patch ? Yes. That seems to give most of the answers I was looking for. However, /sys/block/hda/device still points to the right place, and it's my understanding that /sys/block is what yaird walks, so this still is no explanation for how someone could have mis-identified a bug in this area. How does it find the device and then the driver starting from block ? $ readlink /sys/block/hda/device ../../devices/ide0/0.0 This is the ide-generic node, right ? Yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 01:10:27AM -0800, Steve Langasek wrote: On Fri, Mar 10, 2006 at 09:49:18AM +0100, Sven Luther wrote: Mmm. When this was happening, could you use and mount partition on this device ? And when doing so, do you know which of ide-generic or cmd64x would be used to read the drive ? Are you suggesting that loading cmd64x has changed which driver is associated with /dev/hda, even though the machine has partitions mounted from it at the time? No, i am wondering what /sys/devices/pci:00/:00:0b.0/driver was pointing too previous to cm64x being loaded. Nothing: there is no driver associated with the PCI device. Interesting. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Looks like the two days rest is getting irrelevant...) On Fri, 10 Mar 2006 00:00:50 -0800 (PST) Jurij Smakov [EMAIL PROTECTED] wrote: On Thu, 9 Mar 2006, Steve Langasek wrote: What version of the kernel was this analysis done with? The workaround in yaird is explicitly commented as existing for the benefit of older kernel versions; can you assure us that this aspect of the driver design is unchanged from 2.6.8 through 2.6.15? My testing confirms, that 2.6.8 from Debian fails to boot if ide-generic module is not included in initrd: Thanks alot for investigating this, Jurij. When ide-generic is included (it is loaded after all the native ide modules), the kernel boots fine. The reason is that in the Debian 2.6.8 sources the ide-generic initialization procedure contains the call to ide_scan_pcibus(), which actually does the detection of PCI IDE devices. Function probe_for_hwifs() in ide.c contains a call to ide_scan_pcibus() as well, but there it is only called if ide.c is built-in, and not a part of a module (it normally goes into ide-core). So my wild guess of the problem having to do with ide-core being modular (which it isn't on powerpc due to builtin ide-pmac) was not entirely wrong? So, in Debian's 2.6.8 loading of ide-generic is really essential, [...] this situation is the result of Debian-specific patches, in particular modular IDE patch, originally introduced by Herbert Xu. That patch has been dropped starting with the release of 2.6.15-1 Debian kernel packages, according to changelog. Yes. It is also noted as being dropped in 2.6.14-6. The first of my collected[1] Bugreports[2] indicated problems with 2.6.14-5, however, so I suspect either both changelog entries are wrong or there's more to it than the modular-ide patch. I am not trying to escape facts here (I'd be happy for a simple solution) - just trying to asure they are in fact - eh - facts. Regards, - Jonas [1] http://wiki.debian.org/LinuxKernelIdeProblem?action=recallrev=28#head-4146d50632c8d7d20078cdfdbefdad7544b14a8f [2] Bugs #343042 #343048 - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEWLHn7DbMsAkQLgRApcWAJ4pri/o2SwyH2SSS9O2y7wBL1F0rwCfV8Sd T/eQIi7RqnK6UtO09+PXSJc= =A/tx -END PGP SIGNATURE-
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 12:28:07PM +0100, Jonas Smedegaard wrote: That patch has been dropped starting with the release of 2.6.15-1 Debian kernel packages, according to changelog. Yes. It is also noted as being dropped in 2.6.14-6. The first of my collected[1] Bugreports[2] indicated problems with 2.6.14-5, however, so I suspect either both changelog entries are wrong or there's more to it than the modular-ide patch. If the patch was droped in 2.6.14-6, and you had problems with 2.6.14-5, then this is perfectly normal, no ? Or am i missing something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 10 Mar 2006 13:53:18 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Fri, Mar 10, 2006 at 12:28:07PM +0100, Jonas Smedegaard wrote: That patch has been dropped starting with the release of 2.6.15-1 Debian kernel packages, according to changelog. Yes. It is also noted as being dropped in 2.6.14-6. The first of my collected[1] Bugreports[2] indicated problems with 2.6.14-5, however, so I suspect either both changelog entries are wrong or there's more to it than the modular-ide patch. If the patch was droped in 2.6.14-6, and you had problems with 2.6.14-5, then this is perfectly normal, no ? Or am i missing something ? If modular-ide is the sole source of trouble here, then what worked in 2.6.14-4 and earlier? The bugreports seem to indicate that things broke in 2.6.14-5 that worked in 2.6.14-4. And it seems nothing related else than linux-2.6 changed then - not yaird and not kernel-package. It sounds like modular-ide is evil, but if using linux-2.6 changelog entries as evidense of that evil being the (whole) cause of this trouble, it seems natural to expect those entries to make sense. My worry is that perhaps things actually started _breaking_ with the drop of modular-ide. I am not claiming that modular-ide is good, but perhaps it kept together other broken stuff popping up when modular-ide was dropped? The reason I dare persist with these speculations is that I believe we _do_ have alternatives to weakening the yaird logic until certain that is not the case. (deliberately not repeating those here to avoid rebooting the discussion - please say so if interested in me clarifying) Of course if noone but me see a point here (no need to comment unless you _do_ see a point!) then I rest my case. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEY1Sn7DbMsAkQLgRAjZDAJ4gp5GWlfkBoVM7xG/6JYApVHcFjACbBcjk S9xZlnfskKFAKrA/o7jfSYI= =1uJF -END PGP SIGNATURE-
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Sven Luther wrote: That means that jonas's fear of breaking self-built kernels is vastly unfunded, and that he should remove those hacks, include a mention of the broken kernels in the README file, and maybe propose a fixed yaird to stable-proposed-updates or something. yaird is not in stable. Alternatively, we could propose a fixed kenrel to stable-proposed-update which removes the herbert-xu modular ide patch. 2.6.8 initrds are not, AFAIK, ever built with yaird. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Jurij Smakov wrote: That patch has been dropped starting with the release of 2.6.15-1 Debian kernel packages, according to changelog. I tested my 2.6.12 machine last night, and it does indeed require ide-generic. My empirical results agree with your analysis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Friday 10 March 2006 15:29, Jonas Smedegaard wrote: If modular-ide is the sole source of trouble here, then what worked in 2.6.14-4 and earlier? =2.6.12 used initrd-tools and that must still contain the correct magic to deal with this. 2.6.14 was the first kernel tested with yaird and initramfs-tools. Probably -4 was the first to get wide exposure and thus no-one really noticed the issue before then? pgpJTIgzJO9OJ.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, 10 Mar 2006 17:07:34 +0100 Frans Pop [EMAIL PROTECTED] wrote: On Friday 10 March 2006 15:29, Jonas Smedegaard wrote: If modular-ide is the sole source of trouble here, then what worked in 2.6.14-4 and earlier? =2.6.12 used initrd-tools and that must still contain the correct magic to deal with this. 2.6.14 was the first kernel tested with yaird and initramfs-tools. Probably -4 was the first to get wide exposure and thus no-one really noticed the issue before then? If upgrading from 2.6.14-4 to 2.6.14-5 I suspect the user was indeed able to boot a 2.6.14 kernel. Theoretically all those users could of course have been running 2.6.12 and only rebooting after several kernel upgrades, but why would then none of them mention that? I am referring to the bug reports collected at the wiki page. Here's an example: Paulo Marcel Coelho Aragao [EMAIL PROTECTED] in bug#343042: Right after I upgraded linux-image-2.6.14-2-686 to 2.6.14-5 and rebooted, boot is interrupted with repeated messages: /bin/cat: /sys/block/hda/hda1/dev: No such file or directory until it finally stops completely, with message: Device /sys/block/hda/hda1/dev seems to be down I'm having to reboot with 2.6.12. Note the first line of the bugreport. The need to reboot with 2.6.12 is because of the upgrade being irreversible (due to a bug in yaird 0.0.11 making it sometimes not fail on error). The irreversability is actually a fine example of a good use of superstrict yaird: If in the above case the current yaird had been used instead, then the user would not have to roll back to 2.6.12 (or boot from alternative media if not so conveniently having a backup kernel installed and still working). Instead, yaird would have failed and refused to report the install as succesful, causing dpkg to roll back to 2.6.14-4! Put to extremes, it could even be considered a RC bug for kernel packages to use unreliable ramdisk generators like initramfs-tools (and yaird with the discussed patch applied, which causes it to behave like above for powerpc). But all that was for the sake of explaining the reasoning behind stricnes of yaird. I agree that the specific kernel bug is being hunted down now, so no need to mention that the above is close to theoretical. Nut my point of modular-ide not seeming to be the whole issue (if not in reality dropped earlier than documented) persist. - Jonas P.S. Was your dropping the bugreport from recipients intentional? -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpWHVl9mkz10.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, 10 Mar 2006, Jonas Smedegaard wrote:
If modular-ide is the sole source of trouble here, then what worked in
2.6.14-4 and earlier?
The bugreports seem to indicate that things broke in 2.6.14-5 that
worked in 2.6.14-4. And it seems nothing related else than linux-2.6
changed then - not yaird and not kernel-package.
I have compared the 2.6.14-4 and 2.6.14-5 linux-2.6 packages. The
configs used to build the kernel are almost identical, and the 3
patches added in 2.6.14-5 do not touch anything in the IDE subsystem
at all. Both have the modular IDE patch applied. File lists of
/lib/modules/[version]/kernel/drivers/ide are exactly the same. Thus,
it is pretty unlikely that kernel is the cause of problems with
ide-generic.
Yaird, on the other hand, contains some relevant changes between the
last known working version (0.0.11-12) and the broken one (0.0.12-1).
Out of the complete diff between the source the following three hunks
are relevant for ide-generic handling:
--- yaird-0.0.11-12/perl/Hardware.pm2006-03-10 17:28:03.852469888 -0800
+++ yaird-0.0.12-1/perl/Hardware.pm 2005-12-08 14:42:33.0 -0800
[..]
@@ -88,9 +113,42 @@
# Other mac-io devices are not storage related.
$modules = [ mesh ];
}
-
+ elsif ($abspath =~ m!/ide\d+$!) {
+ # IDE bus. On this end of the
+ # cable we normally have on the PCI bus a chipset
+ # controlling the IDE bus, so that the whole looks
+ # like this:
+ # /sys/devices/pci:00/:00:11.1/ide0/0.0
+ # Here the driver for the PCI device will know how
+ # to manage the IDE bus, and there's no need to load
+ # a driver for the bus as such.
+ #
+ # Except that there also is this:
+ # /sys/devices/ide0/0.0
+ # This happens with the ide-generic driver. This
+ # is a driver that manages any PCI/IDE controller,
+ # regardless of device or vendor ID.
+ # The ide-generic driver does not do DMA, which
+ # means it can be an order of magnitude slower than
+ # drivers specific for a chipset. Avoid if possible.
+ # The ide-generic driver will not show the PCI device
+ # in /sys/devices; this is an indicator for yaird to
+ # add ide-generic to the image.
+ #
+ # Note that there is discussion over whether
+ # ide-generic # should grab otherwise unhandled
+ # IDE devices.
+ # -
http://thread.gmane.org/gmane.linux.hotplug.devel/6003
+ # -
http://lists.debian.org/debian-kernel/2004/11/msg00218.h
tml
+ # -
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/145
2.html
+ #
+ if ($i == 0) {
+ $modules = [ ide-generic ];
+ }
+ }
elsif ($abspath =~ m!/ide\d+/\d+\.\d+$!) {
- # IDE device
+ # IDE device - this is the device at the other end
+ # of the cable; normally a disk.
my $dev = IdeDev-new (path = $abspath);
$modules = IdeDev::findModuleByIdeDev ($dev);
}
[..]
@@ -145,6 +205,19 @@
push @{$result}, @{$modules};
}
}
+
+ #
+ # Hmm, via82cxxx (2.6.8) also needs ide-generic
+ # to load it seems. That could be because ide-generic
+ # contains a call to ide_probe_init() which is in
+ # the ide-core module. After loading ide-generic
+ # it's still the via82cxxx module that manages the device;
+ # see /sys/bus/pci/drivers/VIA_IDE/.
+ # The above error persists in 2.6.12, and is solved
+ # in 2.6.14.
+ #
+ $result = [ map { $_ eq via82cxxx ? ($_, ide-generic) : $_ }
@{$result}
];
+
return $result;
}
[..]
--- yaird-0.0.11-12/perl/IdeDev.pm 2005-08-07 13:57:40.0 -0700
+++ yaird-0.0.12-1/perl/IdeDev.pm 2005-12-08 14:42:33.0 -0800
[..]
@@ -108,16 +86,14 @@
my ($ideDev) = @_;
my $media = $ideDev-media();
my $result = [];
- if (! KConfig::isOmitted (ide-generic)) {
- # Supply ide-generic as default chipseet driver only if
- # it was compiled into the kernel.
- push @{$result}, ide-generic;
- }
my $driver;
$driver = ide-disk if ($media eq disk);
$driver = ide-tape if ($media eq tape);
+
+ # The CD may also
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Thu, Mar 09, 2006 at 01:35:23AM -0800, Steve Langasek wrote: On Wed, Mar 08, 2006 at 10:35:38PM -0800, Jurij Smakov wrote: On Thu, 9 Mar 2006, Sven Luther wrote: As quoted from http://wiki.debian.org/LinuxKernelIdeProblem, it is no clear that ide-generic and via82cxxx to take only one example do exactly the same thing, and there is no way both could be needed at the same time, and in fact it is contrary, what do i say, anathema, to both the linux ide layer and the yaird design document, to even imagine that. I've independently done the analysis of the IDE layer initialization and can confirm the technical part of Sven's conclusion: ide-generic takes over all hardware interfaces (hwifs), which do not have the 'present' flag set in their corresponding entry in the ide_hwifs[] structure. Normally, the native IDE drivers set this flag during their initialization (via82cxxx does it through the chain of calls ide_setup_pci_device() - probe_hwif_init_with_fixup() - hwif_init()). So, if ide-generic is loaded last, it will pick up only the interfaces, which have not been claimed by any native drivers, which is the desired result. Looking at the code I cannot see how the native drivers can depend in any way on the ide-generic being loaded before them. What version of the kernel was this analysis done with? The workaround in yaird is explicitly commented as existing for the benefit of older kernel versions; can you assure us that this aspect of the driver design is unchanged from 2.6.8 through 2.6.15? Steve, what is the interest of doing this ? We only have 2.6.15 currently in sid/etch, and sarge uses 2.6.8 together with initrd-tool, so it is a non-issue. And even if there where a bug in older kernel, the ramdisk generator hacks where only there to confuse the issue by hiding the real problem and should thus be backed out. Furthermore, even if this was the case, it was a kernel bug which would have been noticed, and should be fixed ASAP, since it it contrary to the essence itself of the ide-layer and of the yaird design. Finally, please have a look at the current conversation between jonas and zomb on #debian-kernel, and you will clearly understand why this all degenerated such, it seems jonas is incapable of grasping technical arguments and prefers to keep a proven-wrong theory and justify it by all means possible until the opponents just stop caring. I think this was why it degenerated so, because i also have upto a point this defect, altough i know to stop when proven with real technical arguments, which nobody seemed to care about all those past months. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Thu, 9 Mar 2006 11:43:03 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Thu, Mar 09, 2006 at 11:30:47AM +0100, Frans Pop wrote: On Thursday 09 March 2006 07:35, Jurij Smakov wrote: Looking at the code I cannot see how the native drivers can depend in any way on the ide-generic being loaded before them. This has never been the claim. The issue is that the real driver needs to be loaded but that devices will not become visible until after ide-generic is also loaded. The code has proven this to not be the case for 2.6.15 though. ...which proves nothing, except if yaird does the simpler thing of only supporting the newest kernels (as seems to be the approach taken by udev). - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp4eoGjiKoTJ.pgp Description: PGP signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Thu, Mar 09, 2006 at 08:08:04PM -0800, Steve Langasek wrote: On Thu, Mar 09, 2006 at 11:08:33AM +0100, Sven Luther wrote: Steve, what is the interest of doing this ? We only have 2.6.15 currently in sid/etch, and sarge uses 2.6.8 together with initrd-tool, so it is a non-issue. Whether this workaround is needed for older kernels is a technical factor. You may not consider supporting older kernels worthwhile (and neither do I in this case, really), but it's clear that Jonas *does* consider it Yeah, the main problem, is that, at least under my impression, jonas, followed to a lesser degree with Manoj and kernel-package, do believe that self-built kernels are (much) more important than official kernel ones, which i believe is a problem the kernel team and also the release managers will have to deal with. And maybe the technical comittee could give some guidelines there. important; if he didn't, there would obviously be no need to overrule Jonas at this point. Since he does, it's important that we have as much information as possible about this case in order to make an informed decision. Reaching a technical solution that satisfies both parties should *always* be preferred over forcing a maintainer to do something he disagrees with. But even if that's not possible, we still have a responsibility to base our decision on as clear a picture of the evidence as possible. Well, it is my point that if there was such a bug, and there may be one indeed, it is necessary to fix it in the kernel, and not do some workaround in the tools. Failing to do this research has made us delay the understanding of this problem since november or so, which i believe has been painful to everyone. The correct solution for the tools who wish to support older and known broken kernels is probably not to do some hacky and half understood workaround, but to document the issue in an errata document, and let the user live with the consequences. I've done a little poking of my own at sysfs based on the comments in the yaird code. I can confirm that it is possible for a PCI IDE driver to be listed as associated with a PCI device without actually being the driver used to access the device. This happens on my alpha, where ide-generic must be used due to bugs in the cmd64x driver, yet running modprobe cmd64x does show this driver associated with the PCI device: $ ls -l /sys/devices/pci\:00/\:00\:0b.0/driver lrwxrwxrwx 1 root root 0 2006-03-09 19:46 /sys/devices/pci:00/:00:0b.0/driver - ../../../bus/pci/drivers/CMD64x_IDE Mmm. When this was happening, could you use and mount partition on this device ? And when doing so, do you know which of ide-generic or cmd64x would be used to read the drive ? And again, is the right thing to do here, not to fix those cmd64x bugs ? However, /sys/block/hda/device still points to the right place, and it's my understanding that /sys/block is what yaird walks, so this still is no explanation for how someone could have mis-identified a bug in this area. How does it find the device and then the driver starting from block ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
