[arch-dev-public] Update: kernel26 2.6.25.1-1
Changes are: - updates to .1 upstream patch - catalyst should work on x86_64 now - iotop works now - removed toshiba-acpi patch. The one or two people who need it should refer to this: http://aur.archlinux.org/packages.php?ID=16934 This is a general example of how to build a patched driver without having to build the whole kernel - updated unionfs - updated acpi dsdt initrd patch, it is still broken though, see here: http://bugs.archlinux.org/task/10381 - group scheduler disabled, it seems it causes big latencies. slmodem and martian are still broken, I didn't get to look at that yet. I think about dropping them, as probably only a handfull of people use them. I'd also like to hear some opinions on re-adding mactel. They have updates now and apparently some people have problems without them (one report of a non-bootable system, dunno if it's mactel-related).
On Mon, May 12, 2008 at 2:06 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Changes are: - updates to .1 upstream patch
Just one (stupid?) question : why not .3? http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.2 http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.3
Xavier schrieb:
On Mon, May 12, 2008 at 2:06 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Changes are: - updates to .1 upstream patch
Just one (stupid?) question : why not .3? http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.2 http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.3
Because I am slow and dumb, that's why.
Thomas Bächler schrieb:
Changes are: - updates to .1 upstream patch - catalyst should work on x86_64 now - iotop works now - removed toshiba-acpi patch. The one or two people who need it should refer to this: http://aur.archlinux.org/packages.php?ID=16934 This is a general example of how to build a patched driver without having to build the whole kernel - updated unionfs - updated acpi dsdt initrd patch, it is still broken though, see here: http://bugs.archlinux.org/task/10381 - group scheduler disabled, it seems it causes big latencies.
slmodem and martian are still broken, I didn't get to look at that yet. I think about dropping them, as probably only a handfull of people use them.
I'd also like to hear some opinions on re-adding mactel. They have updates now and apparently some people have problems without them (one report of a non-bootable system, dunno if it's mactel-related).
Okay, x86_64 has been updated to 2.6.25.3, i686 is building right now and will be uploaded when I return in a few hours. Everything else is the same as above.
On Mon, May 12, 2008 at 8:32 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Thomas Bächler schrieb:
Changes are: - updates to .1 upstream patch - catalyst should work on x86_64 now - iotop works now - removed toshiba-acpi patch. The one or two people who need it should refer to this: http://aur.archlinux.org/packages.php?ID=16934 This is a general example of how to build a patched driver without having to build the whole kernel - updated unionfs - updated acpi dsdt initrd patch, it is still broken though, see here: http://bugs.archlinux.org/task/10381 - group scheduler disabled, it seems it causes big latencies.
slmodem and martian are still broken, I didn't get to look at that yet. I think about dropping them, as probably only a handfull of people use them.
I'd also like to hear some opinions on re-adding mactel. They have updates now and apparently some people have problems without them (one report of a non-bootable system, dunno if it's mactel-related).
Are these patches ever going to go upstream? If not, then I vote no. There has to be a reason upstream won't take them, and thats reason enough for me to say no in our stock kernel.
Okay, x86_64 has been updated to 2.6.25.3, i686 is building right now and will be uploaded when I return in a few hours. Everything else is the same as above.
i686 is looking fine here, just rebooted and all is well. Nothing too exotic with my setup though. -Dan
On Mon, May 12, 2008 at 8:20 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, May 12, 2008 at 8:32 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Thomas Bächler schrieb:
Changes are: - updates to .1 upstream patch - catalyst should work on x86_64 now - iotop works now - removed toshiba-acpi patch. The one or two people who need it should refer to this: http://aur.archlinux.org/packages.php?ID=16934 This is a general example of how to build a patched driver without having to build the whole kernel - updated unionfs - updated acpi dsdt initrd patch, it is still broken though, see here: http://bugs.archlinux.org/task/10381 - group scheduler disabled, it seems it causes big latencies.
slmodem and martian are still broken, I didn't get to look at that yet. I think about dropping them, as probably only a handfull of people use them.
I'd also like to hear some opinions on re-adding mactel. They have updates now and apparently some people have problems without them (one report of a non-bootable system, dunno if it's mactel-related).
Are these patches ever going to go upstream? If not, then I vote no. There has to be a reason upstream won't take them, and thats reason enough for me to say no in our stock kernel.
Okay, x86_64 has been updated to 2.6.25.3, i686 is building right now and will be uploaded when I return in a few hours. Everything else is the same as above.
i686 is looking fine here, just rebooted and all is well. Nothing too exotic with my setup though.
Spoke too early. Does this mean nvidia could benefit from a recompile? I don't know if some symbols changed since the initial compile for .25. Damn xscreensaver killing my machine. BUG: unable to handle kernel NULL pointer dereference at 00000148 IP: [<f930957c>] :nvidia:os_set_mlock_capability+0xc/0x30 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ipv6 nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables sg sd_mod ext2 usb_storage scsi_mod parport_pc snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device firewire_ohci firewire_core crc_itu_t snd_intel8x0 snd_ac97_codec serio_raw ppdev snd_pcm_oss snd_mixer_oss ac97_bus snd_pcm nvidia(P) snd_timer snd lp parport ohci1394 psmouse soundcore snd_page_alloc ppp_generic slhc pcspkr ieee1394 ehci_hcd ohci_hcd shpchp pci_hotplug sis_agp agpgart thermal evdev processor fan button battery ac it87 hwmon_vid eeprom i2c_sis96x i2c_core floppy 8139too mii rtc_cmos rtc_core rtc_lib usbcore ext3 jbd mbcache ide_cd_mod cdrom ide_disk ide_pci_generic sis5513 ide_core Pid: 17241, comm: hypnowheel Tainted: P (2.6.25-ARCH #1) EIP: 0060:[<f930957c>] EFLAGS: 00010286 CPU: 0 EIP is at os_set_mlock_capability+0xc/0x30 [nvidia] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000286 ESI: f7afc000 EDI: f7140c00 EBP: f2c63ea8 ESP: f2c63e9c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hypnowheel (pid: 17241, ti=f2c62000 task=f6f7f200 task.ti=f2c62000) Stack: f908aadf f7021280 00000006 f2c63ec8 f908c44c 0000005b f94d0da0 f2c13c80 f908d97b f7afc000 00000001 f2c63ef8 f908de85 f94d0da0 f2c13c80 f94d0da0 1cd47067 c03fd1e0 b7fdffff b7fdf000 0000005b f2de4400 00000000 f2c63f28 Call Trace: [<f908aadf>] _nv001924rm+0xb/0x24 [nvidia] [<f908c44c>] rm_write_watch_init+0x54/0x78 [nvidia] [<f908d97b>] _nv001997rm+0x2b/0x770 [nvidia] [<f908de85>] _nv001997rm+0x535/0x770 [nvidia] [<f908b524>] rm_ioctl+0x1c/0x24 [nvidia] [<f9306a7e>] nv_kern_ioctl+0xae/0x330 [nvidia] [<f9306d38>] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia] [<f9306d20>] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia] [<c019178b>] vfs_ioctl+0x2b/0x90 [<c0191857>] do_vfs_ioctl+0x67/0x2e0 [<c0191b36>] sys_ioctl+0x66/0x70 [<c01050d8>] sysenter_past_esp+0x6d/0xa5 ======================= Code: 80 0d 4d f9 c3 8d 76 00 8d bc 27 00 00 00 00 f3 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 64 a1 00 b0 3f c0 8b 80 bc 04 00 00 <c7> 80 48 01 00 00 ff ff ff ff 64 a1 00 b0 3f c0 81 88 bc 01 00 EIP: [<f930957c>] os_set_mlock_capability+0xc/0x30 [nvidia] SS:ESP 0068:f2c63e9c ---[ end trace 71ca9a3959efaf65 ]---
Am Dienstag, 13. Mai 2008 05:23:37 schrieb Dan McGee:
Spoke too early. Does this mean nvidia could benefit from a recompile? I don't know if some symbols changed since the initial compile for .25. Damn xscreensaver killing my machine.
I think you need nvidia-173.08 when using kernel 2.6.25. At least this one works for me. (OK, I still get some bad caching on address warnings) -- archlinux.de
Dan McGee schrieb:
Spoke too early. Does this mean nvidia could benefit from a recompile? I don't know if some symbols changed since the initial compile for .25. Damn xscreensaver killing my machine.
BUG: unable to handle kernel NULL pointer dereference at 00000148 IP: [<f930957c>] :nvidia:os_set_mlock_capability+0xc/0x30 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ipv6 nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables sg sd_mod ext2 usb_storage scsi_mod parport_pc snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device firewire_ohci firewire_core crc_itu_t snd_intel8x0 snd_ac97_codec serio_raw ppdev snd_pcm_oss snd_mixer_oss ac97_bus snd_pcm nvidia(P) snd_timer snd lp parport ohci1394 psmouse soundcore snd_page_alloc ppp_generic slhc pcspkr ieee1394 ehci_hcd ohci_hcd shpchp pci_hotplug sis_agp agpgart thermal evdev processor fan button battery ac it87 hwmon_vid eeprom i2c_sis96x i2c_core floppy 8139too mii rtc_cmos rtc_core rtc_lib usbcore ext3 jbd mbcache ide_cd_mod cdrom ide_disk ide_pci_generic sis5513 ide_core
Pid: 17241, comm: hypnowheel Tainted: P (2.6.25-ARCH #1) EIP: 0060:[<f930957c>] EFLAGS: 00010286 CPU: 0 EIP is at os_set_mlock_capability+0xc/0x30 [nvidia] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000286 ESI: f7afc000 EDI: f7140c00 EBP: f2c63ea8 ESP: f2c63e9c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hypnowheel (pid: 17241, ti=f2c62000 task=f6f7f200 task.ti=f2c62000) Stack: f908aadf f7021280 00000006 f2c63ec8 f908c44c 0000005b f94d0da0 f2c13c80 f908d97b f7afc000 00000001 f2c63ef8 f908de85 f94d0da0 f2c13c80 f94d0da0 1cd47067 c03fd1e0 b7fdffff b7fdf000 0000005b f2de4400 00000000 f2c63f28 Call Trace: [<f908aadf>] _nv001924rm+0xb/0x24 [nvidia] [<f908c44c>] rm_write_watch_init+0x54/0x78 [nvidia] [<f908d97b>] _nv001997rm+0x2b/0x770 [nvidia] [<f908de85>] _nv001997rm+0x535/0x770 [nvidia] [<f908b524>] rm_ioctl+0x1c/0x24 [nvidia] [<f9306a7e>] nv_kern_ioctl+0xae/0x330 [nvidia] [<f9306d38>] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia] [<f9306d20>] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia] [<c019178b>] vfs_ioctl+0x2b/0x90 [<c0191857>] do_vfs_ioctl+0x67/0x2e0 [<c0191b36>] sys_ioctl+0x66/0x70 [<c01050d8>] sysenter_past_esp+0x6d/0xa5 ======================= Code: 80 0d 4d f9 c3 8d 76 00 8d bc 27 00 00 00 00 f3 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 64 a1 00 b0 3f c0 8b 80 bc 04 00 00 <c7> 80 48 01 00 00 ff ff ff ff 64 a1 00 b0 3f c0 81 88 bc 01 00 EIP: [<f930957c>] os_set_mlock_capability+0xc/0x30 [nvidia] SS:ESP 0068:f2c63e9c ---[ end trace 71ca9a3959efaf65 ]---
Apparently, these changes http://repos.archlinux.org/viewvc.cgi/kernel26/repos/testing-i686/config?r1=376&r2=1507 require rebuild of all modules. Could you test if rebuilding external modules helps?
On Tue, May 13, 2008 at 3:12 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Dan McGee schrieb:
Spoke too early. Does this mean nvidia could benefit from a recompile? I don't know if some symbols changed since the initial compile for .25. Damn xscreensaver killing my machine.
BUG: unable to handle kernel NULL pointer dereference at 00000148 IP: [<f930957c>] :nvidia:os_set_mlock_capability+0xc/0x30 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ipv6 nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables sg sd_mod ext2 usb_storage scsi_mod parport_pc snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device firewire_ohci firewire_core crc_itu_t snd_intel8x0 snd_ac97_codec serio_raw ppdev snd_pcm_oss snd_mixer_oss ac97_bus snd_pcm nvidia(P) snd_timer snd lp parport ohci1394 psmouse soundcore snd_page_alloc ppp_generic slhc pcspkr ieee1394 ehci_hcd ohci_hcd shpchp pci_hotplug sis_agp agpgart thermal evdev processor fan button battery ac it87 hwmon_vid eeprom i2c_sis96x i2c_core floppy 8139too mii rtc_cmos rtc_core rtc_lib usbcore ext3 jbd mbcache ide_cd_mod cdrom ide_disk ide_pci_generic sis5513 ide_core
Pid: 17241, comm: hypnowheel Tainted: P (2.6.25-ARCH #1) EIP: 0060:[<f930957c>] EFLAGS: 00010286 CPU: 0 EIP is at os_set_mlock_capability+0xc/0x30 [nvidia] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000286 ESI: f7afc000 EDI: f7140c00 EBP: f2c63ea8 ESP: f2c63e9c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hypnowheel (pid: 17241, ti=f2c62000 task=f6f7f200 task.ti=f2c62000) Stack: f908aadf f7021280 00000006 f2c63ec8 f908c44c 0000005b f94d0da0 f2c13c80 f908d97b f7afc000 00000001 f2c63ef8 f908de85 f94d0da0 f2c13c80 f94d0da0 1cd47067 c03fd1e0 b7fdffff b7fdf000 0000005b f2de4400 00000000 f2c63f28 Call Trace: [<f908aadf>] _nv001924rm+0xb/0x24 [nvidia] [<f908c44c>] rm_write_watch_init+0x54/0x78 [nvidia] [<f908d97b>] _nv001997rm+0x2b/0x770 [nvidia] [<f908de85>] _nv001997rm+0x535/0x770 [nvidia] [<f908b524>] rm_ioctl+0x1c/0x24 [nvidia] [<f9306a7e>] nv_kern_ioctl+0xae/0x330 [nvidia] [<f9306d38>] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia] [<f9306d20>] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia] [<c019178b>] vfs_ioctl+0x2b/0x90 [<c0191857>] do_vfs_ioctl+0x67/0x2e0 [<c0191b36>] sys_ioctl+0x66/0x70 [<c01050d8>] sysenter_past_esp+0x6d/0xa5 ======================= Code: 80 0d 4d f9 c3 8d 76 00 8d bc 27 00 00 00 00 f3 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 64 a1 00 b0 3f c0 8b 80 bc 04 00 00 <c7> 80 48 01 00 00 ff ff ff ff 64 a1 00 b0 3f c0 81 88 bc 01 00 EIP: [<f930957c>] os_set_mlock_capability+0xc/0x30 [nvidia] SS:ESP 0068:f2c63e9c ---[ end trace 71ca9a3959efaf65 ]---
Apparently, these changes http://repos.archlinux.org/viewvc.cgi/kernel26/repos/testing-i686/config?r1=376&r2=1507 require rebuild of all modules. Could you test if rebuilding external modules helps?
I rebuilt last night and did not come back to a locked machine this morning, so I think we are OK if we rebuilt modules. To Pierre- I use nvidia-96xx and not the main version, so that is definitely not the problem. And everything worked fine already for the original 2.6.25. -Dan
Dan McGee schrieb:
Apparently, these changes http://repos.archlinux.org/viewvc.cgi/kernel26/repos/testing-i686/config?r1=376&r2=1507 require rebuild of all modules. Could you test if rebuilding external modules helps?
I rebuilt last night and did not come back to a locked machine this morning, so I think we are OK if we rebuilt modules.
I already got that confirmation for the latest nvidia. Rebuilt modules are up in testing now.
To Pierre- I use nvidia-96xx and not the main version, so that is definitely not the problem. And everything worked fine already for the original 2.6.25.
nvidia 169.12 is fine on 2.6.25, execept for some annoying warnings on x86_64.
Thomas Bächler schrieb:
slmodem and martian are still broken, I didn't get to look at that yet. I think about dropping them, as probably only a handfull of people use them.
I built slmodem by disabling the slusb module (which cannot be built, because non-GPL modules cannot access to usb subsystem anymore). I have no idea if the package is still useful, but I uploaded it anyway.
participants (4)
-
Dan McGee
-
Pierre Schmitz
-
Thomas Bächler
-
Xavier