I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
There's still a number of bugs that affect a lot of users (like the acpi_power_off issue which I still don't have a handle on, despite being able to reproduce it and spending countless hours building kernels with extra debugging). Hopefully I'll get some of the other nastier issues knocked off soon.
So, in the meantime, try out -698, and file bugs if something new broke. (And please close any old ones that went away with this kernel). The last 2.6.9 update closed quite a few long-standing bugs, however a *lot* of bugs are still in NEEDINFO awaiting confirmation with the new kernel(s).
The biggest change in this kernel over the older ones that affects all x86 users, is that the 4g/4g memory split is no longer the default. If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again. The regular non-hugemem kernels have the traditional 3:1 split. Due to this quite large change, this kernel could really use folks jumping up and down on it for a while before it gets pushed into updates-proper.
Thanks,
Dave
* Fri Dec 3 2004 Dave Jones davej@redhat.com - Pull in bits of -ac12 Should fix the smbfs & visor issues among others.
* Thu Dec 2 2004 Dave Jones davej@redhat.com - Drop the futex debug patch, it served its purpose. - XFRM layer bug fixes - ppc64: Convert to using ibm,read-slot-reset-state2 RTAS call - ide: Make CSB6 driver support configurations. - ide: Handle early EOF on CDs. - Fix sx8 device naming in sysfs - e100/e1000: return -EINVAL when setting rx-mini or rx-jumbo. (#140793)
* Wed Dec 1 2004 Dave Jones davej@redhat.com - Disable 4G/4G for i686. - Workaround for the E1000 erratum 23 (#140047) - Remove bogus futex warning. (#138179) - x86_64: Fix lost edge triggered irqs on UP kernel. - x86_64: Reenable DRI for MGA. - Workaround E1000 post-maturely writing back to TX descriptors (#133261) - 3c59x: add EEPROM_RESET for 3c900 Boomerang - Fix buffer overrun in arch/x86_64/sys_ia32.c:sys32_ni_syscall() - ext3: improves ext3's error logging when we encounter an on-disk corruption. - ext3: improves ext3's ability to deal with corruption on-disk - ext3: Handle double-delete of indirect blocks. - Disable SCB2 flash driver for RHEL4. (#141142)
* Tue Nov 30 2004 Dave Jones davej@redhat.com - x86_64: add an option to configure oops stack dump - x86[64]: display phys_proc_id only when it is initialized - x86_64: no TIOCSBRK/TIOCCBRK in ia32 emulation - via-rhine: references __init code during resume - Add barriers to generic timer code to prevent race. (#128242) - ppc64: Add PURR and version data to /proc/ppc64/lparcfg - Prevent xtime value becoming incorrect. - scsi: return full SCSI status byte in SG_IO - Fix show_trace() in irq context with CONFIG_4KSTACKS - Adjust alignment of pagevec structure. - md: make sure md always uses rdev_dec_pending properly. - Make proc_pid_status not dereference dead task structs. - sg: Fix oops of sg_cmd_done and sg_release race (#140648) - fix bad segment coalescing in blk_recalc_rq_segments() - fix missing security_*() check in net/compat.c - ia64/x86_64/s390 overlapping vma fix - Update Emulex lpfc to 8.0.15
* Mon Nov 29 2004 Dave Jones davej@redhat.com - Add another card reader to whitelist. (#141022) - Fix possible hang in do_wait() (#140042) - Fix ps showing wrong ppid. (#132030) - Print advice to use -hugemem if >=16GB of memory is detected. - Enable ICOM serial driver. (#136150) - Enable acpi hotplug driver for IA64. - SCSI: fix USB forced remove oops. - ia64: add missing sn2 timer mask in time_interpolator code. (#140580) - ia64: Fix hang reading /proc/pal/cpu0/tr_info (#139571) - ia64: bump number of UARTS. (#139100) - Fix ACPI debug level (#141292) - Make EDD runtime configurable, and reenable. - ppc64: IBM VSCSI driver race fix. (#138725) - ppc64: Ensure PPC64 interrupts don't end up hard-disabled. (#139020, #131590) - ppc64: Yet more sigsuspend/singlestep fixing. (#140102, #137931) - x86-64: Implement ACPI based reset mechanism. (#139104) - Backport 2.6.10rc sysfs changes needed for IBM hotplug driver. (#140372) - Update Emulex lpfc driver to v8.0.14 - Optimize away the unconditional write to debug registers on signal delivery path. - Fix up scsi_test_unit_ready() to work correctly with CD-ROMs. - md: fix two little bugs in raid10 - Remove incorrect ELF check from module loading. (#140954) - Plug leaks in error paths of aic driver. - Add refcounting to scsi command allocation. - Taint oopses on machine checks, bad_page()'s calls and forced rmmod's. - Share Intel cache descriptors between x86 & x86-64. - rx checksum support for gige nForce ethernet - vm: vm_dirty_ratio initialisation fix
* Mon Nov 29 2004 Soeren Sandmann sandmann@redhat.com - Build FC-3 kernel in RHEL build root
* Sun Nov 28 2004 Dave Jones davej@redhat.com - Move 4g/4g kernel into -hugemem.
* Sat Nov 27 2004 Dave Jones davej@redhat.com - Recognise Shuttle SN85G4 card reader. (#139163)
* Tue Nov 23 2004 Dave Jones davej@redhat.com - Add futex debug patch.
On Fri, 2004-12-03 at 23:06 -0500, Dave Jones wrote:
snip
The biggest change in this kernel over the older ones that affects all x86 users, is that the 4g/4g memory split is no longer the default. If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again. The regular non-hugemem kernels have the traditional 3:1 split.
Dave,
Is the fix for the b44 issue (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165) incorporated into the kernels yet?
You had a comment indicating that Pekka's fix is in CVS (Comment #69), but I had not seen it mentioned in the changelogs for these last couple of kernel updates. Is the comment referring to Linus' CVS or Fedora's?
Also, does the change in the 4g/4g status influence the b44 fix?
Thanks Dave!
Marc Schwartz
On Fri, Dec 03, 2004 at 10:51:29PM -0600, Marc Schwartz wrote:
The biggest change in this kernel over the older ones that affects all x86 users, is that the 4g/4g memory split is no longer the default. If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again. The regular non-hugemem kernels have the traditional 3:1 split.
Is the fix for the b44 issue (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165) incorporated into the kernels yet?
yes. I actually trimmed too much of the changelog. There's another few days of changes that went in.
Also, does the change in the 4g/4g status influence the b44 fix?
In that the bug only affects -hugemem. So it's doubly fixed 8)
Dave
* Mon Nov 22 2004 Dave Jones davej@redhat.com - Update -ac patch to 2.6.9-ac11 - make tulip_stop_rxtx() wait for DMA to fully stop. (#138240) - ACPI: Make LEqual less strict about operand types matching. - scsi: avoid extra 'put' on devices in __scsi_iterate_device() (#138135) - Fix bugs with SOCK_SEQPACKET AF_UNIX sockets - Reenable token ring drivers. (#119345) - SELinux: Map Unix seqpacket sockets to appropriate security class - SELinux: destroy avtab node cache in policy load error path. - AF_UNIX: Serialize dgram read using semaphore just like stream. - lockd: NLM blocks locks don't sleep - NFS lock recovery fixes - Add more MODULE_VERSION tags (#136403) - Update qlogic driver to 2.6.10rc2 level. - cciss: fixes for clustering - ieee802.11 update. - ipw2100: update to ver 1.0.0 - ipw2200: update to ver 1.0.0 - Enable promisc mode on ipw2100 - 3c59x: reload EEPROM values at rmmod for needy cards - ppc64: Prevent sigsuspend stomping on r4 and r5 - ppc64: Alternative single-step fix. - fix for recursive netdump oops on x86_64 - ia64: Fix IRQ routing fix when booted with maxcpus= (#138236) - ia64: search the iommu for the correct size - Deal with fraglists correctly on ipv4/ipv6 output - Various statm accounting fixes (#139447) - Reenable CMM /proc interface for s390 (#137397)
* Fri Nov 19 2004 Dave Jones davej@redhat.com - e100: fix improper enabling of interrupts. (#139706) - autofs4: allow map update recognition - Various TCP fixes from 2.6.10rc - Various netlink fixes from 2.6.10rc - [IPV4]: Do not try to unhash null-netdev nexthops. - ppc64: Make NUMA map CPU->node before bringing up the CPU (#128063) - ppc64: sched domains / cpu hotplug cleanup. (#128063) - ppc64: Add a CPU_DOWN_PREPARE hotplug CPU notifier (#128063) - ppc64: Register a cpu hotplug notifier to reinitialize the scheduler domains hierarchy (#128063) - ppc64: Introduce CPU_DOWN_FAILED notifier (#128063) - ppc64: Make arch_destroy_sched_domains() conditional (#128063) - ppc64: Use CPU_DOWN_FAILED notifier in the sched-domains hotplug code (#128063) - Various updates to the SCSI midlayer from 2.6.10rc. - vlan_dev: return 0 on vlan_dev_change_mtu success. (#139760) - Update Emulex lpfc driver to v8013 - Fix problem with b44 driver and 4g/4g patch. (#118165) - Prevent oops when loading aic79xx on machine without hardware. (#125982) - Use correct spinlock functions in token ring net code. (#135462) - scsi: Add reset ioctl capability to ULDs - scsi: update ips driver to 7.10.18 - Reenable ACPI hotplug driver. (#139976, #140130, #132691)
On Sat, 2004-12-04 at 00:06 -0500, Dave Jones wrote:
On Fri, Dec 03, 2004 at 10:51:29PM -0600, Marc Schwartz wrote:
The biggest change in this kernel over the older ones that affects all x86 users, is that the 4g/4g memory split is no longer the default. If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again. The regular non-hugemem kernels have the traditional 3:1 split.
Is the fix for the b44 issue (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165) incorporated into the kernels yet?
yes. I actually trimmed too much of the changelog. There's another few days of changes that went in.
Also, does the change in the 4g/4g status influence the b44 fix?
In that the bug only affects -hugemem. So it's doubly fixed 8)
Dave
snip
- Fix problem with b44 driver and 4g/4g patch. (#118165)
Great! :-)
As soon as the new kernel hits my mirror I will install it.
Thanks!
Marc
Why can't something be done short term to fix the Marvell gigabyte lan module missing mess. The update from Syskonnect has been available since early October 04. It was supported in earlier 2.6 kernels?
Anyone? And don't tell me someone has to add it upstream at kernel.org, cause that's ridiculous.
RaXeT
-----Original Message----- From: fedora-test-list-bounces@redhat.com [mailto:fedora-test-list-bounces@redhat.com] On Behalf Of Marc Schwartz Sent: Friday, December 03, 2004 10:18 PM To: Dave Jones Cc: For testers of Fedora Core development releases Subject: Re: New testing kernel.
On Sat, 2004-12-04 at 00:06 -0500, Dave Jones wrote:
On Fri, Dec 03, 2004 at 10:51:29PM -0600, Marc Schwartz wrote:
The biggest change in this kernel over the older ones that affects all x86 users, is that the 4g/4g memory split is no longer the default. If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again. The regular non-hugemem kernels have the traditional 3:1 split.
Is the fix for the b44 issue (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165) incorporated into the kernels yet?
yes. I actually trimmed too much of the changelog. There's another few days of changes that went in.
Also, does the change in the 4g/4g status influence the b44 fix?
In that the bug only affects -hugemem. So it's doubly fixed 8)
Dave
snip
- Fix problem with b44 driver and 4g/4g patch. (#118165)
Great! :-)
As soon as the new kernel hits my mirror I will install it.
Thanks!
Marc
On Sat, 4 Dec 2004, raxet wrote:
Why can't something be done short term to fix the Marvell gigabyte lan module missing mess. The update from Syskonnect has been available since early October 04. It was supported in earlier 2.6 kernels?
Anyone? And don't tell me someone has to add it upstream at kernel.org, cause that's ridiculous.
Why is that ridiculous? I do not even know what a Marvell gigabyte lan thingy is but if you read the Fedora Charter you will see that getting it upstream is the correct thing to do. The reasoning for this is that if it is not good enough to be upstream then why should it be in the Fedora kernels?
To me, your attitide sounds ridiculous, but that is just me, I suppose.
Oh and one more thing, any possibility you could stop top posting and trim your responses?
Regards,
Tom
Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Hi Dave, I'm a little confused as to how this kernel relates to the latest kernel (kernel-2.6.9-1.1009_FC4) in the /development tree ("rawhide") . Does the rawhide kernel have all these changes? A little more generally, as you go forward what will be the progression as relates to the /development tree, testing, updates? Will /development be "the latest and greatest" as it has been in the past? Then move the same kernel into testing for a wider audience, then the same kernel to updates for the rest? Thanks, Richard Hally
On Sat, Dec 04, 2004 at 01:16:07AM -0500, Richard Hally wrote:
Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Hi Dave, I'm a little confused as to how this kernel relates to the latest kernel (kernel-2.6.9-1.1009_FC4) in the /development tree ("rawhide") . Does the rawhide kernel have all these changes?
Tomorrows snapshot will. (2.6.9-1.1014_FC4) The FC3 kernels appeared first as updates appear as soon as I ask someone to sign & push them, the rawhide push is automated once daily.
A little more generally, as you go forward what will be the progression as relates to the /development tree, testing, updates? Will /development be "the latest and greatest" as it has been in the past? Then move the same kernel into testing for a wider audience, then the same kernel to updates for the rest?
I'm trying to get a staircase effect going on, where a new kernel appears in rawhide, then in FC3, if that works out, a little later it goes into FC2 too etc. (Though last time around, FC2 went out in parallel with FC3 as it'd gone without updates for so long).
RHEL4 changes also factor into the equation here, its sort of hard to explain the 'model', but basically all 4 'current' trees are being kept up to date in parallel, and usually lag each other by at most a few days -- The RHEL kernels typically differ only in which CONFIG_ options are set.
We're now at ~200 patches on top of mainline. I used to be quite proud of being only 40 csets away from mainline, however, that was when we were tracking upstream on a daily basis. As we're not doing that right now, we're essentially pulling in selective parts of the upstream snapshots, so I don't feel its quite so bad as having 200 or so 'feature' patches that aren't upstream.
There's not a lot of stuff on the plate for FC4 kernel-wise right now. I considered rebasing to 2.6.10rc, but its a few days work, and as its still a moving target, stabilising 2.6.9 for FC3 and pushing that into FC4 (with some extra bits like Xen) seems to be the way we're going forward. As well as Xen, the only other real difference is rawhide also has slab_debugging on, so we take a slight performance hit (this is always enabled during FCx-test phases, and then disabled for the production builds), but we do get to see any memory corruption bugs really quickly. The plus side of this hit is that any bugs found and fixed will also be relevant for FC2/FC3/RHEL4.
I'm not sure of the timeline for FC4test1 yet, so its possible things could change by the time we get there, but right now, 2.6.10rc hasn't been anywhere near as stable as 2.6.9-ac in my testing. I'm sure this will change in time, but jumping onboard now isn't really going to buy us much (other than lowering the patchcount again ;-)
I'll reassess the situation in the new year.
Dave
Dave Jones wrote:
On Sat, Dec 04, 2004 at 01:16:07AM -0500, Richard Hally wrote:
Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Hi Dave, I'm a little confused as to how this kernel relates to the latest kernel (kernel-2.6.9-1.1009_FC4) in the /development tree ("rawhide") . Does the rawhide kernel have all these changes?
Tomorrows snapshot will. (2.6.9-1.1014_FC4) The FC3 kernels appeared first as updates appear as soon as I ask someone to sign & push them, the rawhide push is automated once daily.
A little more generally, as you go forward what will be the progression as relates to the /development tree, testing, updates? Will /development be "the latest and greatest" as it has been in the past? Then move the same kernel into testing for a wider audience, then the same kernel to updates for the rest?
I'm trying to get a staircase effect going on, where a new kernel appears in rawhide, then in FC3, if that works out, a little later it goes into FC2 too etc. (Though last time around, FC2 went out in parallel with FC3 as it'd gone without updates for so long).
RHEL4 changes also factor into the equation here, its sort of hard to explain the 'model', but basically all 4 'current' trees are being kept up to date in parallel, and usually lag each other by at most a few days -- The RHEL kernels typically differ only in which CONFIG_ options are set.
Thank you very much for the (more than I expected) explanation and also the status report below! This kind of excellent communication really helps people keep "in tune" with the project. Thanks again, Richard Hally
We're now at ~200 patches on top of mainline. I used to be quite proud of being only 40 csets away from mainline, however, that was when we were tracking upstream on a daily basis. As we're not doing that right now, we're essentially pulling in selective parts of the upstream snapshots, so I don't feel its quite so bad as having 200 or so 'feature' patches that aren't upstream.
There's not a lot of stuff on the plate for FC4 kernel-wise right now. I considered rebasing to 2.6.10rc, but its a few days work, and as its still a moving target, stabilising 2.6.9 for FC3 and pushing that into FC4 (with some extra bits like Xen) seems to be the way we're going forward. As well as Xen, the only other real difference is rawhide also has slab_debugging on, so we take a slight performance hit (this is always enabled during FCx-test phases, and then disabled for the production builds), but we do get to see any memory corruption bugs really quickly. The plus side of this hit is that any bugs found and fixed will also be relevant for FC2/FC3/RHEL4.
I'm not sure of the timeline for FC4test1 yet, so its possible things could change by the time we get there, but right now, 2.6.10rc hasn't been anywhere near as stable as 2.6.9-ac in my testing. I'm sure this will change in time, but jumping onboard now isn't really going to buy us much (other than lowering the patchcount again ;-)
I'll reassess the situation in the new year.
Dave
On Friday 03 December 2004 23:04, Richard Hally wrote:
Dave Jones wrote:
On Sat, Dec 04, 2004 at 01:16:07AM -0500, Richard Hally wrote:
Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Hi Dave, I'm a little confused as to how this kernel relates to the latest kernel (kernel-2.6.9-1.1009_FC4) in the /development tree ("rawhide") . Does the rawhide kernel have all these changes?
Tomorrows snapshot will. (2.6.9-1.1014_FC4) The FC3 kernels appeared first as updates appear as soon as I ask someone to sign & push them, the rawhide push is automated once daily.
A little more generally, as you go forward what will be the progression as relates to the /development tree, testing, updates? Will /development be "the latest and greatest" as it has been in the past? Then move the same kernel into testing for a wider audience, then the same kernel to updates for the rest?
I'm trying to get a staircase effect going on, where a new kernel appears in rawhide, then in FC3, if that works out, a little later it goes into FC2 too etc. (Though last time around, FC2 went out in parallel with FC3 as it'd gone without updates for so long).
RHEL4 changes also factor into the equation here, its sort of hard to explain the 'model', but basically all 4 'current' trees are being kept up to date in parallel, and usually lag each other by at most a few days -- The RHEL kernels typically differ only in which CONFIG_ options are set.
Thank you very much for the (more than I expected) explanation and also the status report below! This kind of excellent communication really helps people keep "in tune" with the project. Thanks again, Richard Hally
We're now at ~200 patches on top of mainline. I used to be quite proud of being only 40 csets away from mainline, however, that was when we were tracking upstream on a daily basis. As we're not doing that right now, we're essentially pulling in selective parts of the upstream snapshots, so I don't feel its quite so bad as having 200 or so 'feature' patches that aren't upstream.
There's not a lot of stuff on the plate for FC4 kernel-wise right now. I considered rebasing to 2.6.10rc, but its a few days work, and as its still a moving target, stabilising 2.6.9 for FC3 and pushing that into FC4 (with some extra bits like Xen) seems to be the way we're going forward. As well as Xen, the only other real difference is rawhide also has slab_debugging on, so we take a slight performance hit (this is always enabled during FCx-test phases, and then disabled for the production builds), but we do get to see any memory corruption bugs really quickly. The plus side of this hit is that any bugs found and fixed will also be relevant for FC2/FC3/RHEL4.
I'm not sure of the timeline for FC4test1 yet, so its possible things could change by the time we get there, but right now, 2.6.10rc hasn't been anywhere near as stable as 2.6.9-ac in my testing. I'm sure this will change in time, but jumping onboard now isn't really going to buy us much (other than lowering the patchcount again ;-)
I'll reassess the situation in the new year.
Dave
Hi Dave (& all the development team):
Just adding my thanks to the others for a job well done. Keep up the good work.
Thanks, Tom
Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
This this fixed my palm oops - noted this on Bugzilla 140005. -Bob Arendt
Once upon a time, Dave Jones davej@redhat.com said:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Is there any chance that we could get the old MegaRAID driver built so those of us not using the latest-n-greatest MegaRAID cards can use FC3? See Bugzillas 135484 and 138590.
Basically, the new MegaRAID driver only works with MegaRAID cards with a newer command interface. Also, some cards with that command interface are not in the PCI ID list (so the driver won't talk to some cards that it would work on). The idea of the new MegaRAID driver was that there would be two: one for new cards and one for old cards. However, nobody ever wrote the driver for the old cards. I proposed on linux-scsi that the Kconfig.megaraid be changed to allow both driver to build (right now the config only allows you to select the old driver if you say "n" to the new driver), but that doesn't appear to have gone anywhere either.
According to the initial Bugzilla entry, the switch to the new driver didn't happen until FC 2.92 (test3); major driver changes shouldn't be made that late in the test cycle. Also, the change was not done correctly; the PCI ID files weren't updated, so anaconda loads the new driver for every MegaRAID card (when it shouldn't be loaded for many of them).
It seems like the real solution would be to switch back to the old driver until either the new driver (or a second driver) can handle all the cards or the kernel config and anaconda are changed to handle both the old and new drivers along side each other.
On Sat, Dec 04, 2004 at 10:54:11PM -0600, Chris Adams wrote:
Once upon a time, Dave Jones davej@redhat.com said:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
Is there any chance that we could get the old MegaRAID driver built so those of us not using the latest-n-greatest MegaRAID cards can use FC3? See Bugzillas 135484 and 138590.
The first commit I did after releasing that updates-testing kernel actually was to do just this. It removes the restriction that you can only build either the old or the new driver.
The next kernel to hit updates-testing will have megaraid.ko as well as megaraid_mbox.ko
Dave
Once upon a time, Dave Jones davej@redhat.com said:
The first commit I did after releasing that updates-testing kernel actually was to do just this. It removes the restriction that you can only build either the old or the new driver.
The next kernel to hit updates-testing will have megaraid.ko as well as megaraid_mbox.ko
Thanks. Should I open a Bugzilla (against hwconf I guess?) about the PCI ID lists being updated? It looks like someone just did a s/megaraid/megaraid_mbox/, but that is not correct.
On Sat, Dec 04, 2004 at 11:04:49PM -0600, Chris Adams wrote:
Once upon a time, Dave Jones davej@redhat.com said:
The first commit I did after releasing that updates-testing kernel actually was to do just this. It removes the restriction that you can only build either the old or the new driver.
The next kernel to hit updates-testing will have megaraid.ko as well as megaraid_mbox.ko
Thanks. Should I open a Bugzilla (against hwconf I guess?) about the PCI ID lists being updated? It looks like someone just did a s/megaraid/megaraid_mbox/, but that is not correct.
hwdata.
Dave
Le vendredi 03 décembre 2004 à 23:06 -0500, Dave Jones a écrit :
I just made a 2.6.9-1.698_FC3 set of kernels (snip)
Thanks for all you work. But ...
I did a lot of file copy (80 Gb) with 2.6.9-1.698_FC3 and got some little problems.
Exemple : $ ll -d /home/fmatias/ drwxr-xr-x 50 750 users 12288 déc 5 18:12 /home/fmatias/
Owner "750", should be "fmatias". I see sometime like this two times (files and directories) with a custom 2.6.9-1.698_FC3. My custom kernel is tainted with : http://www.bewan.fr/bewan/utilisateurs/telechargement/download.php?id=81 I also use mga_vid module : http://www.linuxops.net/~pw/mga_vid/
bewan works nice from a long time. I use mga_vid since 2.6.9-1.681_FC3. I'm back to 2.6.9-1.681_FC3 (custom).
Should I try to reproduce this problem with the "official" 2.6.9-1.698_FC3 ?
fre, 03,.12.2004 kl. 23.06 -0500, skrev Dave Jones:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
There's still a number of bugs that affect a lot of users (like the acpi_power_off issue which I still don't have a handle on, despite being able to reproduce it and spending countless hours building kernels with extra debugging). Hopefully I'll get some of the other nastier issues knocked off soon.
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Cheers
Em Qua, 2004-12-08 às 14:06 +0100, Kjartan Maraas escreveu:
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
On Wed, 8 Dec 2004, Alexandre Strube wrote:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
Is there a bugzilla entry for this?
I've had something similar happen. The crash happened when logging back into gnome (half way through gnome statup mechanism). This was probably with 681 kernel. Don't have enough info to track it down.
Satish
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Em Qua, 2004-12-08 às 14:06 +0100, Kjartan Maraas escreveu:
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
There are a number of folks at Red Hat currently looking into this, but please feel free to try disabling/enabling kernel options to try and help track it down, as we're currently scratching our collective heads over this one.
Dave
Em Qua, 2004-12-08 às 22:39 -0500, Dave Jones escreveu:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some There are a number of folks at Red Hat currently looking into this, but please feel free to try disabling/enabling kernel options to try and help track it down, as we're currently scratching our collective heads over this one.
Sorry the dumb question.. but how? I've been logged on since then.
On Wed, 2004-12-08 at 22:39 -0500, Dave Jones wrote:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Em Qua, 2004-12-08 às 14:06 +0100, Kjartan Maraas escreveu:
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
can't it be simply solved for fedora by not changing the 4g/4g setting for now ?
Once upon a time, Dave Jones davej@redhat.com said:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
Hmm, my father's computer does this (hard lock on GNOME logout) in FC2. He can shut down or reboot, and X exits fine; he just can't log out (so he has to reboot if he wants to log out and back in for some reason). I haven't had a change to diagnose it (and I definately didn't think about the kernel).
On Thu, 9 Dec 2004 08:44:27 -0600, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Dave Jones davej@redhat.com said:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
Hmm, my father's computer does this (hard lock on GNOME logout) in FC2. He can shut down or reboot, and X exits fine; he just can't log out (so he has to reboot if he wants to log out and back in for some reason). I haven't had a change to diagnose it (and I definately didn't think about the kernel).
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
I don't see this behaviour on any of my Athlon machines running via chipset motherboards. I do see it at work on a Dell Dimension 4550. My solution at work has been to use the SMP kernel. I worked on this by hand and found that the problem didn't happen if I had APIC enabled in the kernel. Not sure if this is the same problem, but it is definitely the same symptom.
On Thu, 9 Dec 2004, Jon Nettleton wrote:
On Thu, 9 Dec 2004 08:44:27 -0600, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Dave Jones davej@redhat.com said:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
Hmm, my father's computer does this (hard lock on GNOME logout) in FC2. He can shut down or reboot, and X exits fine; he just can't log out (so he has to reboot if he wants to log out and back in for some reason). I haven't had a change to diagnose it (and I definately didn't think about the kernel).
I don't see this behaviour on any of my Athlon machines running via chipset motherboards. I do see it at work on a Dell Dimension 4550. My solution at work has been to use the SMP kernel. I worked on this by hand and found that the problem didn't happen if I had APIC enabled in the kernel. Not sure if this is the same problem, but it is definitely the same symptom.
In my limited attempts to reproduce this - I've had the hang with 698 a couple of times. But after I disabled DRI - I couldn't crash it (in 4/5 tries). This is with ATI9000 mobile (so could be a radeon issue)
But I've had to reboot today due to #142329 - now I'm back to 681 to see if this issue is less frequent with the older kernel.
Satish
Em Qui, 2004-12-09 às 15:05, Satish Balay escreveu:
In my limited attempts to reproduce this - I've had the hang with 698 a couple of times. But after I disabled DRI - I couldn't crash it (in 4/5 tries). This is with ATI9000 mobile (so could be a radeon issue)
Hum. this can be an idea. I`ve been using savage's dri driver since RH9 on this machine. Upgraded it to FC1, FC2, and now FC3, and always recompiled DRI for the current kernel. This issue begin to happen only recently with the two latest kernels.
On Thu, 9 Dec 2004, Satish Balay wrote:
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
In my limited attempts to reproduce this - I've had the hang with 698 a couple of times. But after I disabled DRI - I couldn't crash it (in 4/5 tries). This is with ATI9000 mobile (so could be a radeon issue)
This problem still persists in kernel 2.6.9-1.715_FC3.
Satish
On Wed, 2004-12-08 at 22:39 -0500, Dave Jones wrote:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Em Qua, 2004-12-08 às 14:06 +0100, Kjartan Maraas escreveu:
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
There are a number of folks at Red Hat currently looking into this, but please feel free to try disabling/enabling kernel options to try and help track it down, as we're currently scratching our collective heads over this one.
I've seen a crash with the non 4g/4g one also though I'm not a 100% sure whether it happened when logging out from GNOME or afterwards -- I logged out and left immediately afterwards, after a 1 hour's drive it wasn't accessible remotely and when I came home Caps&Scroll-Lock where blinking.
Nils
On Thu, 2004-12-09 at 18:19 +0100, Nils Philippsen wrote:
On Wed, 2004-12-08 at 22:39 -0500, Dave Jones wrote:
On Wed, Dec 08, 2004 at 10:11:47PM -0300, Alexandre Strube wrote:
Em Qua, 2004-12-08 às 14:06 +0100, Kjartan Maraas escreveu:
I'm seeing a lockup here when closing the lid on a HP nc4010 laptop. Didn't see that in -1.681FC3.
Is this related with logging out from gnome and, when the gdm screen should appear, the computer locks up hard? This is happening with latest kernels. I don't know what to do anymore.
We've spotted that happening for a while with the RHEL4 kernel. It's started happening since we switched off the 4g/4g patch for some reason. This one really needs solving before the current updates-testing kernel can be pushed as an update as it seems to affect quite a few people.
There are a number of folks at Red Hat currently looking into this, but please feel free to try disabling/enabling kernel options to try and help track it down, as we're currently scratching our collective heads over this one.
I've seen a crash with the non 4g/4g one also though I'm not a 100% sure whether it happened when logging out from GNOME or afterwards -- I logged out and left immediately afterwards, after a 1 hour's drive it wasn't accessible remotely and when I came home Caps&Scroll-Lock where blinking.
I have had a similar problem here with both GNOME and Xfce (4.2 from CVS).
The kernel resolved the problem that I had with the Broadcom NIC (b44) however, which was great.
I did not note this new issue until I logged out the first time and then it was reproducible each time from both desktops. It does not 'crash' per se, but I get a hard lock up which requires a power down and re- boot.
This is on a Dell 5150 laptop, 2 Gb RAM, nVidia video card using the nVidia 6629 driver.
None of this happens of course with the 681 kernel.
Marc Schwartz
On Fri, 2004-12-03 at 23:06 -0500, Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
There's still a number of bugs that affect a lot of users (like the acpi_power_off issue which I still don't have a handle on, despite being able to reproduce it and spending countless hours building kernels with extra debugging). Hopefully I'll get some of the other nastier issues knocked off soon.
So, in the meantime, try out -698, and file bugs if something new broke. (And please close any old ones that went away with this kernel). The last 2.6.9 update closed quite a few long-standing bugs, however a *lot* of bugs are still in NEEDINFO awaiting confirmation with the new kernel(s).
I am still seeing this bug on this kernel:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137129
-tduffy
On Mon, Dec 13, 2004 at 11:00:56AM -0800, Tom Duffy wrote:
On Fri, 2004-12-03 at 23:06 -0500, Dave Jones wrote:
I just made a 2.6.9-1.698_FC3 set of kernels which fix a number of bugs (Full changelog below), including some of the more popular ones that were introduced during the last update (namely, smbfs should work again, and hopefully the palm/visor oopses should be gone too).
There's still a number of bugs that affect a lot of users (like the acpi_power_off issue which I still don't have a handle on, despite being able to reproduce it and spending countless hours building kernels with extra debugging). Hopefully I'll get some of the other nastier issues knocked off soon.
So, in the meantime, try out -698, and file bugs if something new broke. (And please close any old ones that went away with this kernel). The last 2.6.9 update closed quite a few long-standing bugs, however a *lot* of bugs are still in NEEDINFO awaiting confirmation with the new kernel(s).
I am still seeing this bug on this kernel:
Strange. I thought I nuked that msg for that kernel. http://people.redhat.com/davej/kernels/Fedora/FC3/ has a snapshot-of-the-day, which should have it removed for sure. (I just checked, its #if 0'd out).
This will go out as another updates-testing soon.
Dave
On Mon, 2004-12-13 at 14:11 -0500, Dave Jones wrote:
Strange. I thought I nuked that msg for that kernel.
What message?
http://people.redhat.com/davej/kernels/Fedora/FC3/ has a snapshot-of-the-day, which should have it removed for sure. (I just checked, its #if 0'd out).
This will go out as another updates-testing soon.
I will try that out today.
Here was the latest panic messages:
Unable to handle kernel paging request at fffffeff80143897 RIP: [<fffffeff80143897>] PML4 0 Oops: 0010 [1] CPU 0 Modules linked in: md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core ds yenta_socket pcmcia_core sunrpc ext3 jbd dm_mod button battery ac ohci_hcd ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameporUnable to handle kernel paging request at fffffeff80143897 RIP: [<fffffeff80143897>] PML4 0 Oops: 0010 [1] CPU 0 Modules linked in: md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core ds yenta_socket pcmcia_core sunrpc ext3 jbd dm_mod button battery ac ohci_hcd ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore e1000 forcedeth floppy xfs sata_nv libata qla2300 qla2xxx scsi_transport_fc sd_mod scsi_mod Pid: 0, comm: swapper Not tainted 2.6.9-1.698_FC3 RIP: 0010:[<fffffeff80143897>] [<fffffeff80143897>] RSP: 0018:ffffffff804a10f0 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffffffff8042f860 RCX: 000001003f5abe88 RDX: ffffffff804a1108 RSI: ffffffff8042ff40 RDI: 000001003f5a93d0 RBP: 000001003f5a93d0 R08: ffffffff804a1108 R09: 0000000000000001 R10: 0000000000000246 R11: ffffffff8050a780 R12: fffffeff80143897 R13: ffffffff804a1108 R14: 0000000000000000 R15: 0000000000000000 FS: 0000002a95566ec0(0000) GS:ffffffff80512700(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: fffffeff80143897 CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff80514000, task ffffffff80420a00) Stack: ffffffff80143150 0000000000000000 0000000000000246 ffffffff804a1108 ffffffff804a1108 ffffffff80514000 000001003e37a700 0000000004000001 0000000000000001 ffffffff804cc930 Call Trace:<IRQ> <ffffffff80143150>{run_timer_softirq+663} <ffffffff8013efcc>{__do_softirq+76} <ffffffff8013f053>{do_softirq+49} <ffffffff801138cb>{do_IRQ+756} <ffffffff80110d6b>{ret_from_intr+0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle+26} <ffffffff805176fc>{start_kernel+641} <ffffffff805171ab>{_sinittext+427}
Code: Bad RIP value. RIP [<fffffeff80143897>] RSP <ffffffff804a10f0> CR2: fffffeff80143897 <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 in_atomic():1[expected: 0], irqs_disabled():0
Call Trace:<IRQ> <ffffffff80133387>{__might_sleep+173} <ffffffff80139fb9>{profile_task_exit+33} <ffffffff8013bae6>{do_exit+34} <ffffffff80111da2>{oops_end+159} <ffffffff801247ce>{do_page_fault+1155} <ffffffff8011d4e9>{smp_apic_timer_interrupt+49} <ffffffff80110efd>{apic_timer_interrupt+133} <ffffffff80132ca9>{recalc_task_prio+337} <ffffffff80111099>{error_exit+0} <ffffffff80143150>{run_timer_softirq+663} <ffffffff8013efcc>{__do_softirq+76} <ffffffff8013f053>{do_softirq+49} <ffffffff801138cb>{do_IRQ+756} <ffffffff80110d6b>{ret_from_intr+0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle+26} <ffffffff805176fc>{start_kernel+641} <ffffffff805171ab>{_sinittext+427} Kernel panic - not syncing: Aiee, killing interrupt handler! t snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore e1000 forcedeth floppy xfs sata_nv libata qla2300 qla2xxx scsi_transport_fc sd_mod scsi_mod Pid: 0, comm: swapper Not tainted 2.6.9-1.698_FC3 RIP: 0010:[<fffffeff80143897>] [<fffffeff80143897>] RSP: 0018:ffffffff804a10f0 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffffffff8042f860 RCX: 000001003f5abe88 RDX: ffffffff804a1108 RSI: ffffffff8042ff40 RDI: 000001003f5a93d0 RBP: 000001003f5a93d0 R08: ffffffff804a1108 R09: 0000000000000001 R10: 0000000000000246 R11: ffffffff8050a780 R12: fffffeff80143897 R13: ffffffff804a1108 R14: 0000000000000000 R15: 0000000000000000 FS: 0000002a95566ec0(0000) GS:ffffffff80512700(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: fffffeff80143897 CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff80514000, task ffffffff80420a00) Stack: ffffffff80143150 0000000000000000 0000000000000246 ffffffff804a1108 ffffffff804a1108 ffffffff80514000 000001003e37a700 0000000004000001 0000000000000001 ffffffff804cc930 Call Trace:<IRQ> <ffffffff80143150>{run_timer_softirq+663} <ffffffff8013efcc>{__do_softirq+76} <ffffffff8013f053>{do_softirq+49} <ffffffff801138cb>{do_IRQ+756} <ffffffff80110d6b>{ret_from_intr+0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle+26} <ffffffff805176fc>{start_kernel+641} <ffffffff805171ab>{_sinittext+427}
Code: Bad RIP value. RIP [<fffffeff80143897>] RSP <ffffffff804a10f0> CR2: fffffeff80143897 <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 in_atomic():1[expected: 0], irqs_disabled():0
Call Trace:<IRQ> <ffffffff80133387>{__might_sleep+173} <ffffffff80139fb9>{profile_task_exit+33} <ffffffff8013bae6>{do_exit+34} <ffffffff80111da2>{oops_end+159} <ffffffff801247ce>{do_page_fault+1155} <ffffffff8011d4e9>{smp_apic_timer_interrupt+49} <ffffffff80110efd>{apic_timer_interrupt+133} <ffffffff80132ca9>{recalc_task_prio+337} <ffffffff80111099>{error_exit+0} <ffffffff80143150>{run_timer_softirq+663} <ffffffff8013efcc>{__do_softirq+76} <ffffffff8013f053>{do_softirq+49} <ffffffff801138cb>{do_IRQ+756} <ffffffff80110d6b>{ret_from_intr+0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle+26} <ffffffff805176fc>{start_kernel+641} <ffffffff805171ab>{_sinittext+427} Kernel panic - not syncing: Aiee, killing interrupt handler!
On Mon, 2004-12-13 at 14:11 -0500, Dave Jones wrote:
Strange. I thought I nuked that msg for that kernel. http://people.redhat.com/davej/kernels/Fedora/FC3/ has a snapshot-of-the-day, which should have it removed for sure. (I just checked, its #if 0'd out).
Got this on the 715 kernel:
Unable to handle kernel paging request at fffffeff8014278f RIP: [<fffffeff8014278f>] PML4 0 Oops: 0010 [1] CPU 0 Modules linked in: md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core ds yenta_socket pcmcia_core sunrpc ext3 jbd sr_mod dm_mod usb_storage button battery ac joydev ohci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore e1000 forcedeth floppy xfs sata_nv libata qla2300 qla2xxx scsi_transport_fc sd_mod scsi_mod Pid: 0, comm: swapper Not tainted 2.6.9-1.715_FC3 RIP: 0010:[<fffffeff8014278f>] [<fffffeff8014278f>] RSP: 0018:ffffffff8048be80 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffffffff8041a4e0 RCX: 000001003f585e88 RDX: ffffffff8048be98 RSI: fffffeff8014278f RDI: 000001003f602b60 RBP: ffffffff8048be98 R08: ffffffff8048be98 R09: 000001003ec8f240 R10: 000001003ec8f240 R11: ffffffff80501f18 R12: 000000000000007a R13: ffffffff80501f18 R14: 0000000000000000 R15: 0000000000000000 FS: 0000002a95566b00(0000) GS:ffffffff804fd700(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: fffffeff8014278f CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff80500000, task ffffffff8040b680) Stack: ffffffff8014205d ffffffff80501f18 0000000000000246 ffffffff8048be98 ffffffff8048be98 0000000000000000 ffffffff802b621c 0000000000000001 ffffffff804b7930 000000000000000a Call Trace:<IRQ> <ffffffff8014205d>{run_timer_softirq+591} <ffffffff802b621c>{usb_hcd_irq+41} <ffffffff8013e1dc>{__do_softirq+76} <ffffffff8013e263>{do_softirq +49} <ffffffff8011379f>{do_IRQ+664} <ffffffff80110d0f>{ret_from_intr +0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle+26} <ffffffff805036f3>{start_kernel +632} <ffffffff805031ab>{_sinittext+427}
Code: Bad RIP value. RIP [<fffffeff8014278f>] RSP <ffffffff8048be80> CR2: fffffeff8014278f <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 in_atomic():1[expected: 0], irqs_disabled():0
Call Trace:<IRQ> <ffffffff8013311b>{__might_sleep+173} <ffffffff8013968d>{profile_task_exit+33} <ffffffff8013b0c6>{do_exit+34} <ffffffff80111d46>{oops_end+159} <ffffffff8012423a>{do_page_fault+1155} <ffffffff8013378b>{__wake_up_common+67} <ffffffff8011103d>{error_exit+0} <ffffffff8014205d>{run_timer_softirq+591} <ffffffff802b621c>{usb_hcd_irq+41} <ffffffff8013e1dc>{__do_softirq+76} <ffffffff8013e263>{do_softirq+49} <ffffffff8011379f>{do_IRQ+664} <ffffffff80110d0f>{ret_from_intr+0} <EOI> <ffffffff8010e647>{default_idle+0} <ffffffff8010e667>{default_idle+32} <ffffffff8010e6d7>{cpu_idle +26} <ffffffff805036f3>{start_kernel+632} <ffffffff805031ab>{_sinittext+427}
Kernel panic - not syncing: Aiee, killing interrupt handler!
Two new ones this time. 2.6.9-1.9_FC2 and 2.6.9-1.715_FC3 As usual, they're 99% the same (dependancy/specfile diffs only).
Fixes all over the map, see the changelog below for the gory details. These are going out to updates-proper fairly soon unless something horrible turns up.
Dave
* Sun Dec 12 2004 Dave Jones davej@redhat.com - fix false ECHILD result from wait* with zombie group leader.
* Sat Dec 11 2004 Dave Jones davej@redhat.com - Workaround broken pci posting in AGPGART. - Make sure VC resizing fits in s16.
* Fri Dec 10 2004 Dave Jones davej@redhat.com - Prevent block device queues from being shared in viocd. (#139018) - Libata updates. (#132848, #138405) - aacraid: remove aac_handle_aif (#135527) - fix uninitialized variable in waitid(2). (#142505) - Fix CMSG validation checks wrt. signedness. - Fix memory leak in ip_conntrack_ftp - [IPV4]: Do not leak IP options. - ppc64: Align PACA buffer for hypervisor's use. (#141817) - ppc64: Indicate that the veth link is always up. (#135402) - ppc64: Quiesce OpenFirmware stdin device at boot. (#142009) - SELinux: Fix avc_node_update oops. (#142353) - Fix CCISS ioctl return code. - Make ppc64's pci_alloc_consistent() conform to documentation. (#140047) - Disable tiglusb module. (#142102) - E1000 64k-alignment fix. (#140047) - Disable tiglusb module. (#142102) - ID updates for cciss driver. - Fix overflows in USB Edgeport-IO driver. (#142258) - Fix wrong TASK_SIZE for 32bit processes on x86-64. (#141737) - Fix ext2/ext3 xattr/mbcache race. (#138951) - Fix bug where __getblk_slow can loop forever when pages are partially mapped. (#140424) - Add missing cache flushes in agpgart code.
* Wed Dec 8 2004 Dave Jones davej@redhat.com - Enable EDD - Enable ETH1394. (#138497) - Workaround E1000 post-maturely writing back to TX descriptors. (#133261) - Fix the previous E1000 errata workaround. - Several IDE fixes from 2.6.9-ac - vm pageout throttling. (#133858) - Fix Tux from oopsing. (#140918) - Fix Tux/SELinux incompatability (#140916) - Fix Tux/IPV6 problem. (#140916) - ide: Fix possible oops on boot. - Make spinlock debugging panic instead of printk. - Update Emulex lpfc driver to 8.0.16 - Selected patches from 2.6.9-ac12 - ppc64: Fix inability to find space for TCE table (#138844) - Fix compat fcntl F_GETLK{,64} (#141680) - blkdev_get_blocks(): handle eof - Another card reader for the whitelist. (#134094)
* Sat Dec 4 2004 Dave Jones davej@redhat.com - Enable both old and new megaraid drivers. - Add yet another card reader to usb scsi whitelist. (#141367) - Fix oops in conntrack on rmmod.
Le lundi 13 décembre 2004 à 17:33 -0500, Dave Jones a écrit :
Two new ones this time. 2.6.9-1.9_FC2 and 2.6.9-1.715_FC3 As usual, they're 99% the same (dependancy/specfile diffs only).
Fixes all over the map, see the changelog below for the gory details. These are going out to updates-proper fairly soon unless something horrible turns up.
Today I try 714_FC3 and got some Ooops (udev and hotplug). See attachment.
Unable to handle kernel paging request at virtual address d92bc828 printing eip: c014fe57 *pde = 190001e3 Oops: 0000 [#1] Modules linked in: mga parport_pc lp parport nls_utf8 loop dm_mod button battery ac tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc i2c_core videodev snd_via82xx snd_mpu401_uart snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore gameport dummy ext3 jbd raid0 CPU: 0 EIP: 0060:[<c014fe57>] Not tainted VLI EFLAGS: 00010287 (2.6.9-1.714_FC3) EIP is at zap_pte_range+0xc7/0x21c eax: 0021f000 ebx: db191008 ecx: c1325780 edx: 00015000 esi: 00000000 edi: 00000000 ebp: d92bc828 esp: db781df4 ds: 007b es: 007b ss: 0068 Process udevd (pid: 3393, threadinfo=db781000 task=db011850) Stack: 1ece7045 00015000 00a0a000 c03d90b4 00a0a000 00a1f000 db19100c c03d90b4 c014ffee 00015000 00000000 00a0a000 db19100c 00a1f000 c03d90b4 c015004d 00015000 00000000 db781e9c 00a0a000 db78b858 00a1f000 c0150161 00a1f000 Call Trace: [<c014ffee>] zap_pmd_range+0x42/0x65 [<c015004d>] unmap_page_range+0x3c/0x5f [<c0150161>] unmap_vmas+0xf1/0x1df [<c0155017>] exit_mmap+0xb8/0x1cf [<c011d36a>] mmput+0xb3/0xd6 [<c016df35>] exec_mmap+0x278/0x292 [<c016e1ba>] flush_old_exec+0x43/0x361 [<c016dcb3>] kernel_read+0x31/0x3b [<c019235f>] load_elf_binary+0x527/0xbd1 [<c016d801>] copy_strings+0x22b/0x235 [<c016f207>] search_binary_handler+0x72/0x1b1 [<c016f4ae>] do_execve+0x168/0x1f6 [<c0104964>] sys_execve+0x2a/0x6f [<c030243b>] syscall_call+0x7/0xb Code: 40 00 29 7c 24 04 81 64 24 04 00 f0 ff ff 85 f6 74 0d 8b 46 04 85 c0 75 06 83 3e 00 0f 44 f0 31 ff 3b 7c 24 04 0f 83 39 01 00 00 <8b> 55 00 85 d2 0f 84 20 01 00 00 f6 c2 81 0f 84 f6 00 00 00 89 <6>note: udevd[3393] exited with preempt_count 1 Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 in_atomic():1[expected: 0], irqs_disabled():0 [<c011ca40>] __might_sleep+0x7d/0x89 [<c012259f>] do_exit+0xd8/0x54f [<c01067c5>] do_divide_error+0x0/0xea [<c01195bc>] do_page_fault+0x380/0x4dc [<c014fe57>] zap_pte_range+0xc7/0x21c [<c01426ec>] file_read_actor+0x78/0xc9 [<c014266c>] do_generic_mapping_read+0x374/0x37c [<c011923c>] do_page_fault+0x0/0x4dc [<c03025bf>] error_code+0x2f/0x38 [<c014fe57>] zap_pte_range+0xc7/0x21c [<c014ffee>] zap_pmd_range+0x42/0x65 [<c015004d>] unmap_page_range+0x3c/0x5f [<c0150161>] unmap_vmas+0xf1/0x1df [<c0155017>] exit_mmap+0xb8/0x1cf [<c011d36a>] mmput+0xb3/0xd6 [<c016df35>] exec_mmap+0x278/0x292 [<c016e1ba>] flush_old_exec+0x43/0x361 [<c016dcb3>] kernel_read+0x31/0x3b [<c019235f>] load_elf_binary+0x527/0xbd1 [<c016d801>] copy_strings+0x22b/0x235 [<c016f207>] search_binary_handler+0x72/0x1b1 [<c016f4ae>] do_execve+0x168/0x1f6 [<c0104964>] sys_execve+0x2a/0x6f [<c030243b>] syscall_call+0x7/0xb bad: scheduling while atomic! [<c02fff31>] schedule+0x2d/0x544 [<c01063f1>] dump_stack+0x11/0x13 [<c011ca40>] __might_sleep+0x7d/0x89 [<c01225a4>] do_exit+0xdd/0x54f [<c01067c5>] do_divide_error+0x0/0xea [<c01195bc>] do_page_fault+0x380/0x4dc [<c014fe57>] zap_pte_range+0xc7/0x21c [<c01426ec>] file_read_actor+0x78/0xc9 [<c014266c>] do_generic_mapping_read+0x374/0x37c [<c011923c>] do_page_fault+0x0/0x4dc [<c03025bf>] error_code+0x2f/0x38 [<c014fe57>] zap_pte_range+0xc7/0x21c [<c014ffee>] zap_pmd_range+0x42/0x65 [<c015004d>] unmap_page_range+0x3c/0x5f [<c0150161>] unmap_vmas+0xf1/0x1df [<c0155017>] exit_mmap+0xb8/0x1cf [<c011d36a>] mmput+0xb3/0xd6 [<c016df35>] exec_mmap+0x278/0x292 [<c016e1ba>] flush_old_exec+0x43/0x361 [<c016dcb3>] kernel_read+0x31/0x3b [<c019235f>] load_elf_binary+0x527/0xbd1 [<c016d801>] copy_strings+0x22b/0x235 [<c016f207>] search_binary_handler+0x72/0x1b1 [<c016f4ae>] do_execve+0x168/0x1f6 [<c0104964>] sys_execve+0x2a/0x6f [<c030243b>] syscall_call+0x7/0xb Unable to handle kernel paging request at virtual address d9ed2000 printing eip: c0118cbd *pde = 19ecf163 Oops: 0003 [#2] Modules linked in: mga parport_pc lp parport nls_utf8 loop dm_mod button battery ac tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc i2c_core videodev snd_via82xx snd_mpu401_uart snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore gameport dummy ext3 jbd raid0 CPU: 0 EIP: 0060:[<c0118cbd>] Not tainted VLI EFLAGS: 00010216 (2.6.9-1.714_FC3) EIP is at pte_alloc_one+0x33/0x49 eax: 00000000 ebx: c133da40 ecx: 00000400 edx: 00000016 esi: 00000000 edi: d9ed2000 ebp: d9ed2000 esp: db781cd0 ds: 007b es: 007b ss: 0068 Process hotplug (pid: 3399, threadinfo=db781000 task=db011850) Stack: 080ddc3c df0787c0 080ddc3c db7a4080 daf33e40 c014f87d df0787c0 080ddc3c db7a4080 c01522a0 df0787c0 df0787f0 db011850 daf33e40 c01193e8 00000001 00000001 080ddc3c db781dd4 c0310eb1 00000002 0000000e 0000000b c011af65 Call Trace: [<c014f87d>] pte_alloc_map+0x66/0x12d [<c01522a0>] handle_mm_fault+0xb0/0x1fd [<c01193e8>] do_page_fault+0x1ac/0x4dc [<c011af65>] recalc_task_prio+0x128/0x133 [<c01481c0>] prio_tree_insert+0xe8/0x15c [<c014863b>] vma_prio_tree_insert+0x17/0x2a [<c0153283>] __vma_link+0x59/0x66 [<c0153371>] vma_link+0xe1/0x1dd [<c011923c>] do_page_fault+0x0/0x4dc [<c03025bf>] error_code+0x2f/0x38 [<c01d8e67>] direct_clear_user+0x56/0x64 [<c019269c>] load_elf_binary+0x864/0xbd1 [<c016dcb3>] kernel_read+0x31/0x3b [<c016f207>] search_binary_handler+0x72/0x1b1 [<c01914ab>] load_script+0x1e7/0x1f8 [<c019295f>] load_elf_binary+0xb27/0xbd1 [<c0145d7e>] __alloc_pages+0xb4/0x298 [<c016d801>] copy_strings+0x22b/0x235 [<c016f207>] search_binary_handler+0x72/0x1b1 [<c016f4ae>] do_execve+0x168/0x1f6 [<c0104964>] sys_execve+0x2a/0x6f [<c030243b>] syscall_call+0x7/0xb [<c0131c21>] __exec_usermodehelper+0x1a9/0x1c1 [<c0131c4a>] ____call_usermodehelper+0x11/0x1b [<c0131c39>] ____call_usermodehelper+0x0/0x1b [<c01041d9>] kernel_thread_helper+0x5/0xb Code: 57 56 31 f6 53 51 b9 1c 0d 35 c0 e8 28 d0 02 00 85 c0 89 c3 74 23 ba 16 00 00 00 e8 29 1e 00 00 89 c5 89 c7 b9 00 04 00 00 89 f0 <f3> ab ba 16 00 00 00 89 e8 e8 c8 1e 00 00 5a 89 d8 5b 5e 5f 5d <6>note: hotplug[3399] exited with preempt_count 1 Unable to handle kernel paging request at virtual address d9c1e000 printing eip: c0151b66 *pde = 19c001e3 Oops: 0002 [#3] Modules linked in: mga parport_pc lp parport nls_utf8 loop dm_mod button battery ac tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc i2c_core videodev snd_via82xx snd_mpu401_uart snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore gameport dummy ext3 jbd raid0 CPU: 0 EIP: 0060:[<c0151b66>] Not tainted VLI EFLAGS: 00010216 (2.6.9-1.714_FC3) EIP is at do_anonymous_page+0xbf/0x27f eax: 00000000 ebx: df0787c0 ecx: 00000400 edx: 00000016 esi: 00000000 edi: d9c1e000 ebp: c13383c0 esp: da926e74 ds: 007b es: 007b ss: 0068 Process hotplug (pid: 3419, threadinfo=da926000 task=daa0a130) Stack: d9c1e000 ded4a530 db054e40 dadf2500 00000000 db7a409c df0787c0 c0151d7b db7a409c 00000001 09d40cb4 00000000 da926ef0 c01713ae c14dbaa0 00000000 00000000 00000000 09d40cb4 db054e40 00000001 df0787c0 09d40cb4 db7a409c Call Trace: [<c0151d7b>] do_no_page+0x55/0x3bf [<c01713ae>] do_lookup+0x1f/0x8f [<c01522c5>] handle_mm_fault+0xd5/0x1fd [<c01193e8>] do_page_fault+0x1ac/0x4dc [<c016d17a>] sys_fstat64+0x1e/0x23 [<c017568c>] do_fcntl+0x174/0x1dd [<c011923c>] do_page_fault+0x0/0x4dc [<c03025bf>] error_code+0x2f/0x38 Code: c0 b8 d2 00 00 00 e8 84 41 ff ff 85 c0 89 c5 0f 84 cb 01 00 00 ba 16 00 00 00 e8 81 8f fc ff 89 04 24 89 c7 b9 00 04 00 00 89 f0 <f3> ab 8b 04 24 ba 16 00 00 00 e8 1e 90 fc ff 81 7b 54 3c 4b 24 <6>note: hotplug[3419] exited with preempt_count 1
Le lundi 13 décembre 2004 à 18:08 -0500, Dave Jones a écrit :
On Mon, Dec 13, 2004 at 11:54:21PM +0100, Féliciano Matias wrote:
Today I try 714_FC3 and got some Ooops (udev and hotplug). See attachment.
Add to bugzilla please.
Done : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142774
On Mon, 13 Dec 2004, Dave Jones wrote:
Two new ones this time. 2.6.9-1.9_FC2 and 2.6.9-1.715_FC3 As usual, they're 99% the same (dependancy/specfile diffs only).
Regarding kernel-hugemem - your eariler post says:
"If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again."
Does this mean - it won't work on machines less than 16GB?
I tired it on my thinkpad - with 1GB (assuming it should be simlar to the current kernel-2.6.9-1.681_FC3 with 4g/4g) - but it wouldn't boot. It was stuck at:
Uncompressing Linux... Ok, booting the kernel
Satish
On Tue, Dec 14, 2004 at 11:22:33AM -0600, Satish Balay wrote:
On Mon, 13 Dec 2004, Dave Jones wrote:
Two new ones this time. 2.6.9-1.9_FC2 and 2.6.9-1.715_FC3 As usual, they're 99% the same (dependancy/specfile diffs only).
Regarding kernel-hugemem - your eariler post says:
"If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again."
Does this mean - it won't work on machines less than 16GB?
It should work just fine. Remember, this was the default configuration until recently, so if earlier kernels worked, this should too.
I tired it on my thinkpad - with 1GB (assuming it should be simlar to the current kernel-2.6.9-1.681_FC3 with 4g/4g) - but it wouldn't boot. It was stuck at:
That's very odd, and not something I have an explanation for. Did you have 'quiet' on the boot command line ? Removing it may print something more useful.
Dave
On Tue, 14 Dec 2004, Dave Jones wrote:
On Tue, Dec 14, 2004 at 11:22:33AM -0600, Satish Balay wrote:
On Mon, 13 Dec 2004, Dave Jones wrote:
Two new ones this time. 2.6.9-1.9_FC2 and 2.6.9-1.715_FC3 As usual, they're 99% the same (dependancy/specfile diffs only).
Regarding kernel-hugemem - your eariler post says:
"If you have a lot of memory (16GB or more), or have a workload that benefits from being able to have more address space, you can use the -hugemem kernel to run with 4g/4g again."
Does this mean - it won't work on machines less than 16GB?
It should work just fine. Remember, this was the default configuration until recently, so if earlier kernels worked, this should too.
I tired it on my thinkpad - with 1GB (assuming it should be simlar to the current kernel-2.6.9-1.681_FC3 with 4g/4g) - but it wouldn't boot. It was stuck at:
That's very odd, and not something I have an explanation for. Did you have 'quiet' on the boot command line ? Removing it may print something more useful.
Its stuck at the same place after removing 'rhgb quiet' options.
Satish