Re: Problem with ata layer in 2.6.24
On Mon, Jan 28, 2008 at 08:31:57PM -0500, Gene Heskett wrote: > > In my script, its one line: > mkinitrd -f initrd-$VER.img $VER && \ > > where $VER is the shell variable I edit to = the version number, located at > the top of the script. > > Unforch, its failing: > No module pata_amd found for kernel 2.6.24, aborting. mkinitrd is just a shell script. Even if its options, and there is a quite a number of these, do not allow to influence a choice of modules in a desired manner, it is pretty trivial to make yourself a custom version of it and just hardwire there a fixed list of modules to use instead of relying on general mechanisms which are trying hard to guess what you may need. That way your regular 'mkinitrd' will build something to boot with libata and 'mkinird.ide' will use IDE modules for that purpose using the same "core" kernel. If you are using distribution kernels, as opposed to your own configuration, it is quite likely that you will need to install 'kernel-devel' package and recompile and add required IDE modules yourself as those may be not provided. This is done the same way like for any other "external" module. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ata layer in 2.6.24
On Mon, Jan 28, 2008 at 08:31:57PM -0500, Gene Heskett wrote: In my script, its one line: mkinitrd -f initrd-$VER.img $VER \ where $VER is the shell variable I edit to = the version number, located at the top of the script. Unforch, its failing: No module pata_amd found for kernel 2.6.24, aborting. mkinitrd is just a shell script. Even if its options, and there is a quite a number of these, do not allow to influence a choice of modules in a desired manner, it is pretty trivial to make yourself a custom version of it and just hardwire there a fixed list of modules to use instead of relying on general mechanisms which are trying hard to guess what you may need. That way your regular 'mkinitrd' will build something to boot with libata and 'mkinird.ide' will use IDE modules for that purpose using the same core kernel. If you are using distribution kernels, as opposed to your own configuration, it is quite likely that you will need to install 'kernel-devel' package and recompile and add required IDE modules yourself as those may be not provided. This is done the same way like for any other external module. Michal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20.6 vanilla does't boot
On Wed, Apr 18, 2007 at 03:39:25PM -0400, Len Brown wrote: > On Sunday 15 April 2007 11:50, Michal Jaegermann wrote: > > > > A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from > > Fedora "rawhide" to be more precise) did boot on the hardware in > > question, though; but only when I gave it 'acpi=off'. Without that > > parameter it was getting stuck apparently when starting hotplug. > > In that kernel case disks were accessed using pata_atiixp driver. > > If "acpi=off" is necessary to boot the latest kernel, please > report an ACPI bug: > http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI I now travel and what I can do at this moment is somewhat limited. In particular I cannot gain an access to the hardware in question. But please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232490 and the most recent comments there in particular. > Please mention in the bug report what the latest working kernel was. This is mentioned in the referenced report as well. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20.6 vanilla does't boot
On Wed, Apr 18, 2007 at 03:39:25PM -0400, Len Brown wrote: On Sunday 15 April 2007 11:50, Michal Jaegermann wrote: A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from Fedora rawhide to be more precise) did boot on the hardware in question, though; but only when I gave it 'acpi=off'. Without that parameter it was getting stuck apparently when starting hotplug. In that kernel case disks were accessed using pata_atiixp driver. If acpi=off is necessary to boot the latest kernel, please report an ACPI bug: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI I now travel and what I can do at this moment is somewhat limited. In particular I cannot gain an access to the hardware in question. But please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232490 and the most recent comments there in particular. Please mention in the bug report what the latest working kernel was. This is mentioned in the referenced report as well. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20.6 vanilla does't boot
On Fri, Apr 13, 2007 at 03:38:18PM +0400, Denis Kirjanov wrote: > I updated the BIOS to the latest version, but the problem persists. > Boots option pci = noacpi not solved the problem. Reporting bios bug > disappears when setting pci = nommconf, But the kernel is still not > loaded ( On x86_64 hardware using ata_piix I was unable to boot kernels based on the current 2.6.20.x either. Regardless of extra kernel parameters used I was getting consistently 'hdc: lost interrupt', and/or similar and after something like that the whole machine was dead. The only differences were if I could still reboot from a keyboard or if I really have to pull a plug. A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from Fedora "rawhide" to be more precise) did boot on the hardware in question, though; but only when I gave it 'acpi=off'. Without that parameter it was getting stuck apparently when starting hotplug. In that kernel case disks were accessed using pata_atiixp driver. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20.6 vanilla does't boot
On Fri, Apr 13, 2007 at 03:38:18PM +0400, Denis Kirjanov wrote: I updated the BIOS to the latest version, but the problem persists. Boots option pci = noacpi not solved the problem. Reporting bios bug disappears when setting pci = nommconf, But the kernel is still not loaded ( On x86_64 hardware using ata_piix I was unable to boot kernels based on the current 2.6.20.x either. Regardless of extra kernel parameters used I was getting consistently 'hdc: lost interrupt', and/or similar and after something like that the whole machine was dead. The only differences were if I could still reboot from a keyboard or if I really have to pull a plug. A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from Fedora rawhide to be more precise) did boot on the hardware in question, though; but only when I gave it 'acpi=off'. Without that parameter it was getting stuck apparently when starting hotplug. In that kernel case disks were accessed using pata_atiixp driver. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.21-rc5: known regressions (v2)
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote: > On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote: > > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: > > > > > > Subject: kernels fail to boot with drives on ATIIXP controller > > > (ACPI/IRQ related) > > > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 > > > http://lkml.org/lkml/2007/3/4/257 > > > Submitter : Michal Jaegermann <[EMAIL PROTECTED]> > > > Status : unknown > > > > I have now even better one with pata_via. A kernel, which for > > all practical purposes is 2.6.21-rc5, not only refuses to boot > > (and I cannot find some option combination which would allow me to > > do so anyway) but simply refuses to read _any_ data from a media. > > This included a partitioning information. > > > > Earlier kernel on the same hardware boots without raising any fuss. > > > > Details are collected as > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650 > > If I understand this correctly, a plain 2.6.20 kernel is already broken? You mean that a quoted report talks about 2.6.20-1.3025.fc7 kernel? These are vagaries of kernel version numbering in Fedora. Changelogs are not that clear but it appears that 2.6.19-1.2911.6.4.fc6 will be actually closer to 2.6.20. That kernel from a bug report is really, for all intents and purposes, 2.6.21-rc5 (if I am not misreading something). I am afraid that I do not have at this moment an easy to way to check "plain" 2.6.20 on the hardware in question. It appears that the essential difference is that a working kernel is using and old IDE driver, and sees the drive - in this case - as /dev/hdc, while the current one tries to go through libata and chockes uncontrollably. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.21-rc5: known regressions (v2)
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote: On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote: On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information. Earlier kernel on the same hardware boots without raising any fuss. Details are collected as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650 If I understand this correctly, a plain 2.6.20 kernel is already broken? You mean that a quoted report talks about 2.6.20-1.3025.fc7 kernel? These are vagaries of kernel version numbering in Fedora. Changelogs are not that clear but it appears that 2.6.19-1.2911.6.4.fc6 will be actually closer to 2.6.20. That kernel from a bug report is really, for all intents and purposes, 2.6.21-rc5 (if I am not misreading something). I am afraid that I do not have at this moment an easy to way to check plain 2.6.20 on the hardware in question. It appears that the essential difference is that a working kernel is using and old IDE driver, and sees the drive - in this case - as /dev/hdc, while the current one tries to go through libata and chockes uncontrollably. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.21-rc5: known regressions (v2)
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: > > Subject: kernels fail to boot with drives on ATIIXP controller > (ACPI/IRQ related) > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 > http://lkml.org/lkml/2007/3/4/257 > Submitter : Michal Jaegermann <[EMAIL PROTECTED]> > Status : unknown I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information. Earlier kernel on the same hardware boots without raising any fuss. Details are collected as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650 Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.21-rc5: known regressions (v2)
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information. Earlier kernel on the same hardware boots without raising any fuss. Details are collected as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650 Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:36AM +0100, Adrian Bunk wrote: > This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 > that are not yet fixed in Linus' tree. > Subject: kernels fail to boot with drives on ATIIXP controller > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 > Submitter : Michal Jaegermann <[EMAIL PROTECTED]> > Status : unknown Alan added comment to my posting that my problems are caused by messed up IRQ routing on that box I tried. Indeed, I can boot kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided I will use 'acpi=off irqpoll'. Anything else and a boot silently dies if 'acpi=off' is skipped or is not finding disk if 'irqpoll' is missing. Somehow 2.6.19 is booting on the same hardware without "valliant efforts"; OTOH 'ahci' driver was not used there. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:36AM +0100, Adrian Bunk wrote: This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. Subject: kernels fail to boot with drives on ATIIXP controller References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Alan added comment to my posting that my problems are caused by messed up IRQ routing on that box I tried. Indeed, I can boot kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided I will use 'acpi=off irqpoll'. Anything else and a boot silently dies if 'acpi=off' is skipped or is not finding disk if 'irqpoll' is missing. Somehow 2.6.19 is booting on the same hardware without valliant efforts; OTOH 'ahci' driver was not used there. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: Cable detection fixes
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote: > > That little change, buried in the middle of Alan's patch, changes the > probing order for a /lot/ of devices, possibly millions, when you > consider that it changes behavior of ata_piix (Intel SATA) as well as > all the not-yet-default PATA controllers. Hm, I got recently hands on a hardware where 2.6.21-rc1 based kernels from Fedora rawhide simply do not boot as there is no way to get to disks. I would not mind some change in behavior although so far I can boot at least some earlier kernels. This looks like ATIIXP issue and details are here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Changelogs for kernels in question have this: * Wed Feb 21 2007 Dave Jones <[EMAIL PROTECTED]> - 2.6.21-rc1 Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: Cable detection fixes
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote: That little change, buried in the middle of Alan's patch, changes the probing order for a /lot/ of devices, possibly millions, when you consider that it changes behavior of ata_piix (Intel SATA) as well as all the not-yet-default PATA controllers. Hm, I got recently hands on a hardware where 2.6.21-rc1 based kernels from Fedora rawhide simply do not boot as there is no way to get to disks. I would not mind some change in behavior although so far I can boot at least some earlier kernels. This looks like ATIIXP issue and details are here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Changelogs for kernels in question have this: * Wed Feb 21 2007 Dave Jones [EMAIL PROTECTED] - 2.6.21-rc1 Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why can't I remove a kernel module (or: what uses a given module)?
On Mon, Dec 04, 2006 at 11:10:01AM +0100, Tobias Oed wrote: > Tomasz Chmielewski wrote: > > > Yes, something's using that drive, be it a program, a module (unlikely), > > or something that is compiled directly in the kernel (for example, > > md/raid1). > > Since you mention md, dm comes to mind. I have seen a couple of drives that > were previously attached to fake raid controllers becoming unavailable when > moved to a normal controller. I haven't found the one size workaround for > the problem yet. dmraid -r -E Yes, I was hit by this in a different context. A command is described on 'man dmraid' but figuring out what was the issue took me a long while. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why can't I remove a kernel module (or: what uses a given module)?
On Mon, Dec 04, 2006 at 11:10:01AM +0100, Tobias Oed wrote: Tomasz Chmielewski wrote: Yes, something's using that drive, be it a program, a module (unlikely), or something that is compiled directly in the kernel (for example, md/raid1). Since you mention md, dm comes to mind. I have seen a couple of drives that were previously attached to fake raid controllers becoming unavailable when moved to a normal controller. I haven't found the one size workaround for the problem yet. dmraid -r -E device_in_question Yes, I was hit by this in a different context. A command is described on 'man dmraid' but figuring out what was the issue took me a long while. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A "new driver model" and EXPORT_SYMBOL_GPL question
On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote: > On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote: > > Sourced from here: > > http://hulllug.principalhosting.net/archive/index.php/t-52440.html > > No, that is not the same topic or thread. Formally you are correct but from my POV this sounds casuistic and fit for a patent lawyer. You were "recently advised not to change these symbols" and you stated that you will not. So instead you did an end run and you removed an old interface and introduced a replacement; but this time with EXPORT_SYMBOL_GPL - which has the same effect as what you told you will not do. > If you know of any closed source code, using those functions, please put > them in contact with me. Well, I gave an example in my original question. Yes, I asked them to contact you. If they will do that I have no idea. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new driver model and EXPORT_SYMBOL_GPL question
On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote: On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote: Sourced from here: http://hulllug.principalhosting.net/archive/index.php/t-52440.html No, that is not the same topic or thread. Formally you are correct but from my POV this sounds casuistic and fit for a patent lawyer. You were recently advised not to change these symbols and you stated that you will not. So instead you did an end run and you removed an old interface and introduced a replacement; but this time with EXPORT_SYMBOL_GPL - which has the same effect as what you told you will not do. If you know of any closed source code, using those functions, please put them in contact with me. Well, I gave an example in my original question. Yes, I asked them to contact you. If they will do that I have no idea. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A "new driver model" and EXPORT_SYMBOL_GPL question
On Sun, Jul 03, 2005 at 10:44:41PM -0700, Greg KH wrote: > On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote: > > > Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then > > what considerations dictated it, other then the patch author wrote > > it that way, and what drivers in question are supposed to use when > > this change will show up in the mainline? It looks that 2.6.13 > > will do this. > > Please see the archives for the answers to these questions. I actually tried that before posting. Maybe I attempted to look for wrong things but, beyond conversion examples, I found some postings with a general theme "there is no point to make life easy for binary-only modules" and not much else. I am afraid that this leaves me not much wiser. Also, at least when dealing with 2.6.13-r1, neither Documentation/feature-removal-schedule.txt, nor files in Documentation/driver-model/ directory, mention anything about a switch to EXPORT_SYMBOL_GPL for relevant symbols. The only thing I can find about the later in "feature-removal..." is a note about RCU API. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new driver model and EXPORT_SYMBOL_GPL question
On Sun, Jul 03, 2005 at 10:44:41PM -0700, Greg KH wrote: On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote: Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then what considerations dictated it, other then the patch author wrote it that way, and what drivers in question are supposed to use when this change will show up in the mainline? It looks that 2.6.13 will do this. Please see the archives for the answers to these questions. I actually tried that before posting. Maybe I attempted to look for wrong things but, beyond conversion examples, I found some postings with a general theme there is no point to make life easy for binary-only modules and not much else. I am afraid that this leaves me not much wiser. Also, at least when dealing with 2.6.13-r1, neither Documentation/feature-removal-schedule.txt, nor files in Documentation/driver-model/ directory, mention anything about a switch to EXPORT_SYMBOL_GPL for relevant symbols. The only thing I can find about the later in feature-removal... is a note about RCU API. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Microsoft and Xenix.
On Mon, Jun 25, 2001 at 12:20:40AM +0200, Daniel Phillips wrote: > On Sunday 24 June 2001 12:36, Rob Landley wrote: > > On Saturday 23 June 2001 22:47, Eric W. Biederman wrote: > > > GEM was a gui from Digital Research I believe. > > > Geoworks/Geos was a seperate entity. > > > > Ah, the DR-DOS answer to dosshell/windows. Cool. (I used Dr. Dos byt > > never tried its gui.) > > GEM had its moment of glory when Xerox used it for the gui of Ventura > Publisher. GEM (a slight variation) was also providing GUI on Atari ST. At that time it was heavily beating pants off from anything M$ was able to cobble together on nominally much faster machines. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Microsoft and Xenix.
On Mon, Jun 25, 2001 at 12:20:40AM +0200, Daniel Phillips wrote: On Sunday 24 June 2001 12:36, Rob Landley wrote: On Saturday 23 June 2001 22:47, Eric W. Biederman wrote: GEM was a gui from Digital Research I believe. Geoworks/Geos was a seperate entity. Ah, the DR-DOS answer to dosshell/windows. Cool. (I used Dr. Dos byt never tried its gui.) GEM had its moment of glory when Xerox used it for the gui of Ventura Publisher. GEM (a slight variation) was also providing GUI on Atari ST. At that time it was heavily beating pants off from anything M$ was able to cobble together on nominally much faster machines. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Minor "cleanup" patches for 2.4.5-ac kernels
Here are some small, but in times important, "gotchas" in current
2.4.5-ac kernels.
When compiling SMP 'udelay' in current drivers/pci/quirks.c expands to:
__udelay((15), cpu_data[(current->processor)]...
and a type for 'current' is not known, at least on alpha, so
the following seems to be in order:
--- linux-2.4.5ac/drivers/pci/quirks.c~ Tue Jun 12 16:31:12 2001
+++ linux-2.4.5ac/drivers/pci/quirks.c Tue Jun 12 17:13:18 2001
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#undef DEBUG
There is no problem if SMP is not configured.
This one is replacing a symbol in sg.c to one which is exported
so 'sg.o' can be compiled as a valid module.
--- linux-2.4.5ac/drivers/scsi/sg.c~Tue May 29 17:52:09 2001
+++ linux-2.4.5ac/drivers/scsi/sg.c Tue May 29 18:40:17 2001
@@ -2603,7 +2603,7 @@
num = (count < 10) ? count : 10;
copy_from_user(buff, buffer, num);
buff[num] = '\0';
-sg_allow_dio = simple_strtol(buff, 0, 10) ? 1 : 0;
+sg_allow_dio = simple_strtoul(buff, 0, 10) ? 1 : 0;
return count;
}
And this one, proposed already some few times by Ivan Kokshaysky,
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
kills a flood of warnings (at least on Alpha) about 'mm_struct'
defined on a parameter list.
Are there any reasons which would make any of those "bad"?
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Minor cleanup patches for 2.4.5-ac kernels
Here are some small, but in times important, gotchas in current
2.4.5-ac kernels.
When compiling SMP 'udelay' in current drivers/pci/quirks.c expands to:
__udelay((15), cpu_data[(current-processor)]...
and a type for 'current' is not known, at least on alpha, so
the following seems to be in order:
--- linux-2.4.5ac/drivers/pci/quirks.c~ Tue Jun 12 16:31:12 2001
+++ linux-2.4.5ac/drivers/pci/quirks.c Tue Jun 12 17:13:18 2001
@@ -18,6 +18,7 @@
#include linux/pci.h
#include linux/init.h
#include linux/delay.h
+#include linux/sched.h
#undef DEBUG
There is no problem if SMP is not configured.
This one is replacing a symbol in sg.c to one which is exported
so 'sg.o' can be compiled as a valid module.
--- linux-2.4.5ac/drivers/scsi/sg.c~Tue May 29 17:52:09 2001
+++ linux-2.4.5ac/drivers/scsi/sg.c Tue May 29 18:40:17 2001
@@ -2603,7 +2603,7 @@
num = (count 10) ? count : 10;
copy_from_user(buff, buffer, num);
buff[num] = '\0';
-sg_allow_dio = simple_strtol(buff, 0, 10) ? 1 : 0;
+sg_allow_dio = simple_strtoul(buff, 0, 10) ? 1 : 0;
return count;
}
And this one, proposed already some few times by Ivan Kokshaysky,
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
kills a flood of warnings (at least on Alpha) about 'mm_struct'
defined on a parameter list.
Are there any reasons which would make any of those bad?
Michal
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tulip 0.9.15-pre3 - still no dice
A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not work for me and I have to replace it with 0.9.14d (April 3, 2001) to get a functional network. Trying it with 'tulip_debug=3' option I see this: Linux Tulip driver version 0.9.15-pre3 (June 1, 2001) 00:0b.0: MWI config mwi=0, cacheline=16, csr0=00a0d000 tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0d000, CSR5 f016 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is c6. eth0: Setting CSR6 8242/b2422002 CSR12 10c6. eth0: 21143 negotiation status 10c6, 10baseT. eth0: 21143 negotiation failed, status 10c6. eth0: Testing new 21143 media 100baseTx. eth0: The transmitter stopped. CSR5 is f0008102, CSR6 b242, new CSR6 8386. eth0: 21143 link status interrupt 02ca, CSR5 f0668010, fffbff7f. eth0: 21143 100baseTx link beat failed. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 50ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. . (and a loop with at "Autonegotiation failed" until 'ifdown eth0') . eth0: Shutting down ethercard, status was f102. There was a variation once. A status changed to this: eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 52ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 52ca. but it went back to the same loop: This is, for a comparison, the same level of debug with 0.9.14d working driver. Note different values for CSR0 and CSR5 on tulip_open(). Linux Tulip driver version 0.9.14d (April 3, 2001) eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0e000, CSR5 f072 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is ca. eth0: Setting CSR6 8242/b2422002 CSR12 50ca. eth0: 21143 negotiation status 50ca, 10baseT. Here is an output of tulip-diag, as much as I can get, in a non-working state: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0efb 0efb0200 f000 b2420200 fbfffbff 0x40: e000 cbf8 10ce 0001 fffb 8ff5 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 10ce. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1011, device 500b. CardBus Information Structure at offset . Ethernet MAC Station Address 00:00:F0:51:00:72. EEPROM transceiver/media description table. Leaf node at offset 65, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 0005. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 0005. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 0005. No media detection indication (command 80 61). Media
Tulip 0.9.15-pre3 - still no dice
A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not work for me and I have to replace it with 0.9.14d (April 3, 2001) to get a functional network. Trying it with 'tulip_debug=3' option I see this: Linux Tulip driver version 0.9.15-pre3 (June 1, 2001) 00:0b.0: MWI config mwi=0, cacheline=16, csr0=00a0d000 tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0d000, CSR5 f016 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is c6. eth0: Setting CSR6 8242/b2422002 CSR12 10c6. eth0: 21143 negotiation status 10c6, 10baseT. eth0: 21143 negotiation failed, status 10c6. eth0: Testing new 21143 media 100baseTx. eth0: The transmitter stopped. CSR5 is f0008102, CSR6 b242, new CSR6 8386. eth0: 21143 link status interrupt 02ca, CSR5 f0668010, fffbff7f. eth0: 21143 100baseTx link beat failed. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 50ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. . (and a loop with at Autonegotiation failed until 'ifdown eth0') . eth0: Shutting down ethercard, status was f102. There was a variation once. A status changed to this: eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 52ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 52ca. but it went back to the same loop: This is, for a comparison, the same level of debug with 0.9.14d working driver. Note different values for CSR0 and CSR5 on tulip_open(). Linux Tulip driver version 0.9.14d (April 3, 2001) eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0e000, CSR5 f072 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is ca. eth0: Setting CSR6 8242/b2422002 CSR12 50ca. eth0: 21143 negotiation status 50ca, 10baseT. Here is an output of tulip-diag, as much as I can get, in a non-working state: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0efb 0efb0200 f000 b2420200 fbfffbff 0x40: e000 cbf8 10ce 0001 fffb 8ff5 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 10ce. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1011, device 500b. CardBus Information Structure at offset . Ethernet MAC Station Address 00:00:F0:51:00:72. EEPROM transceiver/media description table. Leaf node at offset 65, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 0005. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 0005. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 0005. No media detection indication (command 80 61). Media
Current tulip driver from 2.4.5 is plain broken
I mentioned that before but this should be stated clearly. As far as I am concerned "Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)", as used in 2.4.5 - and other kernels - is totally buggered. It comes up, and ethernet interfaces can be configured, but does not matter how I am playing with options I cannot get a single packet through. Replacing it in 2.4.5 with "Linux Tulip driver version 0.9.14d (April 3, 2001)", which I have handy, restores sanity immediately and a network simply works without any heroic efforts. My NIC is "Digital DS21143 Tulip rev 65 at 0x8800". BTW - a version "tulip-1.1.7" from sourceforge behaves exactly like 0.9.15-pre2. This is an output of 'tulip-diag -af' from a working setup: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0e000 0d572000 0d572200 f066 b2422002 fbfffbff 0x40: e000 fff583ff 52ca 0001 fffb 8ffd0008 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 52ca. Internal autonegotiation state is 'Negotiation complete'. And this what shows up when I am trying to use "the-new-and-improved": tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0b9f4000 0b9f4200 f000 b2420200 fbfffbff 0x40: e000 fff483ff 60ca 0001 fffb 8ffd Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 60ca. Internal autonegotiation state is 'Link check'. Comments? Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Current tulip driver from 2.4.5 is plain broken
I mentioned that before but this should be stated clearly. As far as I am concerned Linux Tulip driver version 0.9.15-pre2 (May 16, 2001), as used in 2.4.5 - and other kernels - is totally buggered. It comes up, and ethernet interfaces can be configured, but does not matter how I am playing with options I cannot get a single packet through. Replacing it in 2.4.5 with Linux Tulip driver version 0.9.14d (April 3, 2001), which I have handy, restores sanity immediately and a network simply works without any heroic efforts. My NIC is Digital DS21143 Tulip rev 65 at 0x8800. BTW - a version tulip-1.1.7 from sourceforge behaves exactly like 0.9.15-pre2. This is an output of 'tulip-diag -af' from a working setup: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0e000 0d572000 0d572200 f066 b2422002 fbfffbff 0x40: e000 fff583ff 52ca 0001 fffb 8ffd0008 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 52ca. Internal autonegotiation state is 'Negotiation complete'. And this what shows up when I am trying to use the-new-and-improved: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0b9f4000 0b9f4200 f000 b2420200 fbfffbff 0x40: e000 fff483ff 60ca 0001 fffb 8ffd Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 60ca. Internal autonegotiation state is 'Link check'. Comments? Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Alpha SMP Low Outbound Bandwidth
On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote: > [1.] One line summary of the problem: > Kernel 2.4.4 ac15 > Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards, [ description of a slowdown skipped ]. Well, it looks that you have at least something to slow down. I could not get a single packet through my tulip on Alpha from at least 2.4.4-ac11 and up. You can consider that an ultimate slowdown. I tried also a driver from http://sourceforge.net/projects/tulip/ and results are the same. This NIC, Digital DS21143 Tulip rev 65, works just fine with various earlier kernels, including assorted 2.4.3 variants. It is on 10baseT netwok - which may, or may not, be relevant here. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac17 - missing in exports simple_strtol symbol
Patches to drivers/scsi/sg.c included in 2.4.4-ac17 require for 'sg.o' module to use 'simple_strtol' which is not exported in kernel/ksyms.c. Is this is an oversight or 'sg.o' should be actually using something like 'simple_strtoul' - which is already exported? In either case patches are obvious. BTW - is tulip supposed to already work in this version? Because it does not. Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac17 - missing in exports simple_strtol symbol
Patches to drivers/scsi/sg.c included in 2.4.4-ac17 require for 'sg.o' module to use 'simple_strtol' which is not exported in kernel/ksyms.c. Is this is an oversight or 'sg.o' should be actually using something like 'simple_strtoul' - which is already exported? In either case patches are obvious. BTW - is tulip supposed to already work in this version? Because it does not. Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Alpha SMP Low Outbound Bandwidth
On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote: [1.] One line summary of the problem: Kernel 2.4.4 ac15 Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards, [ description of a slowdown skipped ]. Well, it looks that you have at least something to slow down. I could not get a single packet through my tulip on Alpha from at least 2.4.4-ac11 and up. You can consider that an ultimate slowdown. I tried also a driver from http://sourceforge.net/projects/tulip/ and results are the same. This NIC, Digital DS21143 Tulip rev 65, works just fine with various earlier kernels, including assorted 2.4.3 variants. It is on 10baseT netwok - which may, or may not, be relevant here. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compile fails an Alpha: include/asm/pci.h included from arch/alpha/kernel/setup.c
On Mon, May 21, 2001 at 05:18:55PM +0200, Jan-Benedict Glaw wrote: > > Kernel 2.4.5-pre[34] don't compile on Alpha: > > 152 struct pci_controller *hose = pdev->sysdata; ^^^ This is the problem (a type for 'pdev' is not defined). And this is a possible fix: --- linux-2.4.4ac/include/asm-alpha/pci.h~ Sat May 19 16:43:11 2001 +++ linux-2.4.4ac/include/asm-alpha/pci.h Sat May 19 17:23:56 2001 @@ -6,6 +6,7 @@ #include #include #include +#include /* * The following structure is used to manage multiple PCI busses. The patch is for 2.4.4-ac11, so offsets are possibly slightly different, but probably not. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compile fails an Alpha: include/asm/pci.h included from arch/alpha/kernel/setup.c
On Mon, May 21, 2001 at 05:18:55PM +0200, Jan-Benedict Glaw wrote: Kernel 2.4.5-pre[34] don't compile on Alpha: 152 struct pci_controller *hose = pdev-sysdata; ^^^ This is the problem (a type for 'pdev' is not defined). And this is a possible fix: --- linux-2.4.4ac/include/asm-alpha/pci.h~ Sat May 19 16:43:11 2001 +++ linux-2.4.4ac/include/asm-alpha/pci.h Sat May 19 17:23:56 2001 @@ -6,6 +6,7 @@ #include linux/spinlock.h #include asm/scatterlist.h #include asm/machvec.h +#include linux/pci.h /* * The following structure is used to manage multiple PCI busses. The patch is for 2.4.4-ac11, so offsets are possibly slightly different, but probably not. :-) Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Troubles with 8139too and 2.2.19
It looks like tha 8139too, at least in 2.2.19, works fine when there is one such card around but with NICs it detects both but fails to set the second one correctly (complaints about incorrect IRQ, memory, ... - you name it). Does anybody has some ideas what is going on here? This was observed on Alpha, BTW, but this tidbit is likely not relevant and, yes, we used pairs of other NICs before on similar machines. Alternate rtl8139 module from that kernel cannot detect D-link DFE-538 card. A version of this driver from http://www.scyld.com seems to be ok (at least both cards start) once you will get it to compile. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Troubles with 8139too and 2.2.19
It looks like tha 8139too, at least in 2.2.19, works fine when there is one such card around but with NICs it detects both but fails to set the second one correctly (complaints about incorrect IRQ, memory, ... - you name it). Does anybody has some ideas what is going on here? This was observed on Alpha, BTW, but this tidbit is likely not relevant and, yes, we used pairs of other NICs before on similar machines. Alternate rtl8139 module from that kernel cannot detect D-link DFE-538 card. A version of this driver from http://www.scyld.com seems to be ok (at least both cards start) once you will get it to compile. :-) Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote: > OK, so you want CML2's "make oldconfig" to do something more graceful than > simply say "Foo! You violated this constraint! Go fix it!" After all this combinatorics I still do not know an answer to a simple question. With the current system I can do grep -v '^#' .config > config.stripped copy 'config.stripped' back to .config, type 'make oldconfig' and hold for a while to get my old .config back. This is actually very useful, and used every day, although maybe not precisely in the manner as above. :-) So, the question is: can I do something something like that with CML2? If the answer is "no" then something is very seriously missing and no references to halting problems can cover that. If, OTOH, the answer is "yes" then what is a big trouble? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote: OK, so you want CML2's make oldconfig to do something more graceful than simply say Foo! You violated this constraint! Go fix it! After all this combinatorics I still do not know an answer to a simple question. With the current system I can do grep -v '^#' .config config.stripped copy 'config.stripped' back to .config, type 'make oldconfig' and hold Return for a while to get my old .config back. This is actually very useful, and used every day, although maybe not precisely in the manner as above. :-) So, the question is: can I do something something like that with CML2? If the answer is no then something is very seriously missing and no references to halting problems can cover that. If, OTOH, the answer is yes then what is a big trouble? Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac3
On Tue, May 01, 2001 at 10:28:35PM +0100, Alan Cox wrote:
>
> 2.4.4-ac3
Does not compile on Alpha. I have a strange feeling that because
of this:-)
> o Fix module exception race on Alpha (Andrea Arcangeli)
A declaration was forgotten and, comparing with i386 equivalent, this
minor correction is required:
--- linux-2.4.4-ac/arch/alpha/mm/extable.c~ Wed May 2 11:08:43 2001
+++ linux-2.4.4-ac/arch/alpha/mm/extable.c Wed May 2 12:08:50 2001
@@ -36,6 +36,8 @@
register unsigned long gp __asm__("$29");
+extern spinlock_t modlist_lock;
+
static unsigned
search_exception_table_without_gp(unsigned long addr)
{
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac3
On Tue, May 01, 2001 at 10:28:35PM +0100, Alan Cox wrote:
2.4.4-ac3
Does not compile on Alpha. I have a strange feeling that because
of this:-)
o Fix module exception race on Alpha (Andrea Arcangeli)
A declaration was forgotten and, comparing with i386 equivalent, this
minor correction is required:
--- linux-2.4.4-ac/arch/alpha/mm/extable.c~ Wed May 2 11:08:43 2001
+++ linux-2.4.4-ac/arch/alpha/mm/extable.c Wed May 2 12:08:50 2001
@@ -36,6 +36,8 @@
register unsigned long gp __asm__($29);
+extern spinlock_t modlist_lock;
+
static unsigned
search_exception_table_without_gp(unsigned long addr)
{
Michal
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote: > On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote: > > ptrace only operates on processes that are stopped. So there are no > > locking issues - we've synchronized on a much higher level than a > > spinlock or semaphore. > > This is only true for requests other than PTRACE_ATTACH and > PTRACE_ATTACH is exactly what I'm worried about. May I remind everybody that at the beginning of this thread I posted another example, from an SMP Alpha, of FPU problems. It certainly was not exactly like the one under discussion but it looked that it had a similar "smell" to it. It looks like that to reproduce this Alpha example one needs processors with a rather fast clock and this hardware version is not yet very widely available. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote: On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote: ptrace only operates on processes that are stopped. So there are no locking issues - we've synchronized on a much higher level than a spinlock or semaphore. This is only true for requests other than PTRACE_ATTACH and PTRACE_ATTACH is exactly what I'm worried about. May I remind everybody that at the beginning of this thread I posted another example, from an SMP Alpha, of FPU problems. It certainly was not exactly like the one under discussion but it looked that it had a similar smell to it. It looks like that to reproduce this Alpha example one needs processors with a rather fast clock and this hardware version is not yet very widely available. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote: > > We have found that one of our programs can cause system-wide > corruption of the x86 FPU under 2.2.16 and 2.2.17. > > We see this problem on dual 550MHz Xeons with 1GB RAM. Hm, I started to wonder if this is not somewhat related to a recent report I got. "The victim" was running 2.2.19 (basically) on an SMP Alpha UP2000+ with two 800 MHz processors. He managed to reduce the problem to a rather small test case and I attach sources, Makefile and a "loop.sh" driver as a shar archive if you want to have a closer look. This "loop.sh" simply fires triplets of "harry" process in a loop. The guy hit by this gets apparently random floating point exceptions starting with roughly sixth process and later intervals between bombs will vary. I have also 'strace' outputs from failing processes but they are not telling very much. 'gdb' is also not very illuminating: Program received signal SIGFPE, Arithmetic exception. 0x1200010a8 in vadd_ (a=0x11fff21e4, ia=0x120003294, b=0x11fff7004, ib=0x120003294, c=0x11fffbe20, ic=0x120003294, n=0x11c70) at vadd.f:99 99 C(CI) = A(AI) + B(BI) Current language: auto; currently fortran (gdb) p *ia $10 = 1 (gdb) p *ib $11 = 1 (gdb) p *ic $12 = 1 (gdb) p *n Cannot access memory at address 0x4 (gdb) p *(0x11c70) $13 = 1024 (gdb) info locals n = (PTR TO -> ( integer )) 0x4 __g77_expr_0 = 10 He tells me that he is getting that on two different machines he has around. The trouble is that I tried to repeat that with different hardware, kernels, compilers and libraries and I failed even on SMP; but I got an access to a box with only 667 MHz processors. OTOH he is running right now 2.4.3-ac9 plus Andrea Arcangeli patches for rw semaphores on Alpha and he reports that the problem went away (and, hopefuly, nothing else will crop out :-). Anybody can offer an insight what that may really be? It may be, of course, totally unrelated to this report from Victor Zandy. Michal [EMAIL PROTECTED] fpbomb.shar
Re: BUG: Global FPU corruption in 2.2
On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote: We have found that one of our programs can cause system-wide corruption of the x86 FPU under 2.2.16 and 2.2.17. We see this problem on dual 550MHz Xeons with 1GB RAM. Hm, I started to wonder if this is not somewhat related to a recent report I got. "The victim" was running 2.2.19 (basically) on an SMP Alpha UP2000+ with two 800 MHz processors. He managed to reduce the problem to a rather small test case and I attach sources, Makefile and a "loop.sh" driver as a shar archive if you want to have a closer look. This "loop.sh" simply fires triplets of "harry" process in a loop. The guy hit by this gets apparently random floating point exceptions starting with roughly sixth process and later intervals between bombs will vary. I have also 'strace' outputs from failing processes but they are not telling very much. 'gdb' is also not very illuminating: Program received signal SIGFPE, Arithmetic exception. 0x1200010a8 in vadd_ (a=0x11fff21e4, ia=0x120003294, b=0x11fff7004, ib=0x120003294, c=0x11fffbe20, ic=0x120003294, n=0x11c70) at vadd.f:99 99 C(CI) = A(AI) + B(BI) Current language: auto; currently fortran (gdb) p *ia $10 = 1 (gdb) p *ib $11 = 1 (gdb) p *ic $12 = 1 (gdb) p *n Cannot access memory at address 0x4 (gdb) p *(0x11c70) $13 = 1024 (gdb) info locals n = (PTR TO - ( integer )) 0x4 __g77_expr_0 = 10 He tells me that he is getting that on two different machines he has around. The trouble is that I tried to repeat that with different hardware, kernels, compilers and libraries and I failed even on SMP; but I got an access to a box with only 667 MHz processors. OTOH he is running right now 2.4.3-ac9 plus Andrea Arcangeli patches for rw semaphores on Alpha and he reports that the problem went away (and, hopefuly, nothing else will crop out :-). Anybody can offer an insight what that may really be? It may be, of course, totally unrelated to this report from Victor Zandy. Michal [EMAIL PROTECTED] fpbomb.shar
Re: /proc/config idea
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote: > > if the distro/sysadmin _always_ installs the kernel the 'right way' then > the difference isn't nessasarily that large, but if you want reliability > on any system it may be worth loosing a page or so of memory (hasn't > someone said that the data can be compressed to <1K?) After throwing away in a Makefile rule all "is not set" lines, as they are trivially recoverable with 'make oldconfig', what is left for an avarege kernel compresses to something like 500 bytes. Quite a bit of space left on this one page if you need more extensive .config. 'zcat /proc/config.gz' works just fine. As most kernels around are NOT installed "the right way" I found that in practice separating configuration information from a kernel image is not even close to be semi-reliable on a longer run. Those who say "installation script", and similar things, assume that people compile kernels for themselves. This is undoubtely true for folks on this list; this does not start to approximate the situation in general and, it seems, that we really want it that way. :-) BTW - /sbin/installkernel, as seen in practice, is not even correct for a general case with x86; not to mention other architectures. Writing something like /var/log/config from "init data" during a bootup could be another solution which does not take any kernel memory and still keeps all this information attached to a kernel image itself. OTOH we have all these tons of strings which show in /proc/pci output and somehow these do not cause such huge opposition. Yes, I know that 'lspci' was supposed to replace that; but it did not. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/config idea
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote: if the distro/sysadmin _always_ installs the kernel the 'right way' then the difference isn't nessasarily that large, but if you want reliability on any system it may be worth loosing a page or so of memory (hasn't someone said that the data can be compressed to 1K?) After throwing away in a Makefile rule all "is not set" lines, as they are trivially recoverable with 'make oldconfig', what is left for an avarege kernel compresses to something like 500 bytes. Quite a bit of space left on this one page if you need more extensive .config. 'zcat /proc/config.gz' works just fine. As most kernels around are NOT installed "the right way" I found that in practice separating configuration information from a kernel image is not even close to be semi-reliable on a longer run. Those who say "installation script", and similar things, assume that people compile kernels for themselves. This is undoubtely true for folks on this list; this does not start to approximate the situation in general and, it seems, that we really want it that way. :-) BTW - /sbin/installkernel, as seen in practice, is not even correct for a general case with x86; not to mention other architectures. Writing something like /var/log/config from "init data" during a bootup could be another solution which does not take any kernel memory and still keeps all this information attached to a kernel image itself. OTOH we have all these tons of strings which show in /proc/pci output and somehow these do not cause such huge opposition. Yes, I know that 'lspci' was supposed to replace that; but it did not. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: ... > > 2.4.2-ac20 ... > o Fix Alpha build (Jeff Garzik) Now I see (at least on Alpha) a constant wailing: /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, which is probably not what you want Is this somehow related? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: ... 2.4.2-ac20 ... o Fix Alpha build (Jeff Garzik) Now I see (at least on Alpha) a constant wailing: /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, which is probably not what you want Is this somehow related? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Sat, Mar 10, 2001 at 07:50:06PM +0100, Martin Mares wrote: > Hello! > > > Well, not really in this situation, after a simple modification. It is > > trivial to show that using "shorter interval sorted first" approach one > > can bound an amount of an extra memory, on stack or otherwise, and by a > > rather small number. > > By O(log N) which is in reality a small number :) Assuming that we sort a full range of 32-bit numbers (pointers on a 32-bit CPU, for example, are numbers of that kind but usually a range can be narrowed down quite substantially) then with a bit of a careful programming you need, I think, something like 16 extra 4-byte words or maybe even a bit less. I do not remember precisely, as I was doing this exercise a long time ago, but even if this is 32, and you need carefuly constructed example to need them all these extra cells, I still think that this is not a huge amount of memory. Especially when every element of a list you are sorting is likely quite a bit bigger. Exponents are something which grows these numbers pretty fast. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Sat, Mar 10, 2001 at 07:50:06PM +0100, Martin Mares wrote: Hello! Well, not really in this situation, after a simple modification. It is trivial to show that using "shorter interval sorted first" approach one can bound an amount of an extra memory, on stack or otherwise, and by a rather small number. By O(log N) which is in reality a small number :) Assuming that we sort a full range of 32-bit numbers (pointers on a 32-bit CPU, for example, are numbers of that kind but usually a range can be narrowed down quite substantially) then with a bit of a careful programming you need, I think, something like 16 extra 4-byte words or maybe even a bit less. I do not remember precisely, as I was doing this exercise a long time ago, but even if this is 32, and you need carefuly constructed example to need them all these extra cells, I still think that this is not a huge amount of memory. Especially when every element of a list you are sorting is likely quite a bit bigger. Exponents are something which grows these numbers pretty fast. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, Mar 09, 2001 at 12:52:22PM +0100, Rogier Wolff wrote: > > Quicksort however is an algorithm that is recursive. This means that > it can use unbounded amounts of stack -> This is not for the kernel. Well, not really in this situation, after a simple modification. It is trivial to show that using "shorter interval sorted first" approach one can bound an amount of an extra memory, on stack or otherwise, and by a rather small number. This assumes that one knows what one is sorting - which is obviously the case here. Also my copy of Reingold, Nivergelt, Deo from 1977 presents a "non-recursive" variant of quicksort as a kind of an "old hat" solution. One would think that this piece of information would spread during those years. :-) It is a simple exercise anyway. > Quicksort has a very bad "worst case": quadratic sort-time. Are you > sure this won't happen? This is much more serious objection. You can nearly guarantee in an itended application that somebody will find a way to feed you packets which will ensure the worst case behaviour. The same gotcha will probably kill quite a few other ways to sort here. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, Mar 09, 2001 at 12:52:22PM +0100, Rogier Wolff wrote: Quicksort however is an algorithm that is recursive. This means that it can use unbounded amounts of stack - This is not for the kernel. Well, not really in this situation, after a simple modification. It is trivial to show that using "shorter interval sorted first" approach one can bound an amount of an extra memory, on stack or otherwise, and by a rather small number. This assumes that one knows what one is sorting - which is obviously the case here. Also my copy of Reingold, Nivergelt, Deo from 1977 presents a "non-recursive" variant of quicksort as a kind of an "old hat" solution. One would think that this piece of information would spread during those years. :-) It is a simple exercise anyway. Quicksort has a very bad "worst case": quadratic sort-time. Are you sure this won't happen? This is much more serious objection. You can nearly guarantee in an itended application that somebody will find a way to feed you packets which will ensure the worst case behaviour. The same gotcha will probably kill quite a few other ways to sort here. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Slightly OT] x86 PROM project
On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote: > On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote: > > Have a look at OpenBIOS: > > > > http://www.freiburg.linux.de/OpenBIOS/ > > > > The project wants to create an IEEE 1275-1994 compliant firmware, like > > used by SUN (for example). > > I don't want to appear to be offensive in regards to this project > considering I have no prior knowledge about it other than what I've seen > at the web site just now, but it appears that there is a lot more talk > than coding occuring at this project. Ok, so what about this one? http://www.acl.lanl.gov/linuxbios/ The code is on sourceforge. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Slightly OT] x86 PROM project
On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote: On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote: Have a look at OpenBIOS: http://www.freiburg.linux.de/OpenBIOS/ The project wants to create an IEEE 1275-1994 compliant firmware, like used by SUN (for example). I don't want to appear to be offensive in regards to this project considering I have no prior knowledge about it other than what I've seen at the web site just now, but it appears that there is a lot more talk than coding occuring at this project. Ok, so what about this one? http://www.acl.lanl.gov/linuxbios/ The code is on sourceforge. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernels - "attempt to access beyond end of device"
On Wed, Feb 28, 2001 at 10:54:15PM +, Petr Vandrovec wrote: > On 28 Feb 01 at 13:46, Michal Jaegermann wrote: > > I think that I found what gives me a hell with this box and it > > looks like that this not Linux at all. Once again, this is Athlon > > K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C. > > K7 on A7V, I believe... Maybe. 'cat /proc/cpuinfo' says "cpu family: 6" and "model :4" (and "stepping: 2"). I possibly misinterpreted that. Do not believe me when I am talking about x86 chips. :-) > > I have more checks to make before I will be fully satisfied but > > this looks like it. > ... > > System Performance Setting [Optimal, Normal] > ... > > Try BIOS 1006. AFAIK 1005D changed some VIA values for 'optimal'. Is that important here? IDE drives in question were not connected to on-board controller but the Promise one. Results seem to indicate that this 'optimal' was important here anyway. > And 1006 contains newer Promise BIOS - but I did not notice any difference: > Windows98 still do not boot if I connect harddisk to /dev/hdh :-( There is at this moment Windows98 installation on /dev/hde1 and it boots so far. It got installed and it was booting regardless with these "other" BIOS seetings. > But Linux works fine... Hope so Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernels - "attempt to access beyond end of device"
I think that I found what gives me a hell with this box and it looks like that this not Linux at all. Once again, this is Athlon K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C. I have more checks to make before I will be fully satisfied but this looks like it. In this BIOS setup there are two "advanced" options: System Performance Setting [Optimal, Normal] USB Legacy Support [Auto, Enabled, Disabled] If the first one is set to "Normal" and the second one to "Disabled" then the whole system becomes stable. I copied from various file systems to a directory+on ext2 around 1.2 GB of files without any ill effects and run succesfully 'diff -r' between two directories 475 MB each. If BIOS options are any other way then one should expect spectacular blowups with corrupted file systems and other nasty effects after the first oops. It survives up to something between 130 to 150 MB of data moved, does not matter which kernel, and that is it. It is difficult to know what is "System Performance Setting" as it always shows "Optimal" regardless of a status on the last save. But a system behaviour depends on how it was set so it seems to change even if a display, on the next visit, does not. How "USB Legacy Support" comes into the picture I cannot even imagine. I did try with 2.2.19pre and 2.4 kernels and the picture does not change. Any rational explanation beyond that BIOS is doing something really nasty? Cheers, Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernels - attempt to access beyond end of device
I think that I found what gives me a hell with this box and it looks like that this not Linux at all. Once again, this is Athlon K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C. I have more checks to make before I will be fully satisfied but this looks like it. In this BIOS setup there are two "advanced" options: System Performance Setting [Optimal, Normal] USB Legacy Support [Auto, Enabled, Disabled] If the first one is set to "Normal" and the second one to "Disabled" then the whole system becomes stable. I copied from various file systems to a directory+on ext2 around 1.2 GB of files without any ill effects and run succesfully 'diff -r' between two directories 475 MB each. If BIOS options are any other way then one should expect spectacular blowups with corrupted file systems and other nasty effects after the first oops. It survives up to something between 130 to 150 MB of data moved, does not matter which kernel, and that is it. It is difficult to know what is "System Performance Setting" as it always shows "Optimal" regardless of a status on the last save. But a system behaviour depends on how it was set so it seems to change even if a display, on the next visit, does not. How "USB Legacy Support" comes into the picture I cannot even imagine. I did try with 2.2.19pre and 2.4 kernels and the picture does not change. Any rational explanation beyond that BIOS is doing something really nasty? Cheers, Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernels - attempt to access beyond end of device
On Wed, Feb 28, 2001 at 10:54:15PM +, Petr Vandrovec wrote: On 28 Feb 01 at 13:46, Michal Jaegermann wrote: I think that I found what gives me a hell with this box and it looks like that this not Linux at all. Once again, this is Athlon K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C. K7 on A7V, I believe... Maybe. 'cat /proc/cpuinfo' says "cpu family: 6" and "model :4" (and "stepping: 2"). I possibly misinterpreted that. Do not believe me when I am talking about x86 chips. :-) I have more checks to make before I will be fully satisfied but this looks like it. ... System Performance Setting [Optimal, Normal] ... Try BIOS 1006. AFAIK 1005D changed some VIA values for 'optimal'. Is that important here? IDE drives in question were not connected to on-board controller but the Promise one. Results seem to indicate that this 'optimal' was important here anyway. And 1006 contains newer Promise BIOS - but I did not notice any difference: Windows98 still do not boot if I connect harddisk to /dev/hdh :-( There is at this moment Windows98 installation on /dev/hde1 and it boots so far. It got installed and it was booting regardless with these "other" BIOS seetings. But Linux works fine... Hope so Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Via-rhine is not finding its interrupts under 2.2.19pre14
After I booted 2.2.19pre14 on a system with two via-rhine cards I see the following: via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 0. eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link . eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 0. eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link . and a network does not work due to these IRQ 0, I guess. In contrast when I will boot on the same hardware 2.4.2-ac5 then I get, among other things, via-rhine.c:v1.08b-LK1.1.7 8/9/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: Enabling device 00:09.0 (0094 -> 0097) PCI: Found IRQ 9 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:0d.0 eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 9. eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link . PCI: Enabling device 00:0c.0 (0094 -> 0097) PCI: Found IRQ 11 for device 00:0c.0 eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 11. eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link . Devices in question can be seen here: -[00]-+-00.0 VIA Technologies, Inc. VT8363/8365 [KT133/KM133] +-01.0-[01]00.0 ATI Technologies Inc Rage 128 RF +-04.0 VIA Technologies, Inc. VT82C686 [Apollo Super South] +-04.1 VIA Technologies, Inc. Bus Master IDE +-04.2 VIA Technologies, Inc. UHCI USB +-04.3 VIA Technologies, Inc. UHCI USB +-04.4 VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] +-09.0 VIA Technologies, Inc. VT86C100A [Rhine 10/100] +-0a.0 Symbios Logic Inc. (formerly NCR) 53c810 +-0c.0 VIA Technologies, Inc. VT86C100A [Rhine 10/100] +-0d.0 Ensoniq CT5880 [AudioPCI] \-11.0 Promise Technology, Inc. 20265 I do not have turned on a support for USB or audio in either of these two kernels. They are actually configured pretty similar (within a reason :-). But network is operational with 2.4.2-ac5. Hm... Even with these IRQ conflicts for eth0 one would think that eth1 should get its interrupt. It does not conflict with anything. Forgotten 'pci_enable()' somewhere? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernels - "attempt to access beyond end of device"
To add to my report about troubles with disk activity on a system with
PDC20265 IDE controller (this is on Asus AV7 mobo, BTW) I tried the
same experiments with 2.2.19pre14 patched with ide patches to get a
support for Promise.
I got similar results - i.e. problems after some 130-150 megabytes
was copied. On different occasions I got things like that:
file_cluster badly computed!!! 0 <> 536870911
file_cluster badly computed!!! 1 <> 0
practically immediately and followed by a period of a lively disk
activity and a crash.
Whoops: end_buffer_io_async: b_count != 1 on async io.
after which 'cp' process hanged in a "D" state.
attempt to access beyond end of device
21:01: rw=0, want=537238629, limit=4506201
dev 21:01 blksize=512 blocknr=1074477258 sector=1074477258 size=512 count=1
...
(and more of these) terminated with oops decoded below.
To take 'vfat' out of picture I also tried 'cp' from ext2 partitions
(I had to collect number of things as I do not have enough of data on
this system yet) to an ext2 partition while using 2.4.2-ac5. This resulted
in:
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #16584: inode out of bounds - offset=0, inode=134234312,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #131542: inode out of bounds - offset=0, inode=134349270,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #82294: inode out of bounds - offset=0, inode=134300022,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #164456: inode out of bounds - offset=0, inode=134382184,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #98872: inode out of bounds - offset=0, inode=134316600,
rec_len=12, name_len=1
22:09: rw=0, want=537530884, limit=1574338
attempt to access beyond end of device
22:09: rw=0, want=537530884, limit=1574338
.
punctuated by oops.
Here is a decoded oops from 2.2.19pre14
Unable to handle kernel paging request at virtual address 0800
current->tss.cr3 = 1f052000, %cr3 = 1f052000
*pde = 1f67b067
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0800 ebx: 0007 ecx: 00053d24 edx: 0800
esi: 000d edi: 2202 ebp: 0004906a esp: de955e7c
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 573, process nr: 19, stackpage=de955000)
Stack: 0004906a 2202 00053d24 c01277e8 2202 0004906a 0200
c0127b9a 2202 0004906a 0200 0004906a ded6a200
c0145398 2202 0004906a 0200 c014a0db ded6a200 0004906a
Call Trace: [] [] [] [] []
[] []
[] [] []
Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c
>>EIP; c01277a8<=
Trace; c01277e8
Trace; c0127b9a
Trace; c0145398
Trace; c014a0db
Trace; c0145b6c
Trace; c014a26f
Trace; c014784e
Trace; c01262d9
Trace; c01476d0
Trace; c0109534
Code; c01277a8
<_EIP>:
Code; c01277a8<=
0: 8b 00 mov(%eax),%eax <=
Code; c01277aa
2: 39 6a 04 cmp%ebp,0x4(%edx)
Code; c01277ad
5: 75 15 jne1c <_EIP+0x1c> c01277c4
Code; c01277af
7: 8b 4c 24 20 mov0x20(%esp,1),%ecx
Code; c01277b3
b: 39 4a 08 cmp%ecx,0x8(%edx)
Code; c01277b6
e: 75 0c jne1c <_EIP+0x1c> c01277c4
Code; c01277b8
10: 66 39 7a 0c cmp%di,0xc(%edx)
And here is the one from ext2 to ext2 copy under 2.4.2-ac5
Unable to handle kernel paging request at virtual address ea096084
c0128edf
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010003
eax: 081b ebx: 081b ecx: 0282 edx: ca096000
esi: dffd7cdc edi: ebp: 1000 esp: dec6de38
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 543, stackpage=dec6d000)
Stack: 220a 0001220a 0286 0010 c17cb2e0 c0133314 dffd7cdc
0003 c17cb2e0 c01333d2 0001 0007ccfc c0121be9
220a c17cb2e0 c17cb2e0 220a c0133687 c17cb2e0 1000
Call Trace: [] [] [] [] []
[] []
[] [] [] [] [] []
Code: 8b 44 82 18 0f af 5e 0c 89 42 14 03 5a 0c 40 75 05 8b 02 89
>>EIP; c0128edf<=
Trace; c0133314
Trace; c01333d2
Trace; c0121be9
Trace; c0133687
Trace; c01339ab <__block_prepare_write+4b/2b0>
Trace; c0123e8c
Trace; c013423d
Trace; c014ffb0
Trace; c0126886
Trace; c014ffb0
Trace; c0124a70
Trace; c0131468
Trace; c01090a3
Code; c0128edf
<_EIP>:
Code; c0128edf<=
0: 8b 44 82 18 mov0x18(%edx,%eax,4),%eax <=
Code; c0128ee3
4: 0f af 5e 0c imul 0xc(%esi),%ebx
Code; c0128ee7
8: 89 42 14 mov%eax,0x14(%edx)
Re: 2.4 kernels - attempt to access beyond end of device
To add to my report about troubles with disk activity on a system with
PDC20265 IDE controller (this is on Asus AV7 mobo, BTW) I tried the
same experiments with 2.2.19pre14 patched with ide patches to get a
support for Promise.
I got similar results - i.e. problems after some 130-150 megabytes
was copied. On different occasions I got things like that:
file_cluster badly computed!!! 0 536870911
file_cluster badly computed!!! 1 0
practically immediately and followed by a period of a lively disk
activity and a crash.
Whoops: end_buffer_io_async: b_count != 1 on async io.
after which 'cp' process hanged in a "D" state.
attempt to access beyond end of device
21:01: rw=0, want=537238629, limit=4506201
dev 21:01 blksize=512 blocknr=1074477258 sector=1074477258 size=512 count=1
...
(and more of these) terminated with oops decoded below.
To take 'vfat' out of picture I also tried 'cp' from ext2 partitions
(I had to collect number of things as I do not have enough of data on
this system yet) to an ext2 partition while using 2.4.2-ac5. This resulted
in:
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #16584: inode out of bounds - offset=0, inode=134234312,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #131542: inode out of bounds - offset=0, inode=134349270,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #82294: inode out of bounds - offset=0, inode=134300022,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #164456: inode out of bounds - offset=0, inode=134382184,
rec_len=12, name_len=1
EXT2-fs error (device ide3(34,9)): ext2_readdir: bad entry in
directory #98872: inode out of bounds - offset=0, inode=134316600,
rec_len=12, name_len=1
22:09: rw=0, want=537530884, limit=1574338
attempt to access beyond end of device
22:09: rw=0, want=537530884, limit=1574338
.
punctuated by oops.
Here is a decoded oops from 2.2.19pre14
Unable to handle kernel paging request at virtual address 0800
current-tss.cr3 = 1f052000, %cr3 = 1f052000
*pde = 1f67b067
Oops:
CPU:0
EIP:0010:[c01277a8]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0800 ebx: 0007 ecx: 00053d24 edx: 0800
esi: 000d edi: 2202 ebp: 0004906a esp: de955e7c
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 573, process nr: 19, stackpage=de955000)
Stack: 0004906a 2202 00053d24 c01277e8 2202 0004906a 0200
c0127b9a 2202 0004906a 0200 0004906a ded6a200
c0145398 2202 0004906a 0200 c014a0db ded6a200 0004906a
Call Trace: [c01277e8] [c0127b9a] [c0145398] [c014a0db] [c0145b6c]
[c014a26f] [c014784e]
[c01262d9] [c01476d0] [c0109534]
Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c
EIP; c01277a8 find_buffer+68/90 =
Trace; c01277e8 get_hash_table+18/48
Trace; c0127b9a getblk+1e/144
Trace; c0145398 fat_getblk+3c/4c
Trace; c014a0db fat_add_cluster1+243/3cc
Trace; c0145b6c fat_get_cluster+58/98
Trace; c014a26f fat_add_cluster+b/2c
Trace; c014784e fat_file_write+17e/4ac
Trace; c01262d9 sys_write+e5/118
Trace; c01476d0 fat_file_write+0/4ac
Trace; c0109534 system_call+34/38
Code; c01277a8 find_buffer+68/90
_EIP:
Code; c01277a8 find_buffer+68/90 =
0: 8b 00 mov(%eax),%eax =
Code; c01277aa find_buffer+6a/90
2: 39 6a 04 cmp%ebp,0x4(%edx)
Code; c01277ad find_buffer+6d/90
5: 75 15 jne1c _EIP+0x1c c01277c4 find_buffer+84/90
Code; c01277af find_buffer+6f/90
7: 8b 4c 24 20 mov0x20(%esp,1),%ecx
Code; c01277b3 find_buffer+73/90
b: 39 4a 08 cmp%ecx,0x8(%edx)
Code; c01277b6 find_buffer+76/90
e: 75 0c jne1c _EIP+0x1c c01277c4 find_buffer+84/90
Code; c01277b8 find_buffer+78/90
10: 66 39 7a 0c cmp%di,0xc(%edx)
And here is the one from ext2 to ext2 copy under 2.4.2-ac5
Unable to handle kernel paging request at virtual address ea096084
c0128edf
*pde =
Oops:
CPU:0
EIP:0010:[c0128edf]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010003
eax: 081b ebx: 081b ecx: 0282 edx: ca096000
esi: dffd7cdc edi: ebp: 1000 esp: dec6de38
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 543, stackpage=dec6d000)
Stack: 220a 0001220a 0286 0010 c17cb2e0 c0133314 dffd7cdc
0003 c17cb2e0 c01333d2 0001 0007ccfc c0121be9
220a c17cb2e0 c17cb2e0 220a c0133687 c17cb2e0 1000
Call Trace: [c0133314] [c01333d2] [c0121be9] [c0133687] [c01339ab]
[c0123e8c] [c013423d]
[c014ffb0] [c0126886] [c014ffb0] [c0124a70] [c0131468] [c01090a3]
Code: 8b 44 82 18 0f af 5e 0c 89 42 14 03 5a 0c 40 75 05 8b 02
Via-rhine is not finding its interrupts under 2.2.19pre14
After I booted 2.2.19pre14 on a system with two via-rhine cards I see the following: via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 0. eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link . eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 0. eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link . and a network does not work due to these IRQ 0, I guess. In contrast when I will boot on the same hardware 2.4.2-ac5 then I get, among other things, via-rhine.c:v1.08b-LK1.1.7 8/9/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: Enabling device 00:09.0 (0094 - 0097) PCI: Found IRQ 9 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:0d.0 eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 9. eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link . PCI: Enabling device 00:0c.0 (0094 - 0097) PCI: Found IRQ 11 for device 00:0c.0 eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 11. eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link . Devices in question can be seen here: -[00]-+-00.0 VIA Technologies, Inc. VT8363/8365 [KT133/KM133] +-01.0-[01]00.0 ATI Technologies Inc Rage 128 RF +-04.0 VIA Technologies, Inc. VT82C686 [Apollo Super South] +-04.1 VIA Technologies, Inc. Bus Master IDE +-04.2 VIA Technologies, Inc. UHCI USB +-04.3 VIA Technologies, Inc. UHCI USB +-04.4 VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] +-09.0 VIA Technologies, Inc. VT86C100A [Rhine 10/100] +-0a.0 Symbios Logic Inc. (formerly NCR) 53c810 +-0c.0 VIA Technologies, Inc. VT86C100A [Rhine 10/100] +-0d.0 Ensoniq CT5880 [AudioPCI] \-11.0 Promise Technology, Inc. 20265 I do not have turned on a support for USB or audio in either of these two kernels. They are actually configured pretty similar (within a reason :-). But network is operational with 2.4.2-ac5. Hm... Even with these IRQ conflicts for eth0 one would think that eth1 should get its interrupt. It does not conflict with anything. Forgotten 'pci_enable()' somewhere? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 kernels - "attempt to access beyond end of device"
I have right now on hands a system with PDC20265 controller, not used as "raid", and it gives me a hard time. It looks like that after some number of megabytes copied to a disk, where "number" seems to be somewhere between 100 and 150, something in a kernel internal structures get overwritten and the whole thing just blows up. After an oops mostly anything will end up with errors so even a clean reboot will likely be not possible. In particular this prevents me from installing the recent Red Hat public beta with its kernel based on 2.4.1. I tried also some other variants of 2.4 kernels and so far results are the same. If there is something left in logs then I see messages of that sort (21:01 is /dev/hde1). 21:01: rw=0, want=536992869, limit=4506201 attempt to access beyond end of device 21:01: rw=0, want=536992870, limit=4506201 attempt to access beyond end of device The following log file is for 2.4.2-ac5. It has less extraneous stuff like LVM, and RAID, and USB support, and whatever... These were effects of an attempt to copy from one vfat to another vfat file system. Below is also decoded oops. Linux version 2.4.2-ac5 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #4 Mon Feb 26 18:11:13 MST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009dc00 @ (usable) BIOS-e820: 2400 @ 0009dc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 1feec000 @ 0010 (usable) BIOS-e820: 3000 @ 1ffec000 (ACPI data) BIOS-e820: 0001 @ 1ffef000 (reserved) BIOS-e820: 1000 @ 1000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 131052 zone(0): 4096 pages. zone(1): 126956 pages. zone(2): 0 pages. Kernel command line: initrd=initrd.img root=/dev/hdg3 BOOT_IMAGE=vmlinuz auto Initializing CPU#0 Detected 1109.899 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2215.11 BogoMIPS Memory: 513140k/524208k available (920k kernel code, 10672k reserved, 351k data, 176k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 9 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:0d.0 PCI: Found IRQ 11 for device 00:0c.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 341080kB/210008kB, 1024 slots per queue RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1 ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x6800-0x6807, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0x6808-0x680f, BIOS settings: hdg:DMA, hdh:pio hda: CREATIVE CD5233E, ATAPI CD/DVD-ROM drive hde: IBM-DTLA-307045, ATA DISK drive hdg: IBM-DTLA-307045, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide2 at 0x8000-0x8007,0x7802 on irq 10 ide3 at 0x7400-0x7407,0x7002 on irq 10 hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA Uniform CD-ROM driver
2.4 kernels - attempt to access beyond end of device
I have right now on hands a system with PDC20265 controller, not used as "raid", and it gives me a hard time. It looks like that after some number of megabytes copied to a disk, where "number" seems to be somewhere between 100 and 150, something in a kernel internal structures get overwritten and the whole thing just blows up. After an oops mostly anything will end up with errors so even a clean reboot will likely be not possible. In particular this prevents me from installing the recent Red Hat public beta with its kernel based on 2.4.1. I tried also some other variants of 2.4 kernels and so far results are the same. If there is something left in logs then I see messages of that sort (21:01 is /dev/hde1). 21:01: rw=0, want=536992869, limit=4506201 attempt to access beyond end of device 21:01: rw=0, want=536992870, limit=4506201 attempt to access beyond end of device The following log file is for 2.4.2-ac5. It has less extraneous stuff like LVM, and RAID, and USB support, and whatever... These were effects of an attempt to copy from one vfat to another vfat file system. Below is also decoded oops. Linux version 2.4.2-ac5 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #4 Mon Feb 26 18:11:13 MST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009dc00 @ (usable) BIOS-e820: 2400 @ 0009dc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 1feec000 @ 0010 (usable) BIOS-e820: 3000 @ 1ffec000 (ACPI data) BIOS-e820: 0001 @ 1ffef000 (reserved) BIOS-e820: 1000 @ 1000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 131052 zone(0): 4096 pages. zone(1): 126956 pages. zone(2): 0 pages. Kernel command line: initrd=initrd.img root=/dev/hdg3 BOOT_IMAGE=vmlinuz auto Initializing CPU#0 Detected 1109.899 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2215.11 BogoMIPS Memory: 513140k/524208k available (920k kernel code, 10672k reserved, 351k data, 176k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 9 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:0d.0 PCI: Found IRQ 11 for device 00:0c.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 341080kB/210008kB, 1024 slots per queue RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1 ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x6800-0x6807, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0x6808-0x680f, BIOS settings: hdg:DMA, hdh:pio hda: CREATIVE CD5233E, ATAPI CD/DVD-ROM drive hde: IBM-DTLA-307045, ATA DISK drive hdg: IBM-DTLA-307045, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide2 at 0x8000-0x8007,0x7802 on irq 10 ide3 at 0x7400-0x7407,0x7002 on irq 10 hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA Uniform CD-ROM driver
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote: > > I retried the mysticism and incantations (d -l 801feac d) at the srm > prompt, and the machine locked on fsck, under kernel 2.4.1-ac13. Like I wrote - I did not get to locks on fsck but then stuff was weird and if I would press sufficiently long maybe I would. I still had some use for my file systems so I did not try hard enough. Maybe we need black hens on the top of the magic quoted above? > I don't care about X on this system, all that much, honestly. "Technicolor" thingy seems to be side effect of your particular graphics card, no? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
>
> Well, the situation is improving, I suppose ...
>
> Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different _after_
I put on it the latest SRM and used this "magic incantation" from
Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
I copied from disk to disk directory tries with some 150 MB of data
in these and no ill effects.
OTOH things are still wobbly. This shows up in this that trying to
run e2fsck on a dirty file system while booting one 2.4.1 is likely
to come up with all kind of errors in a file sytstem requiring manual
interactions. If one breaks this process and repeats an exercise
on the same file system, but booting this time 2.2.18, then things
check out without any incidents. Once clean file systems can be
used with 2.4.1 again and no problems are reported.
I really do not see any kernel problems with 2.2 series kernels and IDE
patches.
> Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but
> doesn't lock up until somewhere between 13000 and 2.
I got various lockups but no "technicolor" on any occasion. Recently
I even got a picture with X and G450 Matrox card although one can
be very careful not to look at it a wrong angle or a power button will
be the only way out.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
Well, the situation is improving, I suppose ...
Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different _after_
I put on it the latest SRM and used this "magic incantation" from
Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
I copied from disk to disk directory tries with some 150 MB of data
in these and no ill effects.
OTOH things are still wobbly. This shows up in this that trying to
run e2fsck on a dirty file system while booting one 2.4.1 is likely
to come up with all kind of errors in a file sytstem requiring manual
interactions. If one breaks this process and repeats an exercise
on the same file system, but booting this time 2.2.18, then things
check out without any incidents. Once clean file systems can be
used with 2.4.1 again and no problems are reported.
I really do not see any kernel problems with 2.2 series kernels and IDE
patches.
Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but
doesn't lock up until somewhere between 13000 and 2.
I got various lockups but no "technicolor" on any occasion. Recently
I even got a picture with X and G450 Matrox card although one can
be very careful not to look at it a wrong angle or a power button will
be the only way out.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote: I retried the mysticism and incantations (d -l 801feac d) at the srm prompt, and the machine locked on fsck, under kernel 2.4.1-ac13. Like I wrote - I did not get to locks on fsck but then stuff was weird and if I would press sufficiently long maybe I would. I still had some use for my file systems so I did not try hard enough. Maybe we need black hens on the top of the magic quoted above? I don't care about X on this system, all that much, honestly. "Technicolor" thingy seems to be side effect of your particular graphics card, no? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 not fully sane on Alpha - file systems
To follow my own message about lockups on UP1100. This time I tried to boot 2.4.1-ac1. Results are really the same but this time an attempt to copy kernel source from a partition on a SCSI drive to another one on an IDE drive brought different message. I include it below. When trying to immediatly reboot with this kernel a machine locks up in the middle of fsck. Luckily 2.2.18 does not have problems with that or other disk operations for that matter. Here is what I collected in logs this time before a machine went "poof". kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753664 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753664 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753665, count = 1 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753683 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753686, count = 5 kernel: EXT2-fs error (device ide0(3,1)): ext2_add_entry: bad entry in directory #379108: inode out of bounds - offset=0, inode=4049125, rec_len=12, name_len=1 last message repeated 10 times kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753686 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753687 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753688, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753688 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753689, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753700 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753702, count = 6 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753702 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753705, count = 5 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753734 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753739, count = 3 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753739 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753746, count = 1 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753746 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753747, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753747 BTW - on a target disk there are no traces that somebody attempted to copy something. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote: > On Wed, 31 Jan 2001, Michal Jaegermann wrote: > > > I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine > > happens to have two SCSI disks on sym53c875 controller and two IDE > > drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". > > ALI M1535D pci-ide bridge, isn't it? That's what the specs on > API's webpage seem to indicate. 'lspci' claims that this is: "07.0 Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]" > > Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it > cronks out. Probably. > In my case, any serious I/O on the IDE drives quickly results in pretty > technicolor on the VGA screen, and then a hard lockup. No, no technicolor or other sounds effects. The whole thing just locks up with a power switch as the only option. > Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck > the drives. It hangs after about the 2nd-3rd partition, again in a hard > lockup. My box is much healtier than that. Regardless if I booted into a file system on a SCSI drive or on an IDE drive (I happen to have those options although I prefer IDE - I have there something which I can loose without any real pain :-) I can still fsck drives healthy after the crash but I did NOT risk fsck under 2.4.1. Things looks way too screwy for this. > > My WAG is that there are problems in the ALI driver. Possibly, but I crashed the whole thing without mounting anything from IDE drives at all. There are still there but unused. I simply managed to get something in logs for the case described. Note that errors I quoted are from a device 08:05, i.e. SCSI driver (/dev/sda5 to be more precise). When my compiler went bonkers and started to read clearly some random stuff instead of sources then the whole action was happening on a SCSI drive. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote: On Wed, 31 Jan 2001, Michal Jaegermann wrote: I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine happens to have two SCSI disks on sym53c875 controller and two IDE drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". ALI M1535D pci-ide bridge, isn't it? That's what the specs on API's webpage seem to indicate. 'lspci' claims that this is: "07.0 Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]" Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it cronks out. Probably. In my case, any serious I/O on the IDE drives quickly results in pretty technicolor on the VGA screen, and then a hard lockup. No, no technicolor or other sounds effects. The whole thing just locks up with a power switch as the only option. Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck the drives. It hangs after about the 2nd-3rd partition, again in a hard lockup. My box is much healtier than that. Regardless if I booted into a file system on a SCSI drive or on an IDE drive (I happen to have those options although I prefer IDE - I have there something which I can loose without any real pain :-) I can still fsck drives healthy after the crash but I did NOT risk fsck under 2.4.1. Things looks way too screwy for this. My WAG is that there are problems in the ALI driver. Possibly, but I crashed the whole thing without mounting anything from IDE drives at all. There are still there but unused. I simply managed to get something in logs for the case described. Note that errors I quoted are from a device 08:05, i.e. SCSI driver (/dev/sda5 to be more precise). When my compiler went bonkers and started to read clearly some random stuff instead of sources then the whole action was happening on a SCSI drive. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 not fully sane on Alpha - file systems
To follow my own message about lockups on UP1100. This time I tried to boot 2.4.1-ac1. Results are really the same but this time an attempt to copy kernel source from a partition on a SCSI drive to another one on an IDE drive brought different message. I include it below. When trying to immediatly reboot with this kernel a machine locks up in the middle of fsck. Luckily 2.2.18 does not have problems with that or other disk operations for that matter. Here is what I collected in logs this time before a machine went "poof". kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753664 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753664 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753665, count = 1 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753683 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753686, count = 5 kernel: EXT2-fs error (device ide0(3,1)): ext2_add_entry: bad entry in directory #379108: inode out of bounds - offset=0, inode=4049125, rec_len=12, name_len=1 last message repeated 10 times kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753686 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753687 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753688, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753688 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753689, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753700 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753702, count = 6 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753702 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753705, count = 5 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753734 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753739, count = 3 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753739 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753746, count = 1 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753746 kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system zones - Block = 753747, count = 7 kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system zone - block = 753747 BTW - on a target disk there are no traces that somebody attempted to copy something. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1 not fully sane on Alpha - file systems
I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine happens to have two SCSI disks on sym53c875 controller and two IDE drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". It boots and in the first moment makes even a pretty good impression of beeing healthy. But an attempt to compile something causes the whole setup to start behaving weird, with a compiler obviously unable to find both itself and the right sources, and the whole thing ends in a silent lockup. On the second boot I tried to copy kernel sources from a SCSI to an IDE drive. This time I got something in my logs and the same stuff was printed on my screen before everything lockded up really tight again (no sysrq). Here it is: kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=4294934529, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in directory #250255: directory entry across blocks - offset=0, inode=198505472, rec_len=32768, name_len=255 (and the machine dies at this point). There is nothing wrong with this device and a file system on it. Copying the same way, or compiling the same sources, but when booted with 2.2.18 does not present a whiff of trouble and e2fsck, luckily enough, finds my file systems still in place. One should be grateful for small favours. Anybody have seen something similar? Michal [EMAIL PROTECTED] p.s. I find a bit humorous the fact that the code required to recognize that one has _some_ partition table (I happen to have two kinds at the moment) is billed in a config file as ADVANCED. It did the job anyway. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1 not fully sane on Alpha - file systems
I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine happens to have two SCSI disks on sym53c875 controller and two IDE drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". It boots and in the first moment makes even a pretty good impression of beeing healthy. But an attempt to compile something causes the whole setup to start behaving weird, with a compiler obviously unable to find both itself and the right sources, and the whole thing ends in a silent lockup. On the second boot I tried to copy kernel sources from a SCSI to an IDE drive. This time I got something in my logs and the same stuff was printed on my screen before everything lockded up really tight again (no sysrq). Here it is: kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=4294934529, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in directory #250255: directory entry across blocks - offset=0, inode=198505472, rec_len=32768, name_len=255 (and the machine dies at this point). There is nothing wrong with this device and a file system on it. Copying the same way, or compiling the same sources, but when booted with 2.2.18 does not present a whiff of trouble and e2fsck, luckily enough, finds my file systems still in place. One should be grateful for small favours. Anybody have seen something similar? Michal [EMAIL PROTECTED] p.s. I find a bit humorous the fact that the code required to recognize that one has _some_ partition table (I happen to have two kinds at the moment) is billed in a config file as ADVANCED. It did the job anyway. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre24 - forgotten symbols
With an SMP kernel one gets, in particular, depmod: *** Unresolved symbols in /lib/modules/2.2.18pre24/misc/agpgart.o depmod: smp_call_function depmod: smp_num_cpus The machine affected is actually Alpha but likely this is not relevant. Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre24 - forgotten symbols
With an SMP kernel one gets, in particular, depmod: *** Unresolved symbols in /lib/modules/2.2.18pre24/misc/agpgart.o depmod: smp_call_function depmod: smp_num_cpus The machine affected is actually Alpha but likely this is not relevant. Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vm in 2.2.18pre23 - behaving worse
I was busy with other things and did not track 2.2.18pre kernels very carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression that a situation with a virtual memory handling is worse than it was, say, in 2.2.18pre15. I can now see in /var/log/messages entries like "VM: killing process sh" or "VM: killing process emacs" because I was compiling a kernel. This does not happen consistently, predictably, or very often but it does happen and I should not be oom. Nothing else crashes, or leaves any traces in log files, and a machine continues apparently not disturbed, but a process is gone. Applying patches from Andrea and the one from Rik, posted some week ago under "blindingly stupid 2.2 VM bug" subject, does not seem to help very much. Sigh! Am I isolated in this experience? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vm in 2.2.18pre23 - behaving worse
I was busy with other things and did not track 2.2.18pre kernels very carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression that a situation with a virtual memory handling is worse than it was, say, in 2.2.18pre15. I can now see in /var/log/messages entries like "VM: killing process sh" or "VM: killing process emacs" because I was compiling a kernel. This does not happen consistently, predictably, or very often but it does happen and I should not be oom. Nothing else crashes, or leaves any traces in log files, and a machine continues apparently not disturbed, but a process is gone. Applying patches from Andrea and the one from Rik, posted some week ago under "blindingly stupid 2.2 VM bug" subject, does not seem to help very much. Sigh! Am I isolated in this experience? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ux164 (ruffian) fixes
On Tue, Nov 21, 2000 at 10:47:20AM -0800, Richard Henderson wrote: > On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote: > >Interesting, other pyxis machines do not seem to be so sensitive, > >so I guess some design problems with ux164 motherboard - all this > >looks pretty much like timing issues. > > Wow. Thanks for following through on this. I can now confirm that I can boot using SCSI disks (the fact that this was possible for a while into IDE was a life-saver here :-) a Ruffian (pyxis) Alpha using 2.4.0-test11 kernel and two patches posted by Ivan (bridges-2.4.0t11.gz and extra ruffian fixes). Here are fragments from 'dmesg': Booting on Ruffian using machine vector Ruffian from MILO Command line: bootdevice=sda2 bootfile=/vml240o11.gz root=/dev/sda2 SCSI subsystem driver Revision: 1.00 sym53c8xx: at PCI bus 1, device 13, function 0 sym53c8xx: 53c875 detected sym53c875-0: rev 0x3 on pci bus 1 device 13 function 0 irq 20 sym53c875-0: ID 7, Fast-20, Parity Checking sym53c875-0: on-chip RAM at 0xa101000 sym53c875-0: restart (scsi reset). sym53c875-0: Downloading SCSI SCRIPTS. scsi0 : sym53c8xx - version 1.6b Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 sym53c875-0-<2,0>: tagged command queue depth set to 8 sym53c875-0-<10,0>: tagged command queue depth set to 8 Detected scsi disk sda at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 VFS: Mounted root (ext2 filesystem) readonly. Those who posted "me too" could you please test that this is not only a fluke on my particular machine? Thanks a bunch, Ivan. Also thanks are extended to Gerard Roudier who provided a crucial hint in the moment when we appeared to be completly stuck. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ux164 (ruffian) fixes
On Tue, Nov 21, 2000 at 10:47:20AM -0800, Richard Henderson wrote: On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote: Interesting, other pyxis machines do not seem to be so sensitive, so I guess some design problems with ux164 motherboard - all this looks pretty much like timing issues. Wow. Thanks for following through on this. I can now confirm that I can boot using SCSI disks (the fact that this was possible for a while into IDE was a life-saver here :-) a Ruffian (pyxis) Alpha using 2.4.0-test11 kernel and two patches posted by Ivan (bridges-2.4.0t11.gz and extra ruffian fixes). Here are fragments from 'dmesg': Booting on Ruffian using machine vector Ruffian from MILO Command line: bootdevice=sda2 bootfile=/vml240o11.gz root=/dev/sda2 SCSI subsystem driver Revision: 1.00 sym53c8xx: at PCI bus 1, device 13, function 0 sym53c8xx: 53c875 detected sym53c875-0: rev 0x3 on pci bus 1 device 13 function 0 irq 20 sym53c875-0: ID 7, Fast-20, Parity Checking sym53c875-0: on-chip RAM at 0xa101000 sym53c875-0: restart (scsi reset). sym53c875-0: Downloading SCSI SCRIPTS. scsi0 : sym53c8xx - version 1.6b Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 sym53c875-0-2,0: tagged command queue depth set to 8 sym53c875-0-10,0: tagged command queue depth set to 8 Detected scsi disk sda at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 VFS: Mounted root (ext2 filesystem) readonly. Those who posted "me too" could you please test that this is not only a fluke on my particular machine? Thanks a bunch, Ivan. Also thanks are extended to Gerard Roudier who provided a crucial hint in the moment when we appeared to be completly stuck. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: easy-to-fix bug in /dev/null driver
On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
>
> I still think that write_null() should be rewritten as:
>
> ===
> static ssize_t write_null(struct file * file, const char * buf,
> size_t count, loff_t *ppos)
> {
> return (count <= 2147483647) ? count : 2147483647;
> }
> ===
>
> This would fix the problem without introducing any new errors.
> (Unless someone change the definitions of ssize_t and size_t!!)
Someone already did. Or, more precisely, there are platforms where
values used in 'return' above are bogus.
Shifting 1 up by sizeof(ssize_t) * 8 - 1 and subtracting one from
the result, in order to derive the maximal allowable value, might work.
I do not think that we have anything with non-8 bit bytes yet.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: easy-to-fix bug in /dev/null driver
On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
I still think that write_null() should be rewritten as:
===
static ssize_t write_null(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
return (count = 2147483647) ? count : 2147483647;
}
===
This would fix the problem without introducing any new errors.
(Unless someone change the definitions of ssize_t and size_t!!)
Someone already did. Or, more precisely, there are platforms where
values used in 'return' above are bogus.
Shifting 1 up by sizeof(ssize_t) * 8 - 1 and subtracting one from
the result, in order to derive the maximal allowable value, might work.
I do not think that we have anything with non-8 bit bytes yet.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] __builtin_expect in 2.4.0-test11pre4
At least on Alpha, and possibly other architectures, the following minor correction is needed: --- linux-2.4.0p11p/include/asm-alpha/semaphore.h~ Mon Nov 13 14:01:10 2000 +++ linux-2.4.0p11p/include/asm-alpha/semaphore.h Mon Nov 13 14:03:44 2000 @@ -11,6 +11,7 @@ #include #include #include +#include #define DEBUG_SEMAPHORE 0 #define DEBUG_RW_SEMAPHORE 0 or various version of a compiler are blowing a fuse on a missing __builtin_expect prototype. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] __builtin_expect in 2.4.0-test11pre4
At least on Alpha, and possibly other architectures, the following minor correction is needed: --- linux-2.4.0p11p/include/asm-alpha/semaphore.h~ Mon Nov 13 14:01:10 2000 +++ linux-2.4.0p11p/include/asm-alpha/semaphore.h Mon Nov 13 14:03:44 2000 @@ -11,6 +11,7 @@ #include asm/current.h #include asm/system.h #include asm/atomic.h +#include asm/compiler.h #define DEBUG_SEMAPHORE 0 #define DEBUG_RW_SEMAPHORE 0 or various version of a compiler are blowing a fuse on a missing __builtin_expect prototype. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 10:09:39PM -0500, Jeff Garzik wrote: > [EMAIL PROTECTED] wrote: > > 4. Boot Time Failures > > > * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are > >not configured correctly Michal Jaegermann; Richard Henderson may > >have an idea what's failing.) > > Move to patch-exists-but-not-merged. rth has patches, co-developed with > Ivan Kokshaysky Would be nice, wouldn't it. Unfortunately this is not the case. rth has patches which help to boot his machine, and few others, but this still does not work in general. Ivan works now pretty hard, with my involvment into this, trying to identify and fix the problem. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 10:09:39PM -0500, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: 4. Boot Time Failures * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are not configured correctly Michal Jaegermann; Richard Henderson may have an idea what's failing.) Move to patch-exists-but-not-merged. rth has patches, co-developed with Ivan Kokshaysky Would be nice, wouldn't it. Unfortunately this is not the case. rth has patches which help to boot his machine, and few others, but this still does not work in general. Ivan works now pretty hard, with my involvment into this, trying to identify and fix the problem. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote: > > It was posted to lkml, so no link (except if you want to dig through > > lkml mail archives). > > It booted but then it oops'ed before userland I belive. I tried it this > morning and didn't have much time. It did find the scsi controller (which > is across the bridge) and the drives attached so it does appear to be > working. Looks so far that I am the worst off. If I am trying to boot with a root on a SCSI device then either a controller is misdetected, or goes into an infinite "abort/reset" loop, or it does not initialize properly and disks are not found. This is a non-exclusive, logical, "or". :-) Booting to an IDE device makes difference only in that that if I can boot then SCSI disks will be simply ignored. If somebody is interested in a collection of dmesg outputs, with DEBUG printks, from such attempts then I am game. Ivan was getting these pretty consistently. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote: It was posted to lkml, so no link (except if you want to dig through lkml mail archives). It booted but then it oops'ed before userland I belive. I tried it this morning and didn't have much time. It did find the scsi controller (which is across the bridge) and the drives attached so it does appear to be working. Looks so far that I am the worst off. If I am trying to boot with a root on a SCSI device then either a controller is misdetected, or goes into an infinite "abort/reset" loop, or it does not initialize properly and disks are not found. This is a non-exclusive, logical, "or". :-) Booting to an IDE device makes difference only in that that if I can boot then SCSI disks will be simply ignored. If somebody is interested in a collection of dmesg outputs, with DEBUG printks, from such attempts then I am game. Ivan was getting these pretty consistently. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FIX: Nice oops from agpgart - 2.2 kernels and Alpha
I complained few days ago that 'agpgart.o' module from 2.2.18pre
is causing a kernel oops. The problem turned out to be an apparent
assumption that PCI memory <-> memory mapping is an identity and
this is not always the case.
Here is a patch applicable to all 2.2.18pre kernels with agpgart
support:
--- linux-2.2.18px/drivers/char/agp/agp.h~ Tue Oct 3 16:03:13 2000
+++ linux-2.2.18px/drivers/char/agp/agp.h Tue Oct 17 10:23:14 2000
@@ -27,6 +27,8 @@
#ifndef _AGP_BACKEND_PRIV_H
#define _AGP_BACKEND_PRIV_H 1
+#include
+
enum aper_size_type {
U8_APER_SIZE,
U16_APER_SIZE,
@@ -119,13 +121,13 @@
void (*free_by_type) (agp_memory *);
};
-#define OUTREG32(mmap, addr, val) *(volatile u32 *)(mmap + (addr)) = (val)
-#define OUTREG16(mmap, addr, val) *(volatile u16 *)(mmap + (addr)) = (val)
-#define OUTREG8 (mmap, addr, val) *(volatile u8 *) (mmap + (addr)) = (val)
-
-#define INREG32(mmap, addr) *(volatile u32 *)(mmap + (addr))
-#define INREG16(mmap, addr) *(volatile u16 *)(mmap + (addr))
-#define INREG8 (mmap, addr) *(volatile u8 *) (mmap + (addr))
+#define OUTREG32(mmap, addr, val) writel((val),(mmap + (addr)))
+#define OUTREG16(mmap, addr, val) writew((val),(mmap + (addr)))
+#define OUTREG8 (mmap, addr, val) writeb((val),(mmap + (addr)))
+
+#define INREG32(mmap, addr) readl(mmap + (addr))
+#define INREG16(mmap, addr) readw(mmap + (addr))
+#define INREG8 (mmap, addr) readb(mmap + (addr))
#define CACHE_FLUSHagp_bridge.cache_flush
#define A_SIZE_8(x)((aper_size_info_8 *) x)
With this patch 'agpgart.o' module compiled on x86 machine is
byte-by-byte identical as the one without it. OTOH on UP1100 Alpha
with an Irongate after the fixed module is inserted instead of
crashing prints this in dmesg:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 204M
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 512M @ 0x4000
I have no idea if this is really useful on Alpha and if there are no
other address mapping problems still there but the patch above should
at least be a start. :-)
A peek at agpgart sources from 2.4 reveals that this mapping problem
is absent there as INREG... and OUTREG... macros are defined with
a help of __raw_read... and __raw_write... which function the same
like the stuff above from 2.2.
On x86 machines 'agpgart' appears to be really doing something. :-)
A small test program 'testgart' (got in mail from somebody) reports
a memory benchmark speed in 580-590 mb/s range before I started my
X server and some 720+ mb/s after X was started and exited. Don't
ask me why. :-)
The same 'testgart' on Alpha, after obviously x86 specific or not
applicable stuff was edited out, is causing a spectacular crash
with mulitple oopses, a total lockup and zilch in log files. So
not everything is healthy yet but not bombing out for a start
seems like a good beginning.
Michal
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
FIX: Nice oops from agpgart - 2.2 kernels and Alpha
I complained few days ago that 'agpgart.o' module from 2.2.18pre
is causing a kernel oops. The problem turned out to be an apparent
assumption that PCI memory - memory mapping is an identity and
this is not always the case.
Here is a patch applicable to all 2.2.18pre kernels with agpgart
support:
--- linux-2.2.18px/drivers/char/agp/agp.h~ Tue Oct 3 16:03:13 2000
+++ linux-2.2.18px/drivers/char/agp/agp.h Tue Oct 17 10:23:14 2000
@@ -27,6 +27,8 @@
#ifndef _AGP_BACKEND_PRIV_H
#define _AGP_BACKEND_PRIV_H 1
+#include asm/io.h
+
enum aper_size_type {
U8_APER_SIZE,
U16_APER_SIZE,
@@ -119,13 +121,13 @@
void (*free_by_type) (agp_memory *);
};
-#define OUTREG32(mmap, addr, val) *(volatile u32 *)(mmap + (addr)) = (val)
-#define OUTREG16(mmap, addr, val) *(volatile u16 *)(mmap + (addr)) = (val)
-#define OUTREG8 (mmap, addr, val) *(volatile u8 *) (mmap + (addr)) = (val)
-
-#define INREG32(mmap, addr) *(volatile u32 *)(mmap + (addr))
-#define INREG16(mmap, addr) *(volatile u16 *)(mmap + (addr))
-#define INREG8 (mmap, addr) *(volatile u8 *) (mmap + (addr))
+#define OUTREG32(mmap, addr, val) writel((val),(mmap + (addr)))
+#define OUTREG16(mmap, addr, val) writew((val),(mmap + (addr)))
+#define OUTREG8 (mmap, addr, val) writeb((val),(mmap + (addr)))
+
+#define INREG32(mmap, addr) readl(mmap + (addr))
+#define INREG16(mmap, addr) readw(mmap + (addr))
+#define INREG8 (mmap, addr) readb(mmap + (addr))
#define CACHE_FLUSHagp_bridge.cache_flush
#define A_SIZE_8(x)((aper_size_info_8 *) x)
With this patch 'agpgart.o' module compiled on x86 machine is
byte-by-byte identical as the one without it. OTOH on UP1100 Alpha
with an Irongate after the fixed module is inserted instead of
crashing prints this in dmesg:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 204M
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 512M @ 0x4000
I have no idea if this is really useful on Alpha and if there are no
other address mapping problems still there but the patch above should
at least be a start. :-)
A peek at agpgart sources from 2.4 reveals that this mapping problem
is absent there as INREG... and OUTREG... macros are defined with
a help of __raw_read... and __raw_write... which function the same
like the stuff above from 2.2.
On x86 machines 'agpgart' appears to be really doing something. :-)
A small test program 'testgart' (got in mail from somebody) reports
a memory benchmark speed in 580-590 mb/s range before I started my
X server and some 720+ mb/s after X was started and exited. Don't
ask me why. :-)
The same 'testgart' on Alpha, after obviously x86 specific or not
applicable stuff was edited out, is causing a spectacular crash
with mulitple oopses, a total lockup and zilch in log files. So
not everything is healthy yet but not bombing out for a start
seems like a good beginning.
Michal
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Nice oops from agpgart - 2.2 kernels and Alpha
On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller" an attempt to use 'agpgart' support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels. With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck after oops and does not boot. If CONFIG_AGP=m is used then an attempt to insert 'agpgart' module ends up with the following oops (after a run through 'ksymoops'): ksymoops 2.3.4 on alpha 2.2.18pre15x. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.18pre15x/ (default) -m /boot/System.map-2.2.18pre15x (specified) Unable to handle kernel paging request at virtual address 6204 insmod(1048): Oops 1 pc = [] ra = [] ps = Using defaults from ksymoops -t elf64-alpha -a alpha v0 = t0 = 6200 t1 = 6200 t2 = 0c322000 t3 = fc802000 t4 = fe85 t5 = fe85 t6 = fffe t7 = fc000c2a s0 = fe844e50 s1 = fe844f50 s2 = fe844cb0 s3 = 0001 s4 = 0001 s5 = fe844e50 s6 = fe840090 a0 = fd01fe14 a1 = 00b0 a2 = 0080 a3 = fc569310 a4 = fc000c2a3d60 a5 = fc000c2a3d58 t8 = 0001 t9 = fc523078 t10= t11= fc523070 pv = fc31d640 47f01412 or zero,128,a2 4441f102 andnot t1,15,t1 44420401 or t1,t1,t0 b05e0020 stl t1,32(sp) 4821f621 zapnot t0,15,t0 b42a stq t0,0(s1) a6090028 ldq a0,40(s0) Trace: 332014 33bc18 310cf8 42fe80 Warning (Oops_read): Code line not seen, dumping what data is available >>PC; fe841ba8 <[agpgart]amd_irongate_configure+68/140> <= Trace; 00332014 Before first symbol Trace; 0033bc18 Before first symbol Trace; 00310cf8 Before first symbol Trace; 0042fe80 Before first symbol 1 warning issued. Results may not be reliable. followed by a "Segmentation fault" from insmod. Unfortunately option -m produces an empty symbol map for the module; also later the module is not removable with the following output from lsmod: agpgart21312 1 (initializing) This bomb happens on this code /* Write out the address of the gatt table */ OUTREG32(amd_irongate_private.registers, AMD_ATTBASE, agp_bridge.gatt_bus_addr); from amd_irongate_configure() in drivers/char/agp/agpgart_be.c. I dropped few printk's there like that: /* Get the memory mapped registers */ pci_read_config_dword(agp_bridge.dev, AMD_MMBASE, ); printk(KERN_INFO PFX "Read irongate temp %x\n", temp); temp = (temp & PCI_BASE_ADDRESS_MEM_MASK); printk(KERN_INFO PFX "Masked temp to %x\n", temp); amd_irongate_private.registers = (volatile u8 *) ioremap(temp, 4096); printk(KERN_INFO PFX "Updated private registers to %x\n", amd_irongate_private.registers); and results are as follows: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 204M agpgart: Detected AMD Irongate chipset agpgart: Read irongate temp 6208 agpgart: Masked temp to 6200 agpgart: Updated private registers to 6200 Unable to handle kernel paging request at virtual address 6204 Any ideas what is wrong with this picture? BTW - despite the following commment in drivers/char/drm/drm.h "Dec 1999, Richard Henderson <[EMAIL PROTECTED]>, move to generic cmpxchg." an attempt to compile 'drm' module includes some x86 specific code from drivers/char/drm/drmP.h, like this: __asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2" : "=a"(prev) : "q"(new), "m"(*__xg(ptr)), "0"(old) : "memory"); and, as you can guess, does not compile on Alpha. But that is the next problem after 'agpgart'. :-) Michal [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: want tool to open RPM package on Window 95
> Somewhere floating around there is a perl version of rpm2cpio.
This is what I wrote one day a long time ago:
#!/usr/bin/perl -w
use strict;
my ($buffer, $pos, $gzmagic);
$gzmagic = "\037\213";
open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
while(1) {
exit 1 unless defined($pos = read STDIN, $buffer, 8192) and $pos > 0;
next unless ($pos = index $buffer, $gzmagic) >= 0;
print OUT substr $buffer, $pos;
last;
}
print OUT ;
exit 0;
Yes, I know that I should not mix 'read' with stdio but it worked
every time I tried the above. :-)
Can we go back now to kernel issues?
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: want tool to open RPM package on Window 95
Somewhere floating around there is a perl version of rpm2cpio.
This is what I wrote one day a long time ago:
#!/usr/bin/perl -w
use strict;
my ($buffer, $pos, $gzmagic);
$gzmagic = "\037\213";
open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
while(1) {
exit 1 unless defined($pos = read STDIN, $buffer, 8192) and $pos 0;
next unless ($pos = index $buffer, $gzmagic) = 0;
print OUT substr $buffer, $pos;
last;
}
print OUT STDIN;
exit 0;
Yes, I know that I should not mix 'read' with stdio but it worked
every time I tried the above. :-)
Can we go back now to kernel issues?
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Trident soundcard on Alpha/UX
An attempt to use on Alpha UX a 'trident' module on 2.2.18pre15 (and 2.2.17, and 2.2.16 with patches) with a sound card present ends up with the following lines in 'dmesg': Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 23:57:52 Oct 3 2000 trident: Trident 4DWave DX found at IO 0x9800, IRQ 27 ac97_codec: AC97 Audio codec, vendor id1: 0x4352, id2: 0x5903 (Cirrus Logic CS4297) trident: DMA buffer beyond 1 GB; bus address = 0x48158000, size = 32768 and that's it. A presence or absence of 'bigmem" patches from Andrea does not seem to have effects. Any ideas how to prevent that from happening? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Trident soundcard on Alpha/UX
An attempt to use on Alpha UX a 'trident' module on 2.2.18pre15 (and 2.2.17, and 2.2.16 with patches) with a sound card present ends up with the following lines in 'dmesg': Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 23:57:52 Oct 3 2000 trident: Trident 4DWave DX found at IO 0x9800, IRQ 27 ac97_codec: AC97 Audio codec, vendor id1: 0x4352, id2: 0x5903 (Cirrus Logic CS4297) trident: DMA buffer beyond 1 GB; bus address = 0x48158000, size = 32768 and that's it. A presence or absence of 'bigmem" patches from Andrea does not seem to have effects. Any ideas how to prevent that from happening? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4 kernels do not boot on UX (Alpha)
I tried to boot recent 2.4.0 kernels (the last one 2.4.0-test9-pre5) on Ruffian type of Alpha, also known as UX, with a notable lack of success. So far I had not a single succesful boot. My test machine ran without any hiccups various 2.2 kernels, patched and upatched, and before that a long list of 2.0 kernels. Here are excerpts from boot messages, transcribed from a screen, which seem to be relevant to the problem: Booting GENERIC on Ruffian using machine vector Ruffian from MILO Calibrating delay loop... 1191.18 BogoMips pci: cia revision 1 (pyxis) ... pci: passed tb register update test pci: passed passed sg loopback i/o read test pci: passed tbia test pci: passed pte write cache snoop test pci: failed valid tad invalid pte reload test (mcheck; workaround avialable) pci: passed pci machine check test PCI: Failed to allocate resource 8 for Digital Equipment Corporation DECchip 21052 PCI: Failed to allocate resource 1 for Trident Microsystems 4DWave DX PCI: Failed to allocate resource 1 for Symbios Logic Inc. (formerly NCR) 53c875 Activating ISA DMA hang workarounds . hda: IBM-DJNA=370910, ATA DISK driver ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 17803440 sectors (9115 MB) w/1966KiB Cache, CHS=17662/16/63, (U)DMA Partition check: hda: unknown partition table sym53c8xx: at PCI bus 1, device 13, function 0 sym53c8xx: 53c875 detected sym53c876-0: rev 0xff on pci bus 1 device 13 function 0 irq 20 sym53c876-0: ID 7, Fast-20, Parity Checking, Differential sym53c876-0: on-chip RAM at 0xa00 CACHE TEST FAILED: script execution failed. start=4fea4dd8, pc=. end=4fea4df8 CACHE INCORRECTLY CONFIGURED. sym53c876-0: giving up ... and a kernel panic because my root file system on /dev/sda2 cannot be mounted. The machine is dead with even a keyboard gone. There is also another failure mode when some messages are scrolling up the screen too fast to be of any use because a screen is flooded with repeated messages: pc_keyb: controller jammed (0xFF). followed by: keyboard timed out [1]. and a kernel hangs the moment it should print hda: IBM-DJNA-370910, ATA DISK drive line. The second failure mode happens apparently less often but apparently at random. For comparison here are similar lines from a correct boot of a kernel from 2.2 series on the same machine: Booting GENERIC on Ruffian using machine vector Ruffian from MILO Calibrating delay loop... 595.59 BogoMIPS hda: IBM-DJNA-370910, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: IBM-DJNA-370910, 8693MB w/1966kB Cache, CHS=17662/16/63, (U)DMA ... sym53c8xx: at PCI bus 32, device 13, function 0 sym53c8xx: 53c875 detected sym53c875-0: rev 0x3 on pci bus 32 device 13 function 0 irq 20 sym53c875-0: ID 7, Fast-20, Parity Checking scsi0 : sym53c8xx-1.7.0-2709 scsi : 1 host. Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 2, lun 0 Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 scsi : detected 1 SCSI cdrom 2 SCSI disks total. sym53c875-0-<6,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 16) Partition check: sda: sda1 sda2 sda3 sda4 < sda5 sda6 > sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 > hda: hda1 hda2 hda3 hda4 VFS: Mounted root (ext2 filesystem) readonly. In particular note differences in a detected SCSI controller and lack of problems on a partition check. I also do not know from where "DECchip 21052" is coming with 2.4 kernel. The real ethernet controller is DS21143 Tulip rev. 48. This is a PCI layout as reported by 'lspci -tv': -[00]-+-0d.0-[01]--+-0a.0 Trident Microsystems 4DWave DX |\-0d.0 Symbios Logic Inc. (formerly NCR) 53c875 +-0e.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +-0e.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] +-0f.0 Digital Equipment Corporation DECchip 21142/43 \-11.0 Texas Instruments TVP4020 [Permedia 2] Any ideas what gives here? Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4 kernels do not boot on UX (Alpha)
I tried to boot recent 2.4.0 kernels (the last one 2.4.0-test9-pre5) on Ruffian type of Alpha, also known as UX, with a notable lack of success. So far I had not a single succesful boot. My test machine ran without any hiccups various 2.2 kernels, patched and upatched, and before that a long list of 2.0 kernels. Here are excerpts from boot messages, transcribed from a screen, which seem to be relevant to the problem: Booting GENERIC on Ruffian using machine vector Ruffian from MILO Calibrating delay loop... 1191.18 BogoMips pci: cia revision 1 (pyxis) ... pci: passed tb register update test pci: passed passed sg loopback i/o read test pci: passed tbia test pci: passed pte write cache snoop test pci: failed valid tad invalid pte reload test (mcheck; workaround avialable) pci: passed pci machine check test PCI: Failed to allocate resource 8 for Digital Equipment Corporation DECchip 21052 PCI: Failed to allocate resource 1 for Trident Microsystems 4DWave DX PCI: Failed to allocate resource 1 for Symbios Logic Inc. (formerly NCR) 53c875 Activating ISA DMA hang workarounds . hda: IBM-DJNA=370910, ATA DISK driver ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 17803440 sectors (9115 MB) w/1966KiB Cache, CHS=17662/16/63, (U)DMA Partition check: hda: unknown partition table sym53c8xx: at PCI bus 1, device 13, function 0 sym53c8xx: 53c875 detected sym53c876-0: rev 0xff on pci bus 1 device 13 function 0 irq 20 sym53c876-0: ID 7, Fast-20, Parity Checking, Differential sym53c876-0: on-chip RAM at 0xa00 CACHE TEST FAILED: script execution failed. start=4fea4dd8, pc=. end=4fea4df8 CACHE INCORRECTLY CONFIGURED. sym53c876-0: giving up ... and a kernel panic because my root file system on /dev/sda2 cannot be mounted. The machine is dead with even a keyboard gone. There is also another failure mode when some messages are scrolling up the screen too fast to be of any use because a screen is flooded with repeated messages: pc_keyb: controller jammed (0xFF). followed by: keyboard timed out [1]. and a kernel hangs the moment it should print hda: IBM-DJNA-370910, ATA DISK drive line. The second failure mode happens apparently less often but apparently at random. For comparison here are similar lines from a correct boot of a kernel from 2.2 series on the same machine: Booting GENERIC on Ruffian using machine vector Ruffian from MILO Calibrating delay loop... 595.59 BogoMIPS hda: IBM-DJNA-370910, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: IBM-DJNA-370910, 8693MB w/1966kB Cache, CHS=17662/16/63, (U)DMA ... sym53c8xx: at PCI bus 32, device 13, function 0 sym53c8xx: 53c875 detected sym53c875-0: rev 0x3 on pci bus 32 device 13 function 0 irq 20 sym53c875-0: ID 7, Fast-20, Parity Checking scsi0 : sym53c8xx-1.7.0-2709 scsi : 1 host. Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 2, lun 0 Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 scsi : detected 1 SCSI cdrom 2 SCSI disks total. sym53c875-0-6,*: FAST-10 SCSI 10.0 MB/s (100 ns, offset 16) Partition check: sda: sda1 sda2 sda3 sda4 sda5 sda6 sdb: sdb1 sdb2 sdb3 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 hda: hda1 hda2 hda3 hda4 VFS: Mounted root (ext2 filesystem) readonly. In particular note differences in a detected SCSI controller and lack of problems on a partition check. I also do not know from where "DECchip 21052" is coming with 2.4 kernel. The real ethernet controller is DS21143 Tulip rev. 48. This is a PCI layout as reported by 'lspci -tv': -[00]-+-0d.0-[01]--+-0a.0 Trident Microsystems 4DWave DX |\-0d.0 Symbios Logic Inc. (formerly NCR) 53c875 +-0e.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +-0e.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] +-0f.0 Digital Equipment Corporation DECchip 21142/43 \-11.0 Texas Instruments TVP4020 [Permedia 2] Any ideas what gives here? Michal [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fix for non-booting Alpha with BRIDGE_OTHER device
I found by an experiment that an Alpha with a device which provides
its own PCI bridge, and if that device is on a PCI bus 0, will stop
booting right after "Partition check" messages. The only way out is
through a power switch. One can still boot if the device in question
is plugged in a slot on a PCI bus 1.
That particular hardware which revealed the problem is in fact SCI
board from Scali ( http://www.scali.com ) used in a cluster
communication and Scali provides a fix which makes machines bootable
again.
Here it is recreated against linux-2.2.18pre6. It will actually
apply to a wide range of kernels but with a possible line offsets
noise.
--- linux-2.2.18p/arch/alpha/kernel/bios32.c.orig Wed Jun 7 15:26:42 2000
+++ linux-2.2.18p/arch/alpha/kernel/bios32.cWed Sep 13 14:08:05 2000
@@ -828,6 +828,7 @@
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
disable_dev(dev);
}
@@ -840,6 +841,7 @@
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
layout_dev(dev);
}
@@ -1081,6 +1083,7 @@
*/
for (dev = pci_devices; dev; dev = dev->next) {
if ((dev->class >> 16 == PCI_BASE_CLASS_BRIDGE) &&
+ (dev->class >> 8 != PCI_CLASS_BRIDGE_OTHER) &&
(dev->class >> 8 != PCI_CLASS_BRIDGE_PCMCIA))
continue;
It indeed makes possible to boot regardles of a slot with SCI in it and
in tests on various Alphas _without_ that device does not seem to harm
anything - which is not a big surprise as otherwise PCMCIA would likely
be a problem too.:-) Any comments from those who sleep with PCI specs
under pillows? Should not that be included into standart kernels?
In arch/sparc64/kernel/psycho.c exists already a code which seems to
be somewhat related.
Michal
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Fix for non-booting Alpha with BRIDGE_OTHER device
I found by an experiment that an Alpha with a device which provides
its own PCI bridge, and if that device is on a PCI bus 0, will stop
booting right after "Partition check" messages. The only way out is
through a power switch. One can still boot if the device in question
is plugged in a slot on a PCI bus 1.
That particular hardware which revealed the problem is in fact SCI
board from Scali ( http://www.scali.com ) used in a cluster
communication and Scali provides a fix which makes machines bootable
again.
Here it is recreated against linux-2.2.18pre6. It will actually
apply to a wide range of kernels but with a possible line offsets
noise.
--- linux-2.2.18p/arch/alpha/kernel/bios32.c.orig Wed Jun 7 15:26:42 2000
+++ linux-2.2.18p/arch/alpha/kernel/bios32.cWed Sep 13 14:08:05 2000
@@ -828,6 +828,7 @@
for (dev = bus-devices; dev; dev = dev-sibling) {
if ((dev-class 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev-class 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev-class 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
disable_dev(dev);
}
@@ -840,6 +841,7 @@
for (dev = bus-devices; dev; dev = dev-sibling) {
if ((dev-class 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev-class 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev-class 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
layout_dev(dev);
}
@@ -1081,6 +1083,7 @@
*/
for (dev = pci_devices; dev; dev = dev-next) {
if ((dev-class 16 == PCI_BASE_CLASS_BRIDGE)
+ (dev-class 8 != PCI_CLASS_BRIDGE_OTHER)
(dev-class 8 != PCI_CLASS_BRIDGE_PCMCIA))
continue;
It indeed makes possible to boot regardles of a slot with SCI in it and
in tests on various Alphas _without_ that device does not seem to harm
anything - which is not a big surprise as otherwise PCMCIA would likely
be a problem too.:-) Any comments from those who sleep with PCI specs
under pillows? Should not that be included into standart kernels?
In arch/sparc64/kernel/psycho.c exists already a code which seems to
be somewhat related.
Michal
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Availability of kdb
Jamie Lokier wrote: > World Domination is my hobby too :-) Now, that is THE T-shirt! What should be added? A flock of penguins in an attack mode. :-) --mj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
