Re: Oops with 2.6.24 git when loading iwl3945
On Sun, 2 Dec 2007 19:43:16 +0300, "Cyrill Gorcunov" <[EMAIL PROTECTED]> said: > [Thomas Tuttle - Tue, Nov 27, 2007 at 03:43:57PM -0500] > | Hey. > | > | I'm using a git snapshot that gentoo distributed mere hours ago (so I'm > | fairly confident it's current), and I'm getting an Oops when I try to > | load the iwl3945 driver. I've attached it as plain text. > | > | Hope this helps, > | > | Thomas Tuttle > > Hi Thomas, > Could you please test the patch? It didn't help. The original oops says the problem was in strcmp. It was a GPF, which suggests to me that one of the arguments is NULL. Since ops->name is checked at the beginning of the function, the only other possibility is that alg->ops->name is NULL. I added a bit of code to check for this, and it turns out that one of the strings was indeed NULL. I didn't know where to go from there in debugging, but I hope it helps. Thanks, Thomas Tuttle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with 2.6.24 git when loading iwl3945
On Sun, 2 Dec 2007 19:43:16 +0300, Cyrill Gorcunov [EMAIL PROTECTED] said: [Thomas Tuttle - Tue, Nov 27, 2007 at 03:43:57PM -0500] | Hey. | | I'm using a git snapshot that gentoo distributed mere hours ago (so I'm | fairly confident it's current), and I'm getting an Oops when I try to | load the iwl3945 driver. I've attached it as plain text. | | Hope this helps, | | Thomas Tuttle Hi Thomas, Could you please test the patch? It didn't help. The original oops says the problem was in strcmp. It was a GPF, which suggests to me that one of the arguments is NULL. Since ops-name is checked at the beginning of the function, the only other possibility is that alg-ops-name is NULL. I added a bit of code to check for this, and it turns out that one of the strings was indeed NULL. I didn't know where to go from there in debugging, but I hope it helps. Thanks, Thomas Tuttle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with 2.6.24 git when loading iwl3945
Hey. I'm using a git snapshot that gentoo distributed mere hours ago (so I'm fairly confident it's current), and I'm getting an Oops when I try to load the iwl3945 driver. I've attached it as plain text. Hope this helps, Thomas Tuttle ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.17kds iwl3945: Copyright(c) 2003-2007 Intel Corporation ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device :0c:00.0 to 64 iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels general protection fault: [1] SMP CPU 0 Modules linked in: iwl3945 ieee80211_crypt_wep ieee80211_crypt mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc coretemp hwmon rtc rfcomm l2cap hci_usb bluetooth uhci_hcd ehci_hcd usbcore evdev b44 ssb psmouse Pid: 5230, comm: iwl3945/0 Not tainted 2.6.24-rc3-git2 #1 RIP: 0010:[] [] strcmp+0x0/0x1a RSP: 0018:810074d93dd8 EFLAGS: 00010287 RAX: 881c2e80 RBX: 8100752b84e0 RCX: 810074d92000 RDX: 810074de2073 RSI: 881c086b RDI: 00020074016b RBP: 881c8e80 R08: 810074d92000 R09: 810002bf77a0 R10: R11: 0001 R12: 88197540 R13: 810074de2060 R14: 810074de2030 R15: 0038 FS: () GS:8059d000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b313ecef000 CR3: 7d10 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process iwl3945/0 (pid: 5230, threadinfo 810074d92000, task 81007c812000) Stack: 88183a0e 810074d52220 810074d518c0 810074de2000 881a81e2 74d93e30 81007c812000 Call Trace: [] :mac80211:ieee80211_rate_control_register+0x3d/0xdd [] :iwl3945:iwl_bg_alive_start+0xc96/0xef9 [] thread_return+0x3d/0x81 [] :iwl3945:iwl_bg_alive_start+0x0/0xef9 [] run_workqueue+0x7f/0x10b [] worker_thread+0x0/0xe4 [] worker_thread+0xda/0xe4 [] autoremove_wake_function+0x0/0x2e [] kthread+0x47/0x75 [] child_rip+0xa/0x12 [] kthread+0x0/0x75 [] child_rip+0x0/0x12 Code: 8a 17 89 d0 2a 06 48 ff c6 84 c0 75 09 84 d2 74 05 48 ff c7 RIP [] strcmp+0x0/0x1a RSP
Oops with 2.6.24 git when loading iwl3945
Hey. I'm using a git snapshot that gentoo distributed mere hours ago (so I'm fairly confident it's current), and I'm getting an Oops when I try to load the iwl3945 driver. I've attached it as plain text. Hope this helps, Thomas Tuttle ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.17kds iwl3945: Copyright(c) 2003-2007 Intel Corporation ACPI: PCI Interrupt :0c:00.0[A] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :0c:00.0 to 64 iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels general protection fault: [1] SMP CPU 0 Modules linked in: iwl3945 ieee80211_crypt_wep ieee80211_crypt mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc coretemp hwmon rtc rfcomm l2cap hci_usb bluetooth uhci_hcd ehci_hcd usbcore evdev b44 ssb psmouse Pid: 5230, comm: iwl3945/0 Not tainted 2.6.24-rc3-git2 #1 RIP: 0010:[80300c56] [80300c56] strcmp+0x0/0x1a RSP: 0018:810074d93dd8 EFLAGS: 00010287 RAX: 881c2e80 RBX: 8100752b84e0 RCX: 810074d92000 RDX: 810074de2073 RSI: 881c086b RDI: 00020074016b RBP: 881c8e80 R08: 810074d92000 R09: 810002bf77a0 R10: R11: 0001 R12: 88197540 R13: 810074de2060 R14: 810074de2030 R15: 0038 FS: () GS:8059d000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b313ecef000 CR3: 7d10 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process iwl3945/0 (pid: 5230, threadinfo 810074d92000, task 81007c812000) Stack: 88183a0e 810074d52220 810074d518c0 810074de2000 881a81e2 74d93e30 81007c812000 Call Trace: [88183a0e] :mac80211:ieee80211_rate_control_register+0x3d/0xdd [881a81e2] :iwl3945:iwl_bg_alive_start+0xc96/0xef9 [80439984] thread_return+0x3d/0x81 [881a754c] :iwl3945:iwl_bg_alive_start+0x0/0xef9 [80242755] run_workqueue+0x7f/0x10b [80243071] worker_thread+0x0/0xe4 [8024314b] worker_thread+0xda/0xe4 [802460c0] autoremove_wake_function+0x0/0x2e [80245fae] kthread+0x47/0x75 [8020cc48] child_rip+0xa/0x12 [80245f67] kthread+0x0/0x75 [8020cc3e] child_rip+0x0/0x12 Code: 8a 17 89 d0 2a 06 48 ff c6 84 c0 75 09 84 d2 74 05 48 ff c7 RIP [80300c56] strcmp+0x0/0x1a RSP 810074d93dd8
Re: SAK and screen readers
On December 05 at 18:50 EST, Samuel Thibault hastily scribbled: > The problem comes when using SAK: brltty gets killed because it owns an > fd on /dev/tty0. This is a problem since the blind user then just can't > use her computer any more... > > Could there be a solution for brltty yet not being killed by SAK? (like > letting brltty just nicely close his fd for the current VT, and then > re-open it later) How about this? brltty launches a child process that opens the VT and pipes data back and forth to the parent process via pipes or fifos. When the SAK is pressed, the child process will die, and the parent process will simply relaunch it. It seems like any solution that involves the kernel not killing brltty will compromise the (admittedly rudimentary) security that the SAK offers. Hope this helps, Thomas Tuttle pgpqKt5QkLY0v.pgp Description: PGP signature
Re: SAK and screen readers
On December 05 at 18:50 EST, Samuel Thibault hastily scribbled: The problem comes when using SAK: brltty gets killed because it owns an fd on /dev/tty0. This is a problem since the blind user then just can't use her computer any more... snip Could there be a solution for brltty yet not being killed by SAK? (like letting brltty just nicely close his fd for the current VT, and then re-open it later) How about this? brltty launches a child process that opens the VT and pipes data back and forth to the parent process via pipes or fifos. When the SAK is pressed, the child process will die, and the parent process will simply relaunch it. It seems like any solution that involves the kernel not killing brltty will compromise the (admittedly rudimentary) security that the SAK offers. Hope this helps, Thomas Tuttle pgpqKt5QkLY0v.pgp Description: PGP signature
Re: 2.6.19-rc6-mm2
I've found a couple of bugs so far... 1. I did `modprobe kvm' and then tried running a version of the KVM Qemu compiled for a different kernel. My mistake. But I got an oops: BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: f91f9c3f *pde = Oops: [#1] SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_max_freq Modules linked in: kvm iTCO_wdt i8k rfcomm l2cap rtc sdhci mmc_block mmc_core hci_usb bluetooth b44 mii ohci1394 ieee1394 uhci_hcd ehci_hcd usbcore psmouse evdev i915 drm cpuid msr speedstep_centrino video thermal processor fan container button battery ac CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.19-rc6-mm1 #1) EIP is at kvm_vmx_return+0xef/0x4d0 [kvm] eax: e5490068 ebx: ecx: edx: e5491ca4 esi: edi: e5490060 ebp: e5a4fde0 esp: e5a4fd54 ds: 007b es: 007b ss: 0068 Process qemu (pid: 24193, ti=e5a4e000 task=c2286a90 task.ti=e5a4e000) Stack: 0002 0001 f7fe1278 0002 b7f92000 e549 e5a4fdac 00d8 f783a580 e5a4fdac c043b98a bfb93f7c f91fa020 e5a4fde0 bfb93f7c bfb93f7c f91fa0cb 04f3 c03fb974 e549 Call Trace: [] kvm_dev_ioctl+0x0/0x1040 [kvm] [] kvm_dev_ioctl+0xab/0x1040 [kvm] [] error_code+0x7c/0x84 [] kmap_atomic+0xc9/0xe0 [] permission+0x2b/0xd0 [] sys_swapon+0x978/0xaf0 [] kunmap_atomic+0x63/0x70 [] kmap_atomic+0xc9/0xe0 [] kunmap_atomic+0x63/0x70 [] get_page_from_freelist+0x27d/0x340 [] kmap_atomic+0xc9/0xe0 [] kunmap_atomic+0x63/0x70 [] get_page_from_freelist+0x27d/0x340 [] find_get_page+0x20/0x60 [] filemap_nopage+0x2dc/0x490 [] do_sync_read+0xc7/0x110 [] kmap_atomic+0xc9/0xe0 [] kunmap_atomic+0x63/0x70 [] __handle_mm_fault+0x246/0x9c0 [] kvm_dev_ioctl+0x0/0x1040 [kvm] [] scsi_host_alloc+0x202/0x2a0 [] do_ioctl+0x2b/0x90 [] vfs_ioctl+0x5c/0x2b0 [] sys_ioctl+0x3d/0x70 [] syscall_call+0x7/0xb [] scsi_host_alloc+0x202/0x2a0 === Code: 14 0f 87 77 02 00 00 8b 0c b5 00 15 20 f9 85 c9 0f 84 68 02 00 00 89 ea 89 f8 ff d1 85 c0 0f 84 4c 02 00 00 89 f8 e8 31 e9 ff ff <65> a1 08 00 00 00 8b 40 04 8b 40 08 a8 04 0f 85 ae 02 00 00 e8 EIP: [] kvm_vmx_return+0xef/0x4d0 [kvm] SS:ESP 0068:e5a4fd54 msrs: 2 Oh, and I get a ton of these messages with kvm: rtc: lost some interrupts at 1024Hz. 2. I'm not sure if this bug is in the kernel, wireless tools, or the ipw3945 driver, but I haven't changed the version of anything but the kernel. When I do `iwconfig eth1 essid foobar' something drops the last character of the essid, and a subsequent `iwconfig eth1' shows "fooba" as the essid. And it's actually set as "fooba", since I had to do `iwconfig eth1 essid MyUsualEssid_' (note underscore) to get on to my usual network. --Thomas Tuttle pgpEvsWJPAyNU.pgp Description: PGP signature
Re: 2.6.19-rc6-mm2
I've found a couple of bugs so far... 1. I did `modprobe kvm' and then tried running a version of the KVM Qemu compiled for a different kernel. My mistake. But I got an oops: BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: f91f9c3f *pde = Oops: [#1] SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_max_freq Modules linked in: kvm iTCO_wdt i8k rfcomm l2cap rtc sdhci mmc_block mmc_core hci_usb bluetooth b44 mii ohci1394 ieee1394 uhci_hcd ehci_hcd usbcore psmouse evdev i915 drm cpuid msr speedstep_centrino video thermal processor fan container button battery ac CPU:0 EIP:0060:[f91f9c3f]Not tainted VLI EFLAGS: 00010202 (2.6.19-rc6-mm1 #1) EIP is at kvm_vmx_return+0xef/0x4d0 [kvm] eax: e5490068 ebx: ecx: edx: e5491ca4 esi: edi: e5490060 ebp: e5a4fde0 esp: e5a4fd54 ds: 007b es: 007b ss: 0068 Process qemu (pid: 24193, ti=e5a4e000 task=c2286a90 task.ti=e5a4e000) Stack: 0002 0001 f7fe1278 0002 b7f92000 e549 e5a4fdac 00d8 f783a580 e5a4fdac c043b98a bfb93f7c f91fa020 e5a4fde0 bfb93f7c bfb93f7c f91fa0cb 04f3 c03fb974 e549 Call Trace: [f91fa020] kvm_dev_ioctl+0x0/0x1040 [kvm] [f91fa0cb] kvm_dev_ioctl+0xab/0x1040 [kvm] [c03fb974] error_code+0x7c/0x84 [c011d469] kmap_atomic+0xc9/0xe0 [c018007b] permission+0x2b/0xd0 [c01700d8] sys_swapon+0x978/0xaf0 [c011d263] kunmap_atomic+0x63/0x70 [c011d469] kmap_atomic+0xc9/0xe0 [c011d263] kunmap_atomic+0x63/0x70 [c015cdbd] get_page_from_freelist+0x27d/0x340 [c011d469] kmap_atomic+0xc9/0xe0 [c011d263] kunmap_atomic+0x63/0x70 [c015cdbd] get_page_from_freelist+0x27d/0x340 [c0157af0] find_get_page+0x20/0x60 [c015a75c] filemap_nopage+0x2dc/0x490 [c0178a47] do_sync_read+0xc7/0x110 [c011d469] kmap_atomic+0xc9/0xe0 [c011d263] kunmap_atomic+0x63/0x70 [c0166386] __handle_mm_fault+0x246/0x9c0 [f91fa020] kvm_dev_ioctl+0x0/0x1040 [kvm] [c030ae02] scsi_host_alloc+0x202/0x2a0 [c018430b] do_ioctl+0x2b/0x90 [c01843cc] vfs_ioctl+0x5c/0x2b0 [c018465d] sys_ioctl+0x3d/0x70 [c0103238] syscall_call+0x7/0xb [c030ae02] scsi_host_alloc+0x202/0x2a0 === Code: 14 0f 87 77 02 00 00 8b 0c b5 00 15 20 f9 85 c9 0f 84 68 02 00 00 89 ea 89 f8 ff d1 85 c0 0f 84 4c 02 00 00 89 f8 e8 31 e9 ff ff 65 a1 08 00 00 00 8b 40 04 8b 40 08 a8 04 0f 85 ae 02 00 00 e8 EIP: [f91f9c3f] kvm_vmx_return+0xef/0x4d0 [kvm] SS:ESP 0068:e5a4fd54 msrs: 2 Oh, and I get a ton of these messages with kvm: rtc: lost some interrupts at 1024Hz. 2. I'm not sure if this bug is in the kernel, wireless tools, or the ipw3945 driver, but I haven't changed the version of anything but the kernel. When I do `iwconfig eth1 essid foobar' something drops the last character of the essid, and a subsequent `iwconfig eth1' shows fooba as the essid. And it's actually set as fooba, since I had to do `iwconfig eth1 essid MyUsualEssid_' (note underscore) to get on to my usual network. --Thomas Tuttle pgpEvsWJPAyNU.pgp Description: PGP signature
ACPI patch submission (was: [PATCH] Implementation of acpi_video_get_next_level)
I've got a patch that fixes acpi_video_get_next_level in the ACPI video driver. I sent it to linux-kernel, linux-acpi, and some people at Intel. It's a very short and simple patch that fixes the brightness hotkeys on my laptop, and probably others. (The function it fixes had /* Fix me */ written in it.) Where or how should I send this patch so that it can be included in the mainline kernel? Thanks, Thomas Tuttle pgpSPz1j36M0q.pgp Description: PGP signature
ACPI patch submission (was: [PATCH] Implementation of acpi_video_get_next_level)
I've got a patch that fixes acpi_video_get_next_level in the ACPI video driver. I sent it to linux-kernel, linux-acpi, and some people at Intel. It's a very short and simple patch that fixes the brightness hotkeys on my laptop, and probably others. (The function it fixes had /* Fix me */ written in it.) Where or how should I send this patch so that it can be included in the mainline kernel? Thanks, Thomas Tuttle pgpSPz1j36M0q.pgp Description: PGP signature
