Here's a summary of the current state of the Linux PCI and PCI Hotplug
subsystems as of 2.6.16-rc5
If the information in here is incorrect, or anyone knows of any
outstanding issues not listed here, please let me know.
List of outstanding regressions from 2.6.15:
- none known.
List of outstanding regressions from older kernel versions:
- some cardbus users still have issues with the change to the
PCI resource allocation stuff.
http://bugzilla.kernel.org/show_bug.cgi?id=5736 shows this
issue, but seems to be stalled for now :(
Here is a list of the current outstanding bugs for the PCI subsystem as
tracked at bugzilla.kernel.org. If anyone can help out with any of
these, please add information to the bug reports.
* 5736 [[email protected]] - pci broken on PIIX/ICH laptop (CARDBUS_IO_SIZE
too small?).
Future stuff:
Wow, for a subsystem that no one cared about for a long time (PCI
Hotplug) all of a sudden we have so many patches floating around that
it is difficult to handle all of them. If you are interested in the
changes in this area that will be coming in 2.6.17, please see my
quilt tree at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
Summary of the changes found there are:
- shpchp driver reworks that fix issues and handle the module
being able to be unloaded properly
- acpiphp driver changes to try to be able to work properly for
laptop docking stations. There is still remaining work to do
in this area.
- We have unstable patches to handle multi-domain PCI busses for
i386 and x86 arches in this tree. Unfortunately they still
seem to break NUMA and other random boxes, so they will not be
heading for mainline any time soon. If anyone has one of
these boxes and wishes to work on this, please let me know.
- MSI cleanups and fixes to get things to work on ia64.
- Other minor PCI and PCI bug fixes.
I still have a few outstanding patches in my TODO queue that I have not
applied to my quilt tree. These patches do the following:
- boot parameter to disable MSI
- various PCI quirks added
- remove PCI_LEGACY_PROC functionality.
- more acpiphp driver fixes.
- kzalloc cleanup for drivers/pci
- cpqphp driver cleanups as found by the Coverty checker.
- other minor things.
I hope to get to these by the end of the week, depending on other 2.6.16
stabilization work. If you don't hear back from me by then, and you
have sent me a PCI or PCI Hotplug patch, please resend it and poke me
about it.
There are no new PCI driver API changes are pending that I am aware of.
Was this summary useful for people? Anything that I should add to it?
thanks,
greg k-h
On Mon, Mar 06, 2006 at 02:35:45PM -0800, Greg KH wrote:
> Here's a summary of the current state of the Linux PCI and PCI Hotplug
> subsystems as of 2.6.16-rc5
>
> If the information in here is incorrect, or anyone knows of any
> outstanding issues not listed here, please let me know.
Not an direct outstanding issue, but more a TODO.
The section mismatch check that is now part of a regular kernel build
(in -mm) detected a number of cases with inconsistency in __devinit
versus __init usage. Some are still outstanding and needs to be fixed.
The natural next step is to extend the check to cover __devinit,
__devinitdata so we to some extent knows things are consistent should
someone decide to build a kernel without hotplug enabled.
The task is simple enough:
Add a new section for __devinit, __devinitdata
Add consistency check in modpost.
I took a short look at it, but done right stuff from vmlinux.lds ought
to be consolidated in asm-generaic/vmlinux.lds.h, but my head started
spinning when I went through the different $(ARCH)/kernel/vmlinux.lds
files.
2.6.18 material - we are not in a hurry.
Fixes for the warnings always generated are 2.6.17 material if people
start fixing them soon (when the check hits mainline I assume this will
happen).
> Was this summary useful for people? Anything that I should add to it?
Useful - maybe. But indeed interesting reading (also the USB part).
Sam
On Mon, Mar 06, 2006 at 11:47:05PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 06, 2006 at 02:35:45PM -0800, Greg KH wrote:
> > Here's a summary of the current state of the Linux PCI and PCI Hotplug
> > subsystems as of 2.6.16-rc5
> >
> > If the information in here is incorrect, or anyone knows of any
> > outstanding issues not listed here, please let me know.
>
> Not an direct outstanding issue, but more a TODO.
> The section mismatch check that is now part of a regular kernel build
> (in -mm) detected a number of cases with inconsistency in __devinit
> versus __init usage. Some are still outstanding and needs to be fixed.
>
> The natural next step is to extend the check to cover __devinit,
> __devinitdata so we to some extent knows things are consistent should
> someone decide to build a kernel without hotplug enabled.
>
> The task is simple enough:
> Add a new section for __devinit, __devinitdata
> Add consistency check in modpost.
Yes, thanks for reminding me.
> I took a short look at it, but done right stuff from vmlinux.lds ought
> to be consolidated in asm-generaic/vmlinux.lds.h, but my head started
> spinning when I went through the different $(ARCH)/kernel/vmlinux.lds
> files.
It's not that bad, you really only have to touch
include/asm-generic/vmlinux.lds.h from which all the other .lds files
are generated. There are 2 others, arch/m68knommu/kernel/vmlinux.lds.S
and arch/v850/kernel/vmlinux.lds.S which seem to not use this file, and
that's it.
See my EXPORT_SYMBOL_GPL_FUTURE() patch for an example of all that
should need to be done to modify this file for this feature.
And yes, I agree that we should do it to fix the issues you have pointed
out.
thanks again,
greg k-h
On Mon, Mar 06, 2006 at 02:35:45PM -0800, Greg KH wrote:
> Here's a summary of the current state of the Linux PCI and PCI Hotplug
> subsystems as of 2.6.16-rc5
>
> If the information in here is incorrect, or anyone knows of any
> outstanding issues not listed here, please let me know.
>...
> Was this summary useful for people? Anything that I should add to it?
It is useful, but one thing seems to be missing:
Which patches do you intend to forward for 2.6.16 (if any)?
(pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
be a candidate.)
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Mar 08, 2006 at 11:26:52PM +0100, Adrian Bunk wrote:
> On Mon, Mar 06, 2006 at 02:35:45PM -0800, Greg KH wrote:
>
> > Here's a summary of the current state of the Linux PCI and PCI Hotplug
> > subsystems as of 2.6.16-rc5
> >
> > If the information in here is incorrect, or anyone knows of any
> > outstanding issues not listed here, please let me know.
> >...
> > Was this summary useful for people? Anything that I should add to it?
>
> It is useful, but one thing seems to be missing:
> Which patches do you intend to forward for 2.6.16 (if any)?
None, as I am expecting 2.6.16 to be out any day now.
> (pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
> be a candidate.)
Yes, if people really want it in I could send it, but I was just looking
for "bugfixes only" at this late stage of the game.
thanks,
thanks,
greg k-h
On Wed, Mar 08, 2006 at 02:50:29PM -0800, Greg KH wrote:
> On Wed, Mar 08, 2006 at 11:26:52PM +0100, Adrian Bunk wrote:
> > On Mon, Mar 06, 2006 at 02:35:45PM -0800, Greg KH wrote:
> >
> > > Here's a summary of the current state of the Linux PCI and PCI Hotplug
> > > subsystems as of 2.6.16-rc5
> > >
> > > If the information in here is incorrect, or anyone knows of any
> > > outstanding issues not listed here, please let me know.
> > >...
> > > Was this summary useful for people? Anything that I should add to it?
> >
> > It is useful, but one thing seems to be missing:
> > Which patches do you intend to forward for 2.6.16 (if any)?
>
> None, as I am expecting 2.6.16 to be out any day now.
Looking through the lists of regressions [1] and pending possible
patches I have for 2.6.16, I'd hope there are still two weeks left for
bringing 2.6.16 into shape.
> > (pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
> > be a candidate.)
>
> Yes, if people really want it in I could send it, but I was just looking
> for "bugfixes only" at this late stage of the game.
It is a fix for a hardware bug, and IMHO 2.6.16 material (but I don't a
very strong opinion on the latter).
> thanks,
>
> greg k-h
cu
Adrian
[1] currently -rc kernels are my trigger for sending regression lists,
IOW the next one will be sent directly after -rc6 is released
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 8 Mar 2006, Greg KH wrote:
>
> None, as I am expecting 2.6.16 to be out any day now.
Sadly, until the FC5 problems re at least somewhat more understood, I
don't think that's going to happen.
Trying to chase down Andrew's "laptop from hell" has also delayed even
doing a -rc6, although that is imminent.
Linus
On Thu, 2006-03-09 at 00:05 +0100, Adrian Bunk wrote:
> > > (pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
> > > be a candidate.)
> >
> > Yes, if people really want it in I could send it, but I was just looking
> > for "bugfixes only" at this late stage of the game.
>
> It is a fix for a hardware bug, and IMHO 2.6.16 material (but I don't a
> very strong opinion on the latter).
>
This is the patch that re-enabled the onboard sound card when a second
one is present?
That should not go in 2.6.16 - it's not a hardware bug but a (poor IMHO)
design decision by the vendor. And, it may break working setups when an
extra sound device shows up.
Lee
On Wed, Mar 08, 2006 at 03:03:47PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 8 Mar 2006, Greg KH wrote:
> >
> > None, as I am expecting 2.6.16 to be out any day now.
>
> Sadly, until the FC5 problems re at least somewhat more understood, I
> don't think that's going to happen.
Understood. Wait, what FC5 issues? Andrew's problems? Or something
else?
> Trying to chase down Andrew's "laptop from hell" has also delayed even
> doing a -rc6, although that is imminent.
Yeah, I'm thinking that just giving Andrew a different laptop might be
the simpler solution for this issue right now :)
thanks,
greg k-h
On Thu, Mar 09, 2006 at 12:05:19AM +0100, Adrian Bunk wrote:
> On Wed, Mar 08, 2006 at 02:50:29PM -0800, Greg KH wrote:
> > > (pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
> > > be a candidate.)
> >
> > Yes, if people really want it in I could send it, but I was just looking
> > for "bugfixes only" at this late stage of the game.
>
> It is a fix for a hardware bug, and IMHO 2.6.16 material (but I don't a
> very strong opinion on the latter).
Agreed that it is a hardware bug, but it's pretty low on the scale of
issues, as there is no oops, and no regression. But if people affected
by it really need it in now, I'm very willing to reconsider.
Just trying to be conservative with changes right now.
thanks,
greg k-h
On Wed, Mar 08, 2006 at 06:18:36PM -0500, Lee Revell wrote:
> On Thu, 2006-03-09 at 00:05 +0100, Adrian Bunk wrote:
> > > > (pci-pci-quirk-for-asus-a8v-and-a8v-deluxe-motherboards.patch seems to
> > > > be a candidate.)
> > >
> > > Yes, if people really want it in I could send it, but I was just looking
> > > for "bugfixes only" at this late stage of the game.
> >
> > It is a fix for a hardware bug, and IMHO 2.6.16 material (but I don't a
> > very strong opinion on the latter).
> >
>
> This is the patch that re-enabled the onboard sound card when a second
> one is present?
Yes.
> That should not go in 2.6.16 - it's not a hardware bug but a (poor IMHO)
> design decision by the vendor. And, it may break working setups when an
> extra sound device shows up.
Ah, good thing I held off :)
Any objections to it going in for 2.6.17?
thanks,
greg k-h
On Wed, 8 Mar 2006, Greg KH wrote:
>
> Understood. Wait, what FC5 issues? Andrew's problems? Or something
> else?
Something else.
Although it might be related, since DaveJ reports that there are some
weird bootup issues that come and go:
"Fedora rawhide kernel stopped booting for a bunch of people, all with
686-SMP boxes. I saw it myself too, it hung just after the 'write
protecting kernel rodata'.
It totally puzzled me for a day. The following day, I rebased to
rc4-git4, and the problem "went away". Nothing in the changesets
merged could explain the hangs I saw.
A few days ago, the exact same bug resurfaced, and like before, the
following day, it went into hiding again."
I don't know a whole lot more.
Linus
On Wed, 2006-03-08 at 15:23 -0800, Greg KH wrote:
>
> > That should not go in 2.6.16 - it's not a hardware bug but a (poor IMHO)
> > design decision by the vendor. And, it may break working setups when an
> > extra sound device shows up.
>
> Ah, good thing I held off :)
>
> Any objections to it going in for 2.6.17?
I can't think of a way to merge this and guarantee not to break
userspace unless it could be disabled by default.
Lee
Linus Torvalds <[email protected]> wrote:
>
>
>
> On Wed, 8 Mar 2006, Greg KH wrote:
> >
> > None, as I am expecting 2.6.16 to be out any day now.
>
> Sadly, until the FC5 problems re at least somewhat more understood, I
> don't think that's going to happen.
>
> Trying to chase down Andrew's "laptop from hell" has also delayed even
> doing a -rc6, although that is imminent.
>
Well.. That's a problem which only I can reproduce, and that only after
applying sched patches while performing strange acts upon small animals.
Plus I don't think we're close to fixing it.
More serious matters would be:
- The x86_64-goes-oom-due-to-bio-using-GFP_DMA bug. I'll send the patch
over today.
- The some-ati-timers-go-too-fast bug. I'll sndn that patch today as
well.
- Neil is sitting on a radi1 BIO leak fix which we need.
- It would be nice to get Martin MOKREJ
<[email protected]>'s full 16GB recognised again. Dave
Hansen is working on that.
- http://bugzilla.kernel.org/show_bug.cgi?id=6180 seems to be a recent
XFS regression.
- Matthew Grant <[email protected]>'s "rt_sigsuspend() does not
return EINTR on 2.6.16-rc2+" might be a new poll() bug, but that one's
hard and I suspect we'll need the extra testers which 2.6.16 will give to
be able to work out whether it's real and what the fix is.
- http://bugzilla.kernel.org/show_bug.cgi?id=6177 _looks_ like a serious
TCP regression, but that happened between 2.6.14 and 2.6.15 and that's
the only report I've seen.
Plus lots of other stuff, probably.
On Wed, Mar 08, 2006 at 06:34:54PM -0500, Lee Revell wrote:
> On Wed, 2006-03-08 at 15:23 -0800, Greg KH wrote:
> >
> > > That should not go in 2.6.16 - it's not a hardware bug but a (poor IMHO)
> > > design decision by the vendor. And, it may break working setups when an
> > > extra sound device shows up.
> >
> > Ah, good thing I held off :)
> >
> > Any objections to it going in for 2.6.17?
>
> I can't think of a way to merge this and guarantee not to break
> userspace unless it could be disabled by default.
Ok, how about you and Bauke (CCed, and the author of the patch) work
together on the problem and let me know what you decide on.
thanks,
greg k-h
On Wed, 2006-03-08 at 15:29 -0800, Andrew Morton wrote:
> - It would be nice to get Martin MOKREJ
> <[email protected]>'s full 16GB recognised again. Dave
> Hansen is working on that.
Martin, please step in here if your problem has come back...
After Martin applied my debugging patch, the problem went away. Last I
heard, he was going to boot back into a kernel without my patch to see
if it stayed fixed.
My guess is that it is be a screwy BIOS that is causing the problem
intermittently. Otherwise, I can't imagine how some printks could
affect the problem. It's not like this is happening in code where there
are SMP races.
I also checked around the office a bit to see if anyone else was having
memory detection issues on large memory x86 machines. No luck. I'd put
this into the "unreproducible" bucket for now.
-- Dave
Dave Hansen <[email protected]> wrote:
>
> On Wed, 2006-03-08 at 15:29 -0800, Andrew Morton wrote:
> > - It would be nice to get Martin MOKREJ
> > <[email protected]>'s full 16GB recognised again. Dave
> > Hansen is working on that.
>
> Martin, please step in here if your problem has come back...
>
> After Martin applied my debugging patch, the problem went away. Last I
> heard, he was going to boot back into a kernel without my patch to see
> if it stayed fixed.
>
> My guess is that it is be a screwy BIOS that is causing the problem
> intermittently. Otherwise, I can't imagine how some printks could
> affect the problem. It's not like this is happening in code where there
> are SMP races.
>
> I also checked around the office a bit to see if anyone else was having
> memory detection issues on large memory x86 machines. No luck.
OK, thanks Dave.
> I'd put this into the "unreproducible" bucket for now.
IBM must make big buckets.
On Wed, 2006-03-08 at 15:40 -0800, Greg KH wrote:
> On Wed, Mar 08, 2006 at 06:34:54PM -0500, Lee Revell wrote:
> > On Wed, 2006-03-08 at 15:23 -0800, Greg KH wrote:
> > >
> > > > That should not go in 2.6.16 - it's not a hardware bug but a (poor IMHO)
> > > > design decision by the vendor. And, it may break working setups when an
> > > > extra sound device shows up.
> > >
> > > Ah, good thing I held off :)
> > >
> > > Any objections to it going in for 2.6.17?
> >
> > I can't think of a way to merge this and guarantee not to break
> > userspace unless it could be disabled by default.
>
> Ok, how about you and Bauke (CCed, and the author of the patch) work
> together on the problem and let me know what you decide on.
The best option might be to just take a chance on breaking things - if
userspace is so fragile that an extra sound device appearing breaks
things, it could also be broken merely by adding a new driver to the
kernel. If we have to worry about this kind of breakage the "no
incompatible changes" policy becomes "no new features".
That's my $0.02, it's between the patch author and the maintainer what
you want to do.
Lee
Greg KH wrote:
> Here's a summary of the current state of the Linux PCI and PCI Hotplug
> subsystems as of 2.6.16-rc5
>
> If the information in here is incorrect, or anyone knows of any
> outstanding issues not listed here, please let me know.
>
> List of outstanding regressions from 2.6.15:
> - none known.
>
> List of outstanding regressions from older kernel versions:
> - some cardbus users still have issues with the change to the
> PCI resource allocation stuff.
> http://bugzilla.kernel.org/show_bug.cgi?id=5736 shows this
> issue, but seems to be stalled for now :(
>
> Here is a list of the current outstanding bugs for the PCI subsystem as
> tracked at bugzilla.kernel.org. If anyone can help out with any of
> these, please add information to the bug reports.
>
> * 5736 [[email protected]] - pci broken on PIIX/ICH laptop (CARDBUS_IO_SIZE
> too small?).
>
>
> Future stuff:
> Wow, for a subsystem that no one cared about for a long time (PCI
> Hotplug) all of a sudden we have so many patches floating around that
> it is difficult to handle all of them. If you are interested in the
> changes in this area that will be coming in 2.6.17, please see my
> quilt tree at
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
>
> Summary of the changes found there are:
> - shpchp driver reworks that fix issues and handle the module
> being able to be unloaded properly
> - acpiphp driver changes to try to be able to work properly for
> laptop docking stations. There is still remaining work to do
> in this area.
> - We have unstable patches to handle multi-domain PCI busses for
> i386 and x86 arches in this tree. Unfortunately they still
> seem to break NUMA and other random boxes, so they will not be
> heading for mainline any time soon. If anyone has one of
> these boxes and wishes to work on this, please let me know.
> - MSI cleanups and fixes to get things to work on ia64.
> - Other minor PCI and PCI bug fixes.
>
>
> I still have a few outstanding patches in my TODO queue that I have not
> applied to my quilt tree. These patches do the following:
> - boot parameter to disable MSI
> - various PCI quirks added
> - remove PCI_LEGACY_PROC functionality.
> - more acpiphp driver fixes.
> - kzalloc cleanup for drivers/pci
> - cpqphp driver cleanups as found by the Coverty checker.
> - other minor things.
>
> I hope to get to these by the end of the week, depending on other 2.6.16
> stabilization work. If you don't hear back from me by then, and you
> have sent me a PCI or PCI Hotplug patch, please resend it and poke me
> about it.
>
> There are no new PCI driver API changes are pending that I am aware of.
>
> Was this summary useful for people? Anything that I should add to it?
>
Could you please add "PCI legacy I/O port free driver"
(http://www.ussg.iu.edu/hypermail/linux/kernel/0603.0/1923.html)
to Future stuff? I hope the set of patches would be tested on -mm tree
for a while.
Thanks,
Kenji Kaneshige
On Mon, 2006-03-06 at 14:35 -0800, Greg KH wrote:
> List of outstanding regressions from older kernel versions:
> - some cardbus users still have issues with the change to the
> PCI resource allocation stuff.
> http://bugzilla.kernel.org/show_bug.cgi?id=5736 shows this
> issue, but seems to be stalled for now :(
Hmm, this sounds like some recent reports on the ALSA lists, I'll ask
those users to look at this.
Lee
On Thu, Mar 09, 2006 at 01:01:00PM +0900, Kenji Kaneshige wrote:
> Could you please add "PCI legacy I/O port free driver"
> (http://www.ussg.iu.edu/hypermail/linux/kernel/0603.0/1923.html)
> to Future stuff? I hope the set of patches would be tested on -mm tree
> for a while.
I will, they are in my TODO queue, don't worry, I haven't forgotten them
:)
thanks,
greg k-h
Hi all,
Andrew Morton wrote:
> Linus Torvalds <[email protected]> wrote:
>
>>
>>
>>On Wed, 8 Mar 2006, Greg KH wrote:
>>
>>>None, as I am expecting 2.6.16 to be out any day now.
>>
>>Sadly, until the FC5 problems re at least somewhat more understood, I
>>don't think that's going to happen.
>>
>>Trying to chase down Andrew's "laptop from hell" has also delayed even
>>doing a -rc6, although that is imminent.
>
> - It would be nice to get Martin MOKREJ
> <[email protected]>'s full 16GB recognised again. Dave
> Hansen is working on that.
I tried a cold boot yesterday after got physical access to the
machine. I couldn't reproduce the problem nor with plain 2.6.16-rc5
nor the same patched with printk patch from Dave Hansen. I touched
all the DIMMs and have to admit all of them are rather loosely
fitted into the mainboard. I will probably flash the BIOS. I will
retry few more reboots and if I manage to reproduce it I'll post
back. Otherwise, consider it either mechanical problem with the size
of those Kingston 2GB DDR DIMMs or MSI9136 mainboard layout or BIOS
bug. Description of the interresting board capable of even 32GB RAM
is at
http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2M&class=spd
Martin
On Wed, Mar 08, 2006 at 03:30:22PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 8 Mar 2006, Greg KH wrote:
> >
> > Understood. Wait, what FC5 issues? Andrew's problems? Or something
> > else?
>
> Something else.
>
> Although it might be related, since DaveJ reports that there are some
> weird bootup issues that come and go:
>
> "Fedora rawhide kernel stopped booting for a bunch of people, all with
> 686-SMP boxes. I saw it myself too, it hung just after the 'write
> protecting kernel rodata'.
>
Ubuntu has similar problem:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
I believe Ubuntu's 2.6.15 source is vanilla+git patches.
--
Tomasz Torcz "Funeral in the morning, IDE hacking
[email protected] in the afternoon and evening." - Alan Cox
On Thu, 9 Mar 2006, Tomasz Torcz wrote:
> >
> > "Fedora rawhide kernel stopped booting for a bunch of people, all with
> > 686-SMP boxes. I saw it myself too, it hung just after the 'write
> > protecting kernel rodata'.
> >
>
> Ubuntu has similar problem:
> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
> I believe Ubuntu's 2.6.15 source is vanilla+git patches.
Interesting. He also apparently boots with "noapic nolapic" on the "386"
kernel, but not the "686" kernel. I wonder what the differences in Kubuntu
kernels are between 386/686 kernels. Is it _just_ the CPU type? If so, the
largest difference is probably just compiler instruction usage/scheduling.
Ben?
Also, the 686 one apparently boots with "acpi=off" or "pci=noacpi"
(although then some interrupts don't work, which I guess shouldn't be a
huge surprise). I do wonder if maybe we have a miscompile issue.
There are a few (but really not very many) other differences between M386
and M686 kernels too. Notably CMPXCHG/XADD isn't used unconditionally on
the M386 kernel. That impacts the new mutex code (it adds a few
conditional jumps, but still ends up using XADD since the CPU actually
supports it).
Linus
On Thu, 2006-03-09 at 11:49 -0800, Linus Torvalds wrote:
>
> On Thu, 9 Mar 2006, Tomasz Torcz wrote:
> > >
> > > "Fedora rawhide kernel stopped booting for a bunch of people, all with
> > > 686-SMP boxes. I saw it myself too, it hung just after the 'write
> > > protecting kernel rodata'.
> > >
> >
> > Ubuntu has similar problem:
> > https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
> > I believe Ubuntu's 2.6.15 source is vanilla+git patches.
>
> Interesting. He also apparently boots with "noapic nolapic" on the "386"
> kernel, but not the "686" kernel. I wonder what the differences in Kubuntu
> kernels are between 386/686 kernels. Is it _just_ the CPU type? If so, the
> largest difference is probably just compiler instruction usage/scheduling.
>
> Ben?
The difference between our 2.6.15 386 and 686 kernels is actually pretty
huge. The 386 is M486, and UP, while our 686 kernel is M686, and SMP.
The SMP is also complicated by our use of the SMP-alternatives patch,
but I believe I had this user test with this disabled (kernel command
line option that leaves all the SMP code intact for testing). It didn't
alter the problem.
So the problem would seem to be narrowed down to between M486 and M686.
Also, we are using gcc 4.0.3, for reference. No special compile options
are added, it's all kbuild generated stuff.
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
On Thu, 9 Mar 2006, Ben Collins wrote:
>
> The difference between our 2.6.15 386 and 686 kernels is actually pretty
> huge. The 386 is M486, and UP, while our 686 kernel is M686, and SMP.
Ok, that's actually better than a _real_ M386. At least M486 has most of
the new instructions statically. But the SMP thing obviously makes a big
difference.
Can you get your tester to try "ctrl + scroll-lock" to see if it outputs
anything?
> So the problem would seem to be narrowed down to between M486 and M686.
Well, SMP ends up being a big issue, and adds tons of things. It would be
very interesting to hear whether a M686 _UP_ kernel shows the same
problem.
Linus
On Thu, 2006-03-09 at 11:49 -0800, Linus Torvalds wrote:
>
> On Thu, 9 Mar 2006, Tomasz Torcz wrote:
> > >
> > > "Fedora rawhide kernel stopped booting for a bunch of people, all with
> > > 686-SMP boxes. I saw it myself too, it hung just after the 'write
> > > protecting kernel rodata'.
> > >
> >
> > Ubuntu has similar problem:
> > https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
> > I believe Ubuntu's 2.6.15 source is vanilla+git patches.
>
> Interesting. He also apparently boots with "noapic nolapic" on the "386"
> kernel, but not the "686" kernel.
hmm curious; I wonder if the "weird" (as in, Arjan considers it a stupid
idea and broken) "enable APIC on UP but not really" patch is at fault
here, which isn't in mainline....
On Thu, Mar 09, 2006 at 09:37:50PM +0100, Arjan van de Ven wrote:
> On Thu, 2006-03-09 at 11:49 -0800, Linus Torvalds wrote:
> >
> > On Thu, 9 Mar 2006, Tomasz Torcz wrote:
> > > >
> > > > "Fedora rawhide kernel stopped booting for a bunch of people, all with
> > > > 686-SMP boxes. I saw it myself too, it hung just after the 'write
> > > > protecting kernel rodata'.
> > > >
> > >
> > > Ubuntu has similar problem:
> > > https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
> > > I believe Ubuntu's 2.6.15 source is vanilla+git patches.
> >
> > Interesting. He also apparently boots with "noapic nolapic" on the "386"
> > kernel, but not the "686" kernel.
>
> hmm curious; I wonder if the "weird" (as in, Arjan considers it a stupid
> idea and broken) "enable APIC on UP but not really" patch is at fault
> here, which isn't in mainline....
Not present in the Fedora kernels any more, and this bug has been seen in
ones without it.
Dave
--
http://www.codemonkey.org.uk
On Thu, 2006-03-09 at 15:10 -0500, Ben Collins wrote:
> The difference between our 2.6.15 386 and 686 kernels is actually pretty
> huge. The 386 is M486, and UP, while our 686 kernel is M686, and SMP.
> The SMP is also complicated by our use of the SMP-alternatives patch,
> but I believe I had this user test with this disabled (kernel command
> line option that leaves all the SMP code intact for testing). It didn't
> alter the problem.
Ubuntu doesn't provide a UP 686 kernel?
Isn't there a performance hit running an SMP kernel on UP?
Lee
On Thu, 2006-03-09 at 15:52 -0500, Lee Revell wrote:
> On Thu, 2006-03-09 at 15:10 -0500, Ben Collins wrote:
> > The difference between our 2.6.15 386 and 686 kernels is actually pretty
> > huge. The 386 is M486, and UP, while our 686 kernel is M686, and SMP.
> > The SMP is also complicated by our use of the SMP-alternatives patch,
> > but I believe I had this user test with this disabled (kernel command
> > line option that leaves all the SMP code intact for testing). It didn't
> > alter the problem.
>
> Ubuntu doesn't provide a UP 686 kernel?
>
> Isn't there a performance hit running an SMP kernel on UP?
This is a little off-topic to the original thread, so trimming CC and
changing subject.
As mentioned above, we have the SMP-alternatives patch, which will
basically convert SMP related code (lock op's and some atomic
operations) to UP, on-the-fly (at boot for the kernel, and at load for
modules). It's not 100% the same as running a UP kernel, but it comes
close enough that it allows us to distribute fewer kernels. This equates
to less load on us and our users.
I don't want to start this whole thread over again, so check back in the
linux-kernel archives for the SMP alternatives patch thread.
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
From: Lee Revell <[email protected]>
Date: Thu, 09 Mar 2006 15:52:35 -0500
> Ubuntu doesn't provide a UP 686 kernel?
>
> Isn't there a performance hit running an SMP kernel on UP?
There is some cost, but it is mitigated by a patch they include
which nops out all the spinlocks when a UP system is detected.
On Thu, 2006-03-09 at 15:46 -0500, Dave Jones wrote:
> On Thu, Mar 09, 2006 at 09:37:50PM +0100, Arjan van de Ven wrote:
> > On Thu, 2006-03-09 at 11:49 -0800, Linus Torvalds wrote:
> > >
> > > On Thu, 9 Mar 2006, Tomasz Torcz wrote:
> > > > >
> > > > > "Fedora rawhide kernel stopped booting for a bunch of people, all with
> > > > > 686-SMP boxes. I saw it myself too, it hung just after the 'write
> > > > > protecting kernel rodata'.
> > > > >
> > > >
> > > > Ubuntu has similar problem:
> > > > https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/29601
> > > > I believe Ubuntu's 2.6.15 source is vanilla+git patches.
> > >
> > > Interesting. He also apparently boots with "noapic nolapic" on the "386"
> > > kernel, but not the "686" kernel.
> >
> > hmm curious; I wonder if the "weird" (as in, Arjan considers it a stupid
> > idea and broken) "enable APIC on UP but not really" patch is at fault
> > here, which isn't in mainline....
>
> Not present in the Fedora kernels any more, and this bug has been seen in
> ones without it.
ok then that's ruled out... (I assume apics are entirely off now for at
least one build that has seen this behavior)
On Thu, 2006-03-09 at 16:06 -0500, Ben Collins wrote:
>
> This is a little off-topic to the original thread, so trimming CC and
> changing subject.
Sorry that should have been off list
On Thu, 2006-03-09 at 12:24 -0800, Linus Torvalds wrote:
>
> On Thu, 9 Mar 2006, Ben Collins wrote:
> >
> > The difference between our 2.6.15 386 and 686 kernels is actually pretty
> > huge. The 386 is M486, and UP, while our 686 kernel is M686, and SMP.
>
> Ok, that's actually better than a _real_ M386. At least M486 has most of
> the new instructions statically. But the SMP thing obviously makes a big
> difference.
>
> Can you get your tester to try "ctrl + scroll-lock" to see if it outputs
> anything?
Here's some screen shots of the ctrl+scroll-lock the user was able to
get:
http://librarian.launchpad.net/1687295/ctl-scroll.tar.gz
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/