Ok - I had a bad day today struggling with hardware. Having said that
I'm somewhat frustrated with the lack of progress of Linux getting it
right with Asus, nVidia, and AMD processors right.
I still have to run pci=nommconf to keep the server from locking up.
That's with both 939 pin and AM2 motherboards.
This bug remains unresolved:
http://bugzilla.kernel.org/show_bug.cgi?id=6975
So what's up with the no progress?
On 2006-10-25, Marc Perkel wrote:
> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
> Xref: news.gmane.org gmane.linux.kernel:460364
> Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/460364>
>
> Ok - I had a bad day today struggling with hardware. Having said that
> I'm somewhat frustrated with the lack of progress of Linux getting it
> right with Asus, nVidia, and AMD processors right.
>
> I still have to run pci=nommconf to keep the server from locking up.
> That's with both 939 pin and AM2 motherboards.
Please, read down this thread:
<http://article.gmane.org/gmane.linux.ports.x86-64.general/1794>
And this one may be relevant:
<http://permalink.gmane.org/gmane.linux.kernel/458769>
Maybe will give some clue about soft-"hardware".
> This bug remains unresolved:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6975
>
> So what's up with the no progress?
If you are only one using that hardware and experiencing
bugs, then you are on your own.
OTOH, many would help if more hardware information and erratas will be
*actually published*.
____
On Tue, 2006-10-24 at 21:55 -0700, Marc Perkel wrote:
> Ok - I had a bad day today struggling with hardware. Having said that
> I'm somewhat frustrated with the lack of progress of Linux getting it
> right with Asus, nVidia, and AMD processors right.
>
I don't know why you would buy a server from a vendor whose hardware is
so closed they expect you to use a proprietary driver to have working
sound, network, and video...
Lee
Marc,
2.6.16.11 works. I tell u because i got an M2E with 1GB ram on Athlon
AM2 under test since a couple of week and it goes fine.
BUT notice: i boot from SATA, dont have any PATA disk.
Maybe u can use that waiting for the patch
Bye,
Gianluca
Marc Perkel wrote:
> Ok - I had a bad day today struggling with hardware. Having said that
> I'm somewhat frustrated with the lack of progress of Linux getting it
> right with Asus, nVidia, and AMD processors right.
>
> I still have to run pci=nommconf to keep the server from locking up.
> That's with both 939 pin and AM2 motherboards.
>
> This bug remains unresolved:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6975
>
> So what's up with the no progress?
>
>
>
> -
> 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/
Marc Perkel <[email protected]> writes:
> Ok - I had a bad day today struggling with hardware. Having said that
> I'm somewhat frustrated with the lack of progress of Linux getting it
> right with Asus, nVidia, and AMD processors right.
>
> I still have to run pci=nommconf to keep the server from locking
> up. That's with both 939 pin and AM2 motherboards.
>
> This bug remains unresolved:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6975
>
> So what's up with the no progress?
The bug report only references ancient kernels (2.6.15, 2.6.17) How do you know there is no
progress?
-Andi
Andi Kleen wrote:
> Marc Perkel <[email protected]> writes:
>
>
>> Ok - I had a bad day today struggling with hardware. Having said that
>> I'm somewhat frustrated with the lack of progress of Linux getting it
>> right with Asus, nVidia, and AMD processors right.
>>
>> I still have to run pci=nommconf to keep the server from locking
>> up. That's with both 939 pin and AM2 motherboards.
>>
>> This bug remains unresolved:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=6975
>>
>> So what's up with the no progress?
>>
>
> The bug report only references ancient kernels (2.6.15, 2.6.17) How do you know there is no
> progress?
>
> -Andi
>
As of the 2.6.18 released kernel I still had to modify the source code
to keep the kernel from locking up on boot. I haven't tried it with
2.6.19rcx yet.
On Wed, 25 Oct 2006 12:09:21 -0700 Marc Perkel wrote:
>
>
> Andi Kleen wrote:
> > Marc Perkel <[email protected]> writes:
> >
> >
> >> Ok - I had a bad day today struggling with hardware. Having said that
> >> I'm somewhat frustrated with the lack of progress of Linux getting it
> >> right with Asus, nVidia, and AMD processors right.
> >>
> >> I still have to run pci=nommconf to keep the server from locking
> >> up. That's with both 939 pin and AM2 motherboards.
> >>
> >> This bug remains unresolved:
> >>
> >> http://bugzilla.kernel.org/show_bug.cgi?id=6975
> >>
> >> So what's up with the no progress?
> >>
> >
> > The bug report only references ancient kernels (2.6.15, 2.6.17) How do you know there is no
> > progress?
> >
> > -Andi
> >
> As of the 2.6.18 released kernel I still had to modify the source code
> to keep the kernel from locking up on boot. I haven't tried it with
> 2.6.19rcx yet.
Have you posted your needed patches?
If so, please do it again.
---
~Randy
> As of the 2.6.18 released kernel I still had to modify the source code
> to keep the kernel from locking up on boot. I haven't tried it with
> 2.6.19rcx yet.
Modify in what way?
-Andi
Andi Kleen wrote:
>> As of the 2.6.18 released kernel I still had to modify the source code
>> to keep the kernel from locking up on boot. I haven't tried it with
>> 2.6.19rcx yet.
>>
>
> Modify in what way?
>
> -Andi
>
>
skip_timer_override = 0
On Thursday 26 October 2006 11:31, Marc Perkel wrote:
> Andi Kleen wrote:
> >> As of the 2.6.18 released kernel I still had to modify the source code
> >> to keep the kernel from locking up on boot. I haven't tried it with
> >> 2.6.19rcx yet.
> >
> > Modify in what way?
> >
> > -Andi
>
> skip_timer_override = 0
Ah that problem. I'm still waiting for Nvidia to give us the required
information to fix this properly.
-Andi
Andi Kleen wrote:
> Marc Perkel <[email protected]> writes:
>
>> Ok - I had a bad day today struggling with hardware. Having said that
>> I'm somewhat frustrated with the lack of progress of Linux getting it
>> right with Asus, nVidia, and AMD processors right.
>>
>> I still have to run pci=nommconf to keep the server from locking
>> up. That's with both 939 pin and AM2 motherboards.
>>
>> This bug remains unresolved:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=6975
>>
>> So what's up with the no progress?
>
> The bug report only references ancient kernels (2.6.15, 2.6.17) How do you know there is no
> progress?
2.6.18 is the latest released kernel, I don't think calling one release
back "ancient" is really advancing the solution. The problem seems to
have been reported in August, and is still not fixed, I do understand
that he would feel there is no progress.
How long will you wait before putting in the fix Marc Perkel suggested,
perhaps with a warning logged that it's a band-aid? Many users will not
be astute enough to find this discussion, the bug report, the fix,
configure and build a kernel, etc. And not all distributions will
address it either.
--
Bill Davidsen <[email protected]>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
Bill Davidsen wrote:
> 2.6.18 is the latest released kernel, I don't think calling one release
> back "ancient" is really advancing the solution. The problem seems to
> have been reported in August, and is still not fixed, I do understand
> that he would feel there is no progress.
>
> How long will you wait before putting in the fix Marc Perkel suggested,
> perhaps with a warning logged that it's a band-aid? Many users will not
> be astute enough to find this discussion, the bug report, the fix,
> configure and build a kernel, etc. And not all distributions will
> address it either.
As far as the "fix" of disabling the skip-ACPI-timer-override, that is
not something that can be put in the kernel as it will break other
boards that require the ACPI timer override not to be used (like many
nForce2 boards for example). Breaking working setups in order to fix
others isn't acceptable.
There are clearly some NVIDIA chipsets which require the override be
skipped, and some which require it not be. I think the ball is currently
in NVIDIA's court to provide a way of figuring out which chipsets
require the quirk and which don't..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Bill Davidsen wrote:
>> 2.6.18 is the latest released kernel, I don't think calling one
>> release back "ancient" is really advancing the solution. The problem
>> seems to have been reported in August, and is still not fixed, I do
>> understand that he would feel there is no progress.
>>
>> How long will you wait before putting in the fix Marc Perkel
>> suggested, perhaps with a warning logged that it's a band-aid? Many
>> users will not be astute enough to find this discussion, the bug
>> report, the fix, configure and build a kernel, etc. And not all
>> distributions will address it either.
>
> As far as the "fix" of disabling the skip-ACPI-timer-override, that is
> not something that can be put in the kernel as it will break other
> boards that require the ACPI timer override not to be used (like many
> nForce2 boards for example). Breaking working setups in order to fix
> others isn't acceptable.
>
> There are clearly some NVIDIA chipsets which require the override be
> skipped, and some which require it not be. I think the ball is currently
> in NVIDIA's court to provide a way of figuring out which chipsets
> require the quirk and which don't..
>
The kernel seems to handle lots of other quirks, I agree that this
should not be the default behavior, but it certainly seems possible to
catch this on the more common cases for which it is needed.
The boards which need it probably should be the exception, 2.6 kernels
did without it for several years, and breaking hardware which worked up
through 2.6.15 is probably not the best way to cope with new boards. I
don't think ignoring the problem while waiting for nVidia is good
policy, since it's a regression.
--
Bill Davidsen <[email protected]>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
> There are clearly some NVIDIA chipsets which require the override be
> skipped, and some which require it not be. I think the ball is currently
> in NVIDIA's court to provide a way of figuring out which chipsets
> require the quirk and which don't..
My current plan is to switch in 2.6.20 to automatic probing of more pins
for the timer routing (suggested by Tim Hockin, I've got a test patch).
But that's too risky for .19.
For 2.6.19 we'll likely add some more PCI-IDs disabling the quirk
and a command line option to disable the skip timer override quirk.
Doing this per PCI ID isn't that bad because afaik Vista certification
requires enabling the HPET table and I assume most boards will get
Vista certification soon. This will force Asus to fix their BIOS.
Can people who use a Nvidia based AM2/SocketF board (especially when they have timer
troubles but otherwise would be useful too) please report their lspcis in private
mail to me?
-Andi
Andi Kleen wrote:
>>There are clearly some NVIDIA chipsets which require the override be
>>skipped, and some which require it not be. I think the ball is currently
>>in NVIDIA's court to provide a way of figuring out which chipsets
>>require the quirk and which don't..
>>
>>
>
>My current plan is to switch in 2.6.20 to automatic probing of more pins
>for the timer routing (suggested by Tim Hockin, I've got a test patch).
>
>
Thank you, Tim!
>But that's too risky for .19.
>
>For 2.6.19 we'll likely add some more PCI-IDs disabling the quirk
>and a command line option to disable the skip timer override quirk.
>
>
That should be safe, and timer override as an option should give
everyone a way to get what they need on any given system.
>Doing this per PCI ID isn't that bad because afaik Vista certification
>requires enabling the HPET table and I assume most boards will get
>Vista certification soon. This will force Asus to fix their BIOS.
>
>
And nVidia to release more information? Hopefully.
>Can people who use a Nvidia based AM2/SocketF board (especially when they have timer
>troubles but otherwise would be useful too) please report their lspcis in private
>mail to me?
>
>-Andi
>
>
>
>
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Hi,
> Can people who use a Nvidia based AM2/SocketF board (especially when they
> have timer troubles but otherwise would be useful too) please report their
> lspcis in private mail to me?
I'll send the lspci in private as requested in a minute.
I have a ASUS M2N-SLI Deluxe (nForce 570) with a Athlon64 X2 4600+ (AM2) and
Bios version 0307 or 0402 beta. The problem with this board seems to be a
little different than the problem the others posting here are experiencing.
Maybe it's a different bug but it seems to be timer-related too.
Booting 2.6.18.1 (or some other 2.6er I tried) stops with
[...]
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apci2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
....trying to set up timer (IRQ0) through the 8259A ... failed.
....trying to set up timer as Virtual Wire IRQ... failed.
....trying to set up timer as ExtINT IRQ... failed :(.
Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug
and send a report. Then try booting with the 'noapic' option
All kernels were SMP and i386 (not x86_64).
I tried to use the acpi_skip_timer_override=0 patch that helped the other
posters but it did not help - same error. Of course I patched the
corresponding code for i386 in arch/i386/kernel/acpi/earlyquirk.c. Booting
with the no_timer_check boot parameter as some people suggested does not help
too.
Booting with apic=debug does not reveal any additional info. Only booting with
noapic makes the machine boot.
Kind regards,
Gerd