I just checked my laptop which is a core2duo with 1 gig of ram. WinXP reports PAE but fc6 installed non-PAE kernel. Would the PAE kernel be better for me or should I stick with the non-PAE? Obviously I don't need highmem support, will that be to much of a performance hit?
model name : Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
-Louis
I am using x86_64 on a opteron box and a core 2 duo laptop, but I see nothing about NX in dmesg (but cpuinfo reports it).
Hi.
On Wed, 03 Jan 2007 03:14:48 -0500, Louis E Garcia II wrote
reports PAE but fc6 installed non-PAE kernel. Would the PAE kernel be better for me or should I stick with the non-PAE? Obviously I don't need highmem support, will that be to much of a performance hit?
The long and short of it seems to be that there simply is no PAE kernel in fedora (apart from the Xen-Kernels, which will not run without PAE).
Once upon a time, Ralf Ertzinger fedora@camperquake.de said:
The long and short of it seems to be that there simply is no PAE kernel in fedora (apart from the Xen-Kernels, which will not run without PAE).
That is not correct: both FC6-release and FC6-updates have kernel-PAE.i686.
* [03.Oca.07 03:14 -0500] Louis E Garcia II:
I just checked my laptop which is a core2duo with 1 gig of ram. WinXP reports PAE but fc6 installed non-PAE kernel. Would the PAE kernel be better for me or should I stick with the non-PAE? Obviously I don't need highmem support, will that be to much of a performance hit?
I’m sticking with non-PAE on my Core Duo (T2300) laptop, because the PAE kernel doesn’t have software suspend enabled.
Hi.
On Wed, 3 Jan 2007 19:36:44 +0200, Sertaç Ö. Yıldız wrote
I’m sticking with non-PAE on my Core Duo (T2300) laptop, because the PAE kernel doesn’t have software suspend enabled.
kernel-PAE-2.6.19-1.2904 does, my notebook suspends and wakes up just fine.
And NX is enabled. yay.
* [03.Oca.07 19:07 +0100] Ralf Ertzinger:
On Wed, 3 Jan 2007 19:36:44 +0200, Sertaç Ö. Yıldız wrote
I’m sticking with non-PAE on my Core Duo (T2300) laptop, because the PAE kernel doesn’t have software suspend enabled.
kernel-PAE-2.6.19-1.2904 does, my notebook suspends and wakes up just fine.
It’s not enabled for FC6 kernels which are still 2.6.18 based: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215396
On Wed, Jan 03, 2007 at 09:16:57PM +0200, Sertaç Ö. Yıldız wrote:
- [03.Oca.07 19:07 +0100] Ralf Ertzinger:
On Wed, 3 Jan 2007 19:36:44 +0200, Sertaç Ö. Yıldız wrote
I’m sticking with non-PAE on my Core Duo (T2300) laptop, because the PAE kernel doesn’t have software suspend enabled.
kernel-PAE-2.6.19-1.2904 does, my notebook suspends and wakes up just fine.
It’s not enabled for FC6 kernels which are still 2.6.18 based: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215396
There's a 2.6.19 based update in the works, should be out next week.
Dave
On Wed, 3 Jan 2007, Dave Jones wrote:
On Wed, Jan 03, 2007 at 09:16:57PM +0200, Sertaç Ö. Yÿÿldÿÿz wrote:
- [03.Oca.07 19:07 +0100] Ralf Ertzinger:
On Wed, 3 Jan 2007 19:36:44 +0200, Sertaç Ö. Yÿÿldÿÿz wrote
Iÿÿm sticking with non-PAE on my Core Duo (T2300) laptop, because the PAE kernel doesnÿÿt have software suspend enabled.
kernel-PAE-2.6.19-1.2904 does, my notebook suspends and wakes up just fine.
Itÿÿs not enabled for FC6 kernels which are still 2.6.18 based: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215396
There's a 2.6.19 based update in the works, should be out next week.
<OT>
Will that update include a fix for the mmap file corruption bug? Pretty please? :)
</OT>
- Panu -
On Thu, Jan 04, 2007 at 09:26:57AM +0200, Panu Matilainen wrote:
There's a 2.6.19 based update in the works, should be out next week.
Will that update include a fix for the mmap file corruption bug? Pretty please? :)
Of course.
Dave
-------- Original-Message -------- Date: Wed, 3 Jan 2007 17:58:24 -0500 From: Dave Jones davej@redhat.com To: fedora-devel-list@redhat.com Subject: Re: To NX or not to NX
There's a 2.6.19 based update in the works, should be out next week.
Dave
For those interested, you can already grab a preview at:
http://people.redhat.com/davej/kernels/Fedora/FC6/1.2887.fc6
"2.6.19-1.2887.fc6" did not settle my issues .. but maybe yours (?)
On Thu, Jan 04, 2007 at 10:02:44AM +0100, Joachim Frieben wrote:
-------- Original-Message -------- Date: Wed, 3 Jan 2007 17:58:24 -0500 From: Dave Jones davej@redhat.com To: fedora-devel-list@redhat.com Subject: Re: To NX or not to NX
There's a 2.6.19 based update in the works, should be out next week.
DaveFor those interested, you can already grab a preview at:
http://people.redhat.com/davej/kernels/Fedora/FC6/1.2887.fc6
"2.6.19-1.2887.fc6" did not settle my issues .. but maybe yours (?)
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
Dave
On Thursday 04 January 2007 11:23 am, Dave Jones wrote:
On Thu, Jan 04, 2007 at 10:02:44AM +0100, Joachim Frieben wrote:
-------- Original-Message -------- Date: Wed, 3 Jan 2007 17:58:24 -0500 From: Dave Jones davej@redhat.com To: fedora-devel-list@redhat.com Subject: Re: To NX or not to NX
There's a 2.6.19 based update in the works, should be out next week.
DaveFor those interested, you can already grab a preview at:
http://people.redhat.com/davej/kernels/Fedora/FC6/1.2887.fc6
"2.6.19-1.2887.fc6" did not settle my issues .. but maybe yours (?)
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
Dave
FWIW, I've been using 2.6.19-1.2887.fc6 (i686) on FC6-test for a few hours. No issues... tho I was surprised my hd*'s are still hd* rather than sd* as they are on rawhide.
rawhide; $ df Filesystem Size Used Avail Use% Mounted on /dev/sdb1 9.9G 4.5G 5.0G 48% / /dev/sda1 92M 56M 32M 65% /boot tmpfs 502M 0 502M 0% /dev/shm /dev/sdb2 27G 5.7G 20G 23% /home /dev/sda8 41G 25G 14G 65% /stor2 /dev/sdc1 151G 119G 25G 84% /stor4
fc6-test; ~ $ uname -r 2.6.19-1.2887.fc6 ~ $ df Filesystem Size Used Avail Use% Mounted on /dev/hda6 9.7G 4.7G 4.5G 52% / /dev/hda1 92M 45M 42M 52% /boot tmpfs 506M 0 506M 0% /dev/shm /dev/hda7 24G 4.5G 18G 20% /home /dev/hda8 41G 26G 14G 66% /stor2 /dev/sda1 151G 124G 20G 87% /stor4
On Thu, Jan 04, 2007 at 13:52:21 -0600, Tom Brinkman tbrinkman@sbcglobal.net wrote:
FWIW, I've been using 2.6.19-1.2887.fc6 (i686) on FC6-test for a few hours. No issues... tho I was surprised my hd*'s are still hd* rather than sd* as they are on rawhide.
Dave has already said that the libata stuff isn't going to appear in FC6 kernels.
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
There are still 1-2 bits that need some more tweaking/fixing that I already know about, but I'm blocking on other people to get those fixed.
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
Notable points:
- The big difference here vs the 2.6.19 that briefly showed up in rawhide is that this kernel sticks with the older IDE code (so you won't get a nasty surprise when your /dev/hda becomes sda etc). I just don't feel comfortable pushing that as an update without worrying about regressions.
- Another notable change in this update: The addition of -debug kernels. All the slowdowns and nasty dmesg-filling debug output you've come to expect in a rawhide kernel, but in FC6! Well, hopefully not too many of the nasty messages, but this is the same as the other FC6 kernels, but with lockdep, slab debug etc turned on which should prove to be useful for tracking down some of the nastier bugs we've had in recent times. The slow-down from these kernels isn't really *that* bad on most workloads, I tend to run with these turned on all the time, and don't notice the difference (but Santa sometimes brings me shinier computers than others so this may not be universally true).
- 2.6.19-1.2888 and above are based on 2.6.19.2rc1 so have the fix for the nasty data corruption bug that turned up in some workloads.
So, it's there, have it at, beat it up etc. It *should* be pretty solid,
All being well, the current plan is to get a slightly improved version of this into updates-testing on Wednesday. I'll do an FC5 version on the flight to LCA and will get that built and pushed to fc5-updates-testing as soon as I get network connectivity in the land of wallabies, cork hats and `roos.
Dave
Dave Jones <davej <at> redhat.com> writes:
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
2888 is still missing the sata-promise-pata.patch rebase, right? Unfortunately, that makes it unusable for me, because I have a PATA drive on a Promise SATA/PATA RAID controller and there's no way I can rewire things differently because I have 5 IDE/PATA devices (3 HDDs, 1 DVD reader and 1 DVD burner). (I'm posting this mainly so that others in the same situation are warned.)
Kevin Kofler
On Sun, Jan 07, 2007 at 04:42:31AM +0000, Kevin Kofler wrote:
Dave Jones <davej <at> redhat.com> writes:
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
2888 is still missing the sata-promise-pata.patch rebase, right? Unfortunately, that makes it unusable for me, because I have a PATA drive on a Promise SATA/PATA RAID controller and there's no way I can rewire things differently because I have 5 IDE/PATA devices (3 HDDs, 1 DVD reader and 1 DVD burner). (I'm posting this mainly so that others in the same situation are warned.)
yeah, that's one of the aforementioned 'bits that need tweaking'. It's on my todo.
Dave
On 1/6/07, Dave Jones davej@redhat.com wrote:
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
Just for my own information, does this include the alsa 1.0.13 driver codebase?
-jef
Jeff Spaleta schrieb:
On 1/6/07, Dave Jones davej@redhat.com wrote:
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
Dave, booted and runs fine on two of my machines so far. I'll install it on another machine later and will yell if any problems turn up.
BTW, I had RPM database corruptions now and then with 2.6.18 (more than usual with that kernel at least). But it was not really reproducible...
Just for my own information, does this include the alsa 1.0.13 driver codebase?
FYI:
[thl@notebook ~]$ uname -r 2.6.19-1.2888.fc6 [thl@notebook ~]$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28 14:07:24 2006 UTC). [thl@notebook ~]$
CU thl
Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
There are still 1-2 bits that need some more tweaking/fixing that I already know about, but I'm blocking on other people to get those fixed.
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
Notable points:
- The big difference here vs the 2.6.19 that briefly showed up in rawhide is that this kernel sticks with the older IDE code (so you won't get a nasty surprise when your /dev/hda becomes sda etc). I just don't feel comfortable pushing that as an update without worrying about regressions.
It doesn't boot on my rawhide box which is a one IDE hard drive box.
the error is: "/bin/nash: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory. Kernel panic - not syncing: Attempted to kill init!"
none of the other 2.6.19 kernels from rawhide will boot either.
Richard
On Sun, Jan 07, 2007 at 01:03:23AM -0500, Richard Hally wrote:
Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
the error is: "/bin/nash: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory. Kernel panic - not syncing: Attempted to kill init!"
none of the other 2.6.19 kernels from rawhide will boot either.
Looks like a mkinitrd problem.
Dave
Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these. [...]
I installed it on my x86_64 box It boots and works fine. But I found one regression: lm_sensors stopped working. sensors just displays "General parse error" (maybe a updated package is needed) booting into a 2.6.18 kernel solves the issue (sensors works)
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
Dave
dragoran schrieb:
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
+1 -- this, BTW, is tracked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65749 afaics.
CU thl
On Sunday, 07 January 2007 at 09:53, Thorsten Leemhuis wrote:
dragoran schrieb:
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
+1 -- this, BTW, is tracked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65749 afaics.
ntfs-3g fuse driver is in Extras and supports writing. I expect with fc7 this becomes a moot point, because of the Core/Extras merger.
Regards, R.
Dominik 'Rathann' Mierzejewski schrieb:
On Sunday, 07 January 2007 at 09:53, Thorsten Leemhuis wrote:
dragoran schrieb:
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
+1 -- this, BTW, is tracked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65749 afaics.
ntfs-3g fuse driver is in Extras and supports writing. I expect with fc7 this becomes a moot point, because of the Core/Extras merger.
There are some people (like me) that simply prefer the in-kernel ntfs driver. So IMHO let's simply ship both.
CU thl
On Sunday, 07 January 2007 at 13:13, Thorsten Leemhuis wrote:
Dominik 'Rathann' Mierzejewski schrieb:
On Sunday, 07 January 2007 at 09:53, Thorsten Leemhuis wrote:
dragoran schrieb:
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
+1 -- this, BTW, is tracked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65749 afaics.
ntfs-3g fuse driver is in Extras and supports writing. I expect with fc7 this becomes a moot point, because of the Core/Extras merger.
There are some people (like me) that simply prefer the in-kernel ntfs driver. So IMHO let's simply ship both.
Oh, I have nothing against that. I don't know how feasible it is, but perhaps ntfs-3g could be integrated into kernel someday.
Regards, R.
Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 07 January 2007 at 13:13, Thorsten Leemhuis wrote:
Dominik 'Rathann' Mierzejewski schrieb:
On Sunday, 07 January 2007 at 09:53, Thorsten Leemhuis wrote:
dragoran schrieb:
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
+1 -- this, BTW, is tracked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65749 afaics.
ntfs-3g fuse driver is in Extras and supports writing. I expect with fc7 this becomes a moot point, because of the Core/Extras merger.
There are some people (like me) that simply prefer the in-kernel ntfs driver. So IMHO let's simply ship both.
+1
Oh, I have nothing against that. I don't know how feasible it is, but perhaps ntfs-3g could be integrated into kernel someday.
no it can't its a fuse fs (works in userspace) the in kernel driver will support write too (later)
Regards, R.
On Sun, 2007-01-07 at 09:47 +0100, dragoran wrote:
Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these. [...]
I installed it on my x86_64 box It boots and works fine. But I found one regression: lm_sensors stopped working. sensors just displays "General parse error" (maybe a updated package is needed) booting into a 2.6.18 kernel solves the issue (sensors works)
one more thing (not a regression): can you enable the ntfs read only driver in the kernel builds? the patent issues are resolved and there is no need to recompile it every time the kernel gets updated.
Um... This is a FC-6 erratum. Let's not go enabling new stuff in a released version. Rawhide is where this should be enabled first.
josh
Josh Boyer wrote:
[...] Um... This is a FC-6 erratum. Let's not go enabling new stuff in a released version. Rawhide is where this should be enabled first.
I disagree here.. enabling a new filesystem driver in a errata kernel can't break anything (=no regressions) because the driver was not enabled before and it won't get loaded until you do it manually. so I see no reason not to enable it.
josh
On Wed, 2007-01-10 at 22:30 +0100, dragoran wrote:
Josh Boyer wrote:
[...] Um... This is a FC-6 erratum. Let's not go enabling new stuff in a released version. Rawhide is where this should be enabled first.
I disagree here.. enabling a new filesystem driver in a errata kernel can't break anything (=no regressions) because the driver was not enabled before and it won't get loaded until you do it manually. so I see no reason not to enable it.
We'll have to agree to disagree. It can cause yet more burden on the kernel developers if lots of people start enabling and loading it and it breaks. And "now I can mount my ntfs partitions and just use that" is quite and incentive for people to try.
As for regressions, it's in the kernel. It can break anything if has a bug and starts corrupting memory. It has no place in FC-6 IMHO. It should be shaken out in rawhide first.
josh
something about the lm_sensors issue: according to http://www.lm-sensors.org/ a new package is required because of k8_temp
"December 5th, 2006: Note to k8temp users. The Linux 2.6.19 kernel features a new hardware monitoring driver, k8temp, which supports all recent AMD K8 CPUs. The driver will load automatically on supported systems. Due to technical specificities of this driver, upgrade to lm_sensors 2.10.1 is mandatory. Older versions of libsensors will fail with a "General parse error" message. If you can't upgrade lm_sensors for any reason, you'll have to blacklist the k8temp driver to prevent it from being loaded. Thanks to Artem S. Tashkinov for notifying us. " *
*
ok now tested on my core 2 duo laptop (also using x86_64). It works fine here too but I get a weird message on boot: [..] Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping 06 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 728 cycles) Brought up 2 CPUs testing NMI watchdog ... CPU#0: NMI appears to be stuck (59->64)! CPU#1: NMI appears to be stuck (27->32)! time.c: Using 14.318180 MHz WALL HPET GTOD HPET timer. time.c: Detected 2166.829 MHz processor. sizeof(vma)=176 bytes sizeof(page)=64 bytes sizeof(inode)=720 bytes sizeof(dentry)=224 bytes sizeof(ext3inode)=968 bytes sizeof(buffer_head)=104 bytes sizeof(skbuff)=240 bytes sizeof(task_struct)=1904 bytes Uhhuh. NMI received for unknown reason 2c. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 00. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue migration_cost=23 [...] what does this mean? I don't see it with 2.6.18 and I have not seen any problems because of it (yet)
On Sun, 2007-01-07 at 10:22 +0100, dragoran wrote:
ok now tested on my core 2 duo laptop (also using x86_64).
what does this mean? I don't see it with 2.6.18 and I have not seen any problems because of it (yet)
you need to disable nmi_watchdog (by putting nmi_watchdog=0) the code is just broken in recent kernels :( (there's people in my team at Intel working on fixing this)
Dave: please disable nmi_watchdog by default in FC x86-64 kernels.. at least until the worst bugs are fixed (but even then it makes little sense to have it enabled anyway)
On Sun, Jan 07, 2007 at 05:38:44AM -0800, Arjan van de Ven wrote:
On Sun, 2007-01-07 at 10:22 +0100, dragoran wrote:
ok now tested on my core 2 duo laptop (also using x86_64).
what does this mean? I don't see it with 2.6.18 and I have not seen any problems because of it (yet)
you need to disable nmi_watchdog (by putting nmi_watchdog=0) the code is just broken in recent kernels :( (there's people in my team at Intel working on fixing this)
Dave: please disable nmi_watchdog by default in FC x86-64 kernels.. at least until the worst bugs are fixed (but even then it makes little sense to have it enabled anyway)
x86-64 has had it default on for ages though, it's only recently that i386 changed to match. It's odd that it's only now causing problems.
Dave
On Sun, 2007-01-07 at 12:37 -0500, Dave Jones wrote:
On Sun, Jan 07, 2007 at 05:38:44AM -0800, Arjan van de Ven wrote:
On Sun, 2007-01-07 at 10:22 +0100, dragoran wrote:
ok now tested on my core 2 duo laptop (also using x86_64).
what does this mean? I don't see it with 2.6.18 and I have not seen any problems because of it (yet)
you need to disable nmi_watchdog (by putting nmi_watchdog=0) the code is just broken in recent kernels :( (there's people in my team at Intel working on fixing this)
Dave: please disable nmi_watchdog by default in FC x86-64 kernels.. at least until the worst bugs are fixed (but even then it makes little sense to have it enabled anyway)
x86-64 has had it default on for ages though, it's only recently that i386 changed to match. It's odd that it's only now causing problems.
NMI-meets-SMM is a general not fun thing; and even on x86-64 it should be off (see Ingo's posts for this, it's hitting issues there too). Also the NMI watchdog code changed recently to be.. well buggy. (which we're fixing in my team but still as general principle..)
On Sun, Jan 07, 2007 at 10:07:41AM -0800, Arjan van de Ven wrote:
On Sun, 2007-01-07 at 12:37 -0500, Dave Jones wrote:
On Sun, Jan 07, 2007 at 05:38:44AM -0800, Arjan van de Ven wrote:
On Sun, 2007-01-07 at 10:22 +0100, dragoran wrote:
ok now tested on my core 2 duo laptop (also using x86_64).
what does this mean? I don't see it with 2.6.18 and I have not seen any problems because of it (yet)
you need to disable nmi_watchdog (by putting nmi_watchdog=0) the code is just broken in recent kernels :( (there's people in my team at Intel working on fixing this)
Dave: please disable nmi_watchdog by default in FC x86-64 kernels.. at least until the worst bugs are fixed (but even then it makes little sense to have it enabled anyway)
x86-64 has had it default on for ages though, it's only recently that i386 changed to match. It's odd that it's only now causing problems.
NMI-meets-SMM is a general not fun thing; and even on x86-64 it should be off (see Ingo's posts for this, it's hitting issues there too). Also the NMI watchdog code changed recently to be.. well buggy. (which we're fixing in my team but still as general principle..)
I'm about to disappear for the afternoon. If I get back and there's a patch in my inbox it'd be much appreciated (hint, hint ;-)
Dave
after some experiments I found out that: the nmi message only comes at boot and only when using the battery (on AC=no message) when the system runs (heavy laod) with battery/AC no message. also no freezes or anything like that. what could be causing this message?
Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
Booting and running my normal apps shows nothing out of the ordinary that I can see in the first: 01:55:33 up 1:32, 1 user, load average: 0.15, 0.26, 0.55 Linux davidtdesktop 2.6.19-1.2888.fc6 #1 SMP Sat Jan 6 01:05:49 EST 2007 i686 athlon i386 GNU/Linux
3x ide disks + dvd drive. usb mounting normal. nvidia fx5600 using proprietary driver and nvidia-x11-drv-1.0.9746-1 {freshrpms}, that dkms auto recompiled for new kernel during boot {-devel is installed}, and nvidia driver boot operates OK.
Apps used: firefox, thunderbird, gnome-terminal, gkrellm, freecell, openoffice calc, nautilus, fslint {to detect and delete empty directories under /home/* - it found about 20,000}
cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2600+ stepping : 1 cpu MHz : 2079.648 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips : 4160.89
DaveT.
On Sat, 2007-01-06 at 23:06 -0500, Dave Jones wrote:
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
kernel-2.6.19-1.2905.fc7.x86_64 on booting always drops me into fsck for a non-root USB disk [0] that is formatted as an ext3 volume and mounted from fstab as ext3. Incidentally, I just noticed that the partition type as reported by fdisk is still W95FAT(LBA). The fsck error is that it cannot find the superblock. Manually giving the alternate block locations doesn't help. dmesg output is lost since the boot process doesn't complete and I am afraid of forcing it through incase it results in any FS corruption on the USB disk (which works on other kernels).
The same setup works flawlessly on 2.6.18-1.2849.fc6.x86_64, finds the superblocks and mounts the disk at boot time without reporting any errors.
Do let me know if there are any relatively safe things I can do with 2.6.19 that'll help diagnose the problem better.
[0] Bus 002 Device 005: ID 1058:0900 Western Digital Technologies, Inc.
cheers,
On Sun, Jan 07, 2007 at 10:49:32AM -0500, Saikat Guha wrote:
On Sat, 2007-01-06 at 23:06 -0500, Dave Jones wrote:
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
kernel-2.6.19-1.2905.fc7.x86_64 on booting always drops me into fsck for a non-root USB disk [0] that is formatted as an ext3 volume and mounted from fstab as ext3. Incidentally, I just noticed that the partition type as reported by fdisk is still W95FAT(LBA). The fsck error is that it cannot find the superblock. Manually giving the alternate block locations doesn't help. dmesg output is lost since the boot process doesn't complete and I am afraid of forcing it through incase it results in any FS corruption on the USB disk (which works on other kernels).
The same setup works flawlessly on 2.6.18-1.2849.fc6.x86_64, finds the superblocks and mounts the disk at boot time without reporting any errors.
Do let me know if there are any relatively safe things I can do with 2.6.19 that'll help diagnose the problem better.
[0] Bus 002 Device 005: ID 1058:0900 Western Digital Technologies, Inc.
Hmm, odd. Pete, any ideas?
wait, this is an fc7 kernel (which is really 2.6.20rc3). This should have been in another thread.
Dave
Was there anything new about the issue with USB storage (quoted below)? I don't see anything in archives.
-- Pete
On Sun, 7 Jan 2007 13:35:17 -0500, Dave Jones davej@redhat.com wrote:
kernel-2.6.19-1.2905.fc7.x86_64 on booting always drops me into fsck for a non-root USB disk [0] that is formatted as an ext3 volume and mounted from fstab as ext3. Incidentally, I just noticed that the partition type as reported by fdisk is still W95FAT(LBA). The fsck error is that it cannot find the superblock. Manually giving the alternate block locations doesn't help. dmesg output is lost since the boot process doesn't complete and I am afraid of forcing it through incase it results in any FS corruption on the USB disk (which works on other kernels).
The same setup works flawlessly on 2.6.18-1.2849.fc6.x86_64, finds the superblocks and mounts the disk at boot time without reporting any errors.
Do let me know if there are any relatively safe things I can do with 2.6.19 that'll help diagnose the problem better.
[0] Bus 002 Device 005: ID 1058:0900 Western Digital Technologies, Inc.
Hmm, odd. Pete, any ideas?
On Sat, 2007-01-06 at 23:06 -0500, Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
There are still 1-2 bits that need some more tweaking/fixing that I already know about, but I'm blocking on other people to get those fixed.
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
Notable points:
The big difference here vs the 2.6.19 that briefly showed up in rawhide is that this kernel sticks with the older IDE code (so you won't get a nasty surprise when your /dev/hda becomes sda etc). I just don't feel comfortable pushing that as an update without worrying about regressions.
Another notable change in this update: The addition of -debug kernels. All the slowdowns and nasty dmesg-filling debug output you've come to expect in a rawhide kernel, but in FC6! Well, hopefully not too many of the nasty messages, but this is the same as the other FC6 kernels, but with lockdep, slab debug etc turned on which should prove to be useful for tracking down some of the nastier bugs we've had in recent times. The slow-down from these kernels isn't really *that* bad on most workloads, I tend to run with these turned on all the time, and don't notice the difference (but Santa sometimes brings me shinier computers than others so this may not be universally true).
2.6.19-1.2888 and above are based on 2.6.19.2rc1 so have the fix for the nasty data corruption bug that turned up in some workloads.
So, it's there, have it at, beat it up etc. It *should* be pretty solid,
All being well, the current plan is to get a slightly improved version of this into updates-testing on Wednesday. I'll do an FC5 version on the flight to LCA and will get that built and pushed to fc5-updates-testing as soon as I get network connectivity in the land of wallabies, cork hats and `roos.
I am now having the same problems on my laptop that I experience when using the netdev kernels. My prism54 wireless card won't get a dhcp address using NetworkManager. If I manually ifup the wireless interface it does work properly. How would you like bug reports for this kernel put into bugzilla?
Jon
On 1/7/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On Sat, 2007-01-06 at 23:06 -0500, Dave Jones wrote:
On Thu, Jan 04, 2007 at 12:23:02PM -0500, Dave Jones wrote:
note that this build doesn't have the fix for the mmap corruption problem which got quite a bit of attention last week. I'll get a fixed build up there soon, but in the meantime, tread carefully with this one.
I've been working on a 2.6.19 update for FC6 over the last few weeks, and it's starting to feel 'almost ready'. Before I push this out to updates-testing though, I'd rather have a few people 'kick the tyres' to make sure there's nothing really silly wrong with these.
There are still 1-2 bits that need some more tweaking/fixing that I already know about, but I'm blocking on other people to get those fixed.
You can find them at http://people.redhat.com/davej/kernels/Fedora/FC6/
Notable points:
The big difference here vs the 2.6.19 that briefly showed up in rawhide is that this kernel sticks with the older IDE code (so you won't get a nasty surprise when your /dev/hda becomes sda etc). I just don't feel comfortable pushing that as an update without worrying about regressions.
Another notable change in this update: The addition of -debug kernels. All the slowdowns and nasty dmesg-filling debug output you've come to expect in a rawhide kernel, but in FC6! Well, hopefully not too many of the nasty messages, but this is the same as the other FC6 kernels, but with lockdep, slab debug etc turned on which should prove to be useful for tracking down some of the nastier bugs we've had in recent times. The slow-down from these kernels isn't really *that* bad on most workloads, I tend to run with these turned on all the time, and don't notice the difference (but Santa sometimes brings me shinier computers than others so this may not be universally true).
2.6.19-1.2888 and above are based on 2.6.19.2rc1 so have the fix for the nasty data corruption bug that turned up in some workloads.
So, it's there, have it at, beat it up etc. It *should* be pretty solid,
All being well, the current plan is to get a slightly improved version of this into updates-testing on Wednesday. I'll do an FC5 version on the flight to LCA and will get that built and pushed to fc5-updates-testing as soon as I get network connectivity in the land of wallabies, cork hats and `roos.
I am now having the same problems on my laptop that I experience when using the netdev kernels. My prism54 wireless card won't get a dhcp address using NetworkManager. If I manually ifup the wireless interface it does work properly. How would you like bug reports for this kernel put into bugzilla?
Jon
This might be more of a NetworkManager issue or timing problem. I have the same problem with the current rawhide on a couple of different laptops that are using the ipw2x00 drivers.
darrell
On Sun, Jan 07, 2007 at 02:50:10PM -0500, Jon Nettleton wrote:
I am now having the same problems on my laptop that I experience when using the netdev kernels. My prism54 wireless card won't get a dhcp address using NetworkManager. If I manually ifup the wireless interface it does work properly. How would you like bug reports for this kernel put into bugzilla?
Yes, please do file bugs about this, and other issues found in this kernel.
Dave
On Sun, 2007-01-07 at 15:10 -0500, Dave Jones wrote:
On Sun, Jan 07, 2007 at 02:50:10PM -0500, Jon Nettleton wrote:
I am now having the same problems on my laptop that I experience when using the netdev kernels. My prism54 wireless card won't get a dhcp address using NetworkManager. If I manually ifup the wireless interface it does work properly. How would you like bug reports for this kernel put into bugzilla?
Yes, please do file bugs about this, and other issues found in this kernel.
Dave
Do you want me to set the bug assigned to you?
On Sun, Jan 07, 2007 at 03:28:41PM -0500, Jon Nettleton wrote:
On Sun, 2007-01-07 at 15:10 -0500, Dave Jones wrote:
On Sun, Jan 07, 2007 at 02:50:10PM -0500, Jon Nettleton wrote:
I am now having the same problems on my laptop that I experience when using the netdev kernels. My prism54 wireless card won't get a dhcp address using NetworkManager. If I manually ifup the wireless interface it does work properly. How would you like bug reports for this kernel put into bugzilla?
Yes, please do file bugs about this, and other issues found in this kernel.
DaveDo you want me to set the bug assigned to you?
Assign to linville@redhat.com , and add me to Cc.
Dave
Some notes:
< sizeof(inode)=424 bytes < sizeof(dentry)=148 bytes < sizeof(ext3inode)=600 bytes < sizeof(buffer_head)=52 bytes ---
sizeof(inode)=568 bytes sizeof(dentry)=156 bytes sizeof(ext3inode)=804 bytes sizeof(buffer_head)=56 bytes
I thought work was being done to *reduce* the size of inodes? Or is this the result of the debug stuff?
Found a new device:
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.00 (08-Oct-2006) iTCO_wdt: Found a ICH3-M TCO device (Version=1, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
Otherwise fine.
On Tue, Jan 09, 2007 at 03:41:34PM -0700, Orion Poplawski wrote:
Some notes:
< sizeof(inode)=424 bytes < sizeof(dentry)=148 bytes < sizeof(ext3inode)=600 bytes
< sizeof(buffer_head)=52 bytes
sizeof(inode)=568 bytes sizeof(dentry)=156 bytes sizeof(ext3inode)=804 bytes sizeof(buffer_head)=56 bytes
I thought work was being done to *reduce* the size of inodes? Or is this the result of the debug stuff?
yes. various structs in the debug kernel will be bigger.
Dave
-
Arjan van de Ven -
Bruno Wolff III -
Chris Adams -
darrell pfeifer -
Dave Jones -
Development discussions related to Fedora -
Dominik 'Rathann' Mierzejewski -
drago01 -
Jef Spaleta -
Joachim Frieben -
Jon Nettleton -
Josh Boyer -
Kevin Kofler -
Louis Garcia -
Orion Poplawski -
Panu Matilainen -
Pete Zaitcev -
Ralf Ertzinger -
Richard Hally -
Saikat Guha -
Sertaç Ö. Yıldız -
Thorsten Leemhuis -
Tom