* BUG: unable to handle kernel NULL pointer dereference at 00000002 @ 2012-06-14 17:45 Pierre-Philipp Braun 0 siblings, 0 replies; 14+ messages in thread From: Pierre-Philipp Braun @ 2012-06-14 17:45 UTC (permalink / raw) To: mchehab; +Cc: linux-media [-- Attachment #1: Type: text/plain, Size: 1680 bytes --] Hi, When I plug my USB IR receiver (MCE) in, I get the error and trace messages hereby attached. It doesn't freeze the system but when I try to boot the machine with the USB receiver plugged in, it actually prevents the system to boot entirely. I've configured a 2.6.39.4 kernel with those drivers built-in, CONFIG_RC_MAP=y CONFIG_IR_RC6_DECODER CONFIG_IR_MCEUSB=y I'm basically using the default configuration + EXT4 + BRIDGE + NTFS + NFSD + FUSE + DRM_RADEON & firmware, nothing funky (and cpu family opteron). Here's the error I got in brief (from dmesg), mceusb 3-2:1.0: usb_probe_interface mceusb 3-2:1.0: usb_probe_interface - got id Registered IR keymap rc-rc6-mce input: Media Center Ed. eHome Infrared Remote Transceiver (0471:2088) as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/rc/rc0/input4 rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:2088) as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/rc/rc0 BUG: unable to handle kernel NULL pointer dereference at 00000002 IP: [<c13911e0>] mce_request_packet+0x6d/0x11f *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/usb3/3-2/manufacturer Modules linked in: Pid: 436, comm: khubd Not tainted 2.6.39.4 #4 System manufacturer System Product Name/M5A78L-M/USB3 EIP: 0060:[<c13911e0>] EFLAGS: 00010286 CPU: 1 EIP is at mce_request_packet+0x6d/0x11f ... (see attached file) ... My kernel, Linux version 2.6.39.4 (elge@h2) (gcc version 4.5.2 (GCC) ) #4 SMP Thu Jun 14 21:00:23 CEST 2012 no modules loaded System is Slackware 13.37 (32-bit version) CPU description attached. Some help will be greately appreciated. Thanks. Pierre-Philipp [-- Attachment #2: remote.log --] [-- Type: text/plain, Size: 7861 bytes --] Jun 14 21:02:16 h2 kernel: [ 34.381608] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0004 Jun 14 21:02:16 h2 kernel: [ 34.381616] ehci_hcd 0000:00:12.2: GetStatus port:2 status 001403 0 ACK POWER sig=k CSC CONNECT Jun 14 21:02:16 h2 kernel: [ 34.381623] hub 1-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Jun 14 21:02:16 h2 kernel: [ 34.485026] hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Jun 14 21:02:16 h2 kernel: [ 34.485033] ehci_hcd 0000:00:12.2: port 2 low speed --> companion Jun 14 21:02:16 h2 kernel: [ 34.485066] ohci_hcd 0000:00:12.0: auto-wakeup root hub Jun 14 21:02:16 h2 kernel: [ 34.536031] ehci_hcd 0000:00:12.2: GetStatus port:2 status 003002 0 ACK POWER OWNER sig=se0 CSC Jun 14 21:02:16 h2 kernel: [ 34.536049] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0004 Jun 14 21:02:16 h2 kernel: [ 34.536052] hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0004 Jun 14 21:02:16 h2 kernel: [ 34.536057] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS Jun 14 21:02:16 h2 kernel: [ 34.536060] hub 3-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s Jun 14 21:02:16 h2 kernel: [ 34.640027] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 Jun 14 21:02:16 h2 kernel: [ 34.702024] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS Jun 14 21:02:16 h2 kernel: [ 34.753030] usb 3-2: new low speed USB device number 2 using ohci_hcd Jun 14 21:02:16 h2 kernel: [ 34.816031] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS Jun 14 21:02:16 h2 kernel: [ 34.887078] usb 3-2: skipped 1 descriptor after interface Jun 14 21:02:16 h2 kernel: [ 34.889081] usb 3-2: default language 0x0409 Jun 14 21:02:16 h2 kernel: [ 34.896088] usb 3-2: udev 2, busnum 3, minor = 257 Jun 14 21:02:16 h2 kernel: [ 34.896090] usb 3-2: New USB device found, idVendor=0471, idProduct=2088 Jun 14 21:02:16 h2 kernel: [ 34.896092] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jun 14 21:02:16 h2 kernel: [ 34.896095] usb 3-2: Product: MCE USB IR Receiver with ALS- Spinel plus for ASUS Jun 14 21:02:16 h2 kernel: [ 34.896096] usb 3-2: Manufacturer: PHILIPS Jun 14 21:02:16 h2 kernel: [ 34.896155] usb 3-2: usb_probe_device Jun 14 21:02:16 h2 kernel: [ 34.896158] usb 3-2: configuration #1 chosen from 1 choice Jun 14 21:02:16 h2 kernel: [ 34.898087] usb 3-2: adding 3-2:1.0 (config #1, interface 0) Jun 14 21:02:16 h2 kernel: [ 34.898117] mceusb 3-2:1.0: usb_probe_interface Jun 14 21:02:16 h2 kernel: [ 34.898119] mceusb 3-2:1.0: usb_probe_interface - got id Jun 14 21:02:16 h2 kernel: [ 34.905086] Registered IR keymap rc-rc6-mce Jun 14 21:02:16 h2 kernel: [ 34.905152] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:2088) as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/rc/rc0/input4 Jun 14 21:02:16 h2 kernel: [ 34.905171] rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:2088) as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/rc/rc0 Jun 14 21:02:16 h2 kernel: [ 34.905200] BUG: unable to handle kernel NULL pointer dereference at 00000002 Jun 14 21:02:16 h2 kernel: [ 34.905303] IP: [<c13911e0>] mce_request_packet+0x6d/0x11f Jun 14 21:02:16 h2 kernel: [ 34.905384] *pde = 00000000 Jun 14 21:02:16 h2 kernel: [ 34.905429] Oops: 0000 [#1] SMP Jun 14 21:02:16 h2 kernel: [ 34.905485] last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/usb3/3-2/manufacturer Jun 14 21:02:16 h2 kernel: [ 34.905588] Modules linked in: Jun 14 21:02:16 h2 kernel: [ 34.906193] Jun 14 21:02:16 h2 kernel: [ 34.906193] Pid: 436, comm: khubd Not tainted 2.6.39.4 #4 System manufacturer System Product Name/M5A78L-M/USB3 Jun 14 21:02:16 h2 kernel: [ 34.906193] EIP: 0060:[<c13911e0>] EFLAGS: 00010286 CPU: 1 Jun 14 21:02:16 h2 kernel: [ 34.906193] EIP is at mce_request_packet+0x6d/0x11f Jun 14 21:02:16 h2 kernel: [ 34.906193] EAX: f4b95c00 EBX: f2f34c00 ECX: 00000003 EDX: 000080d0 Jun 14 21:02:16 h2 kernel: [ 34.906193] ESI: f4b97e1c EDI: 00000000 EBP: f5531c2c ESP: f5531c14 Jun 14 21:02:16 h2 kernel: [ 34.906193] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Jun 14 21:02:16 h2 kernel: [ 34.906193] Process khubd (pid: 436, ti=f5530000 task=f5607020 task.ti=f5530000) Jun 14 21:02:16 h2 kernel: [ 34.906193] Stack: Jun 14 21:02:16 h2 kernel: [ 34.906193] c178cb88 f4858b00 f4b95c00 c178cb88 f2fe2000 00000008 f5531c40 c13912a5 Jun 14 21:02:16 h2 kernel: [ 34.906193] 00000003 00000002 f4b95c00 f5531d44 c150583d 00000471 f4b05e00 00531c60 Jun 14 21:02:16 h2 kernel: [ 34.906193] f4b97e1c 00012928 f2fe2064 f4b97e00 f4b95c41 00000008 f4b95cc1 f4b97e1c Jun 14 21:02:16 h2 kernel: [ 34.906193] Call Trace: Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c13912a5>] mce_async_out+0x13/0x1a Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c150583d>] mceusb_dev_probe+0x64e/0x7ae Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c135bda3>] usb_probe_interface+0xe2/0x11c Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c73b3>] driver_probe_device+0x81/0xf9 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c74b4>] __device_attach+0x2a/0x2e Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c66d4>] bus_for_each_drv+0x3d/0x67 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c7294>] device_attach+0x47/0x5b Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c748a>] ? __driver_attach+0x5f/0x5f Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c6d89>] bus_probe_device+0x18/0x2d Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c5a43>] device_add+0x347/0x486 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c135b2cd>] ? usb_set_configuration+0x457/0x4ad Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c135b2e5>] usb_set_configuration+0x46f/0x4ad Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1360975>] generic_probe+0x41/0x68 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c135b4ad>] usb_probe_device+0x28/0x2f Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c73b3>] driver_probe_device+0x81/0xf9 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c74b4>] __device_attach+0x2a/0x2e Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c66d4>] bus_for_each_drv+0x3d/0x67 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c7294>] device_attach+0x47/0x5b Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c748a>] ? __driver_attach+0x5f/0x5f Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c6d89>] bus_probe_device+0x18/0x2d Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c12c5a43>] device_add+0x347/0x486 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c13535ca>] ? show_string+0x1c/0x21 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1355cd7>] ? usb_new_device+0xe7/0x13c Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1355cf4>] usb_new_device+0x104/0x13c Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c13565a6>] hub_thread+0x87a/0xc80 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1044686>] ? wake_up_bit+0x1b/0x1b Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1355d2c>] ? usb_new_device+0x13c/0x13c Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c1044355>] kthread+0x62/0x67 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c10442f3>] ? kthread_worker_fn+0x107/0x107 Jun 14 21:02:16 h2 kernel: [ 34.906193] [<c15182f6>] kernel_thread_helper+0x6/0xd Jun 14 21:02:16 h2 kernel: [ 34.906193] Code: 8b 45 08 e8 a7 ff ff ff 85 c0 89 45 ec 75 19 68 71 45 6f c1 56 e8 b5 39 f3 ff 89 d8 e8 04 84 fc ff 5b 5e e9 ad 00 00 00 8b 45 f0 <0f> b6 77 02 0f b6 4f 06 8b 50 0c c1 e6 0f 8b 02 89 53 28 c7 43 Jun 14 21:02:16 h2 kernel: [ 34.906193] EIP: [<c13911e0>] mce_request_packet+0x6d/0x11f SS:ESP 0068:f5531c14 Jun 14 21:02:16 h2 kernel: [ 34.906193] CR2: 0000000000000002 Jun 14 21:02:16 h2 kernel: [ 35.052760] ---[ end trace cd83e3973fe4df54 ]--- Jun 14 21:02:16 h2 kernel: [ 35.055337] khubd used greatest stack depth: 5796 bytes left [-- Attachment #3: cpuinfo --] [-- Type: text/plain, Size: 2115 bytes --] processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X2 550 Processor stepping : 2 cpu MHz : 3114.260 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr npt lbrv svm_lock nrip_save bogomips : 6228.52 clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X2 550 Processor stepping : 2 cpu MHz : 3114.260 cache size : 512 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr npt lbrv svm_lock nrip_save bogomips : 6228.17 clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [-- Attachment #4: .config --] [-- Type: application/xml, Size: 76746 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* BUG: unable to handle kernel NULL pointer dereference at 00000002 @ 2008-07-25 9:53 Aneesh Kumar K.V 2008-07-28 22:26 ` Frederik Deweerdt 0 siblings, 1 reply; 14+ messages in thread From: Aneesh Kumar K.V @ 2008-07-25 9:53 UTC (permalink / raw) To: linux-kernel@vger.kernel.org [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 [ 163.378288] *pde = 00000000 [ 163.378294] Oops: 0000 [#1] SMP [ 163.378301] Modules linked in: ipv6 usbhid hid radeon drm rfcomm l2cap bluetooth kvm_intel kvm uinput ppdev autofs4 acpi_cpufreq cpufreq_conservative cpufreq_userspace c pufreq_ondemand cpufreq_stats freq_table cpufreq_powersave sbs sbshc container iptable_filter ip_tables x_tables dm_crypt dm_mod parport_pc lp parport joydev pcmcia iTCO_wd t serio_raw yenta_socket iTCO_vendor_support rsrc_nonstatic arc4 psmouse pcspkr ecb crypto_blkcipher pcmcia_core ac battery iwl3945 rfkill mac80211 cfg80211 snd_hda_intel e 1000e video output snd_pcm snd_timer snd soundcore snd_page_alloc button shpchp pci_hotplug intel_agp agpgart thinkpad_acpi led_class nvram evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi ata_piix ahci ehci_hcd uhci_hcd libata scsi_mod usbcore dock thermal processor fan thermal_sys fuse [ 163.378431] [ 163.378436] Pid: 6456, comm: sched-powersave Not tainted (2.6.26-00149-gc8988f9-dirty #6) [ 163.378442] EIP: 0060:[<c0124933>] EFLAGS: 00010282 CPU: 0 [ 163.378448] EIP is at sched_power_savings_store+0x13/0x70 [ 163.378453] EAX: 00000002 EBX: 00000000 ECX: ffffffea EDX: f480a480 [ 163.378458] ESI: f480a480 EDI: f69a1000 EBP: c0430464 ESP: f6b15f40 [ 163.378463] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 163.378468] Process sched-powersave (pid: 6456, ti=f6b14000 task=f6ad3720 task.ti=f6b14000) [ 163.378473] Stack: c01249a0 c0430464 c027e329 f480a480 c0430158 00000002 c01d8ca1 00000002 [ 163.378487] f6ae8000 f69ae314 c0430158 f6ae8000 080fc408 c01d8be0 00000002 c0191c3f [ 163.378501] f6b15fa0 f6ae8000 f6ae8000 fffffff7 080fc408 f6b14000 c0192241 f6b15fa0 [ 163.378515] Call Trace: [ 163.378519] [<c01249a0>] sched_mc_power_savings_store+0x0/0x10 [ 163.378527] [<c027e329>] sysdev_class_store+0x29/0x40 [ 163.378537] [<c01d8ca1>] sysfs_write_file+0xc1/0x110 [ 163.378546] [<c01d8be0>] sysfs_write_file+0x0/0x110 [ 163.378553] [<c0191c3f>] vfs_write+0x9f/0x170 [ 163.378561] [<c0192241>] sys_write+0x41/0x70 [ 163.378568] [<c0103d6f>] sysenter_past_esp+0x78/0xb9 [ 163.378575] [<c0320000>] set_cpu_sibling_map+0x1e0/0x2a0 [ 163.378584] ======================= [ 163.378587] Code: ff 89 c3 b8 08 ed 41 c0 e8 5b ef 1f 00 e8 26 66 00 00 89 d8 5b c3 66 90 83 ec 08 89 1c 24 89 cb b9 ea ff ff ff 89 74 24 04 89 d6 <0f> b6 10 8d 42 d0 3c 01 76 13 8b 1c 24 89 c8 8b 74 24 04 83 c4 [ 163.378662] EIP: [<c0124933>] sched_power_savings_store+0x13/0x70 SS:ESP 0068:f6b15f40 [ 163.378673] ---[ end trace 90dd601c24cdd750 ]--- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-25 9:53 Aneesh Kumar K.V @ 2008-07-28 22:26 ` Frederik Deweerdt 2008-07-29 4:22 ` Mike Galbraith 0 siblings, 1 reply; 14+ messages in thread From: Frederik Deweerdt @ 2008-07-28 22:26 UTC (permalink / raw) To: Aneesh Kumar K.V; +Cc: linux-kernel@vger.kernel.org, suresh.b.siddha Hello Aneesh, On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 Does the attached patch solve the problem? Regards, Frederik diff --git a/kernel/sched.c b/kernel/sched.c index 0047bd9..090b397 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -7643,34 +7643,30 @@ static ssize_t sched_power_savings_store(const char *buf, size_t count, int smt) } #ifdef CONFIG_SCHED_MC -static ssize_t sched_mc_power_savings_show(struct sys_device *dev, - struct sysdev_attribute *attr, char *page) +static ssize_t sched_mc_power_savings_show(struct sysdev_class *cls, char *page) { return sprintf(page, "%u\n", sched_mc_power_savings); } -static ssize_t sched_mc_power_savings_store(struct sys_device *dev, - struct sysdev_attribute *attr, +static ssize_t sched_mc_power_savings_store(struct sysdev_class *cls, const char *buf, size_t count) { return sched_power_savings_store(buf, count, 0); } -static SYSDEV_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show, +static SYSDEV_CLASS_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show, sched_mc_power_savings_store); #endif #ifdef CONFIG_SCHED_SMT -static ssize_t sched_smt_power_savings_show(struct sys_device *dev, - struct sysdev_attribute *attr, char *page) +static ssize_t sched_smt_power_savings_show(struct sysdev_class *cls, char *page) { return sprintf(page, "%u\n", sched_smt_power_savings); } -static ssize_t sched_smt_power_savings_store(struct sys_device *dev, - struct sysdev_attribute *attr, +static ssize_t sched_smt_power_savings_store(struct sysdev_class *cls, const char *buf, size_t count) { return sched_power_savings_store(buf, count, 1); } -static SYSDEV_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show, +static SYSDEV_CLASS_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show, sched_smt_power_savings_store); #endif @@ -7680,13 +7676,13 @@ int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls) #ifdef CONFIG_SCHED_SMT if (smt_capable()) - err = sysfs_create_file(&cls->kset.kobj, - &attr_sched_smt_power_savings.attr); + err = sysdev_class_create_file(cls, + &attr_sched_smt_power_savings); #endif #ifdef CONFIG_SCHED_MC if (!err && mc_capable()) - err = sysfs_create_file(&cls->kset.kobj, - &attr_sched_mc_power_savings.attr); + err = sysdev_class_create_file(cls, + &attr_sched_mc_power_savings); #endif return err; } ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-28 22:26 ` Frederik Deweerdt @ 2008-07-29 4:22 ` Mike Galbraith 2008-07-29 12:09 ` Andi Kleen 2008-07-30 9:05 ` Ingo Molnar 0 siblings, 2 replies; 14+ messages in thread From: Mike Galbraith @ 2008-07-29 4:22 UTC (permalink / raw) To: Frederik Deweerdt Cc: Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar, Andi Kleen On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > Hello Aneesh, > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 > > Does the attached patch solve the problem? Patch seems to have missed the boat for rc1 too. > > Regards, > Frederik > > diff --git a/kernel/sched.c b/kernel/sched.c > index 0047bd9..090b397 100644 > --- a/kernel/sched.c > +++ b/kernel/sched.c > @@ -7643,34 +7643,30 @@ static ssize_t sched_power_savings_store(const char *buf, size_t count, int smt) > } > > #ifdef CONFIG_SCHED_MC > -static ssize_t sched_mc_power_savings_show(struct sys_device *dev, > - struct sysdev_attribute *attr, char *page) > +static ssize_t sched_mc_power_savings_show(struct sysdev_class *cls, char *page) > { > return sprintf(page, "%u\n", sched_mc_power_savings); > } > -static ssize_t sched_mc_power_savings_store(struct sys_device *dev, > - struct sysdev_attribute *attr, > +static ssize_t sched_mc_power_savings_store(struct sysdev_class *cls, > const char *buf, size_t count) > { > return sched_power_savings_store(buf, count, 0); > } > -static SYSDEV_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show, > +static SYSDEV_CLASS_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show, > sched_mc_power_savings_store); > #endif > > #ifdef CONFIG_SCHED_SMT > -static ssize_t sched_smt_power_savings_show(struct sys_device *dev, > - struct sysdev_attribute *attr, char *page) > +static ssize_t sched_smt_power_savings_show(struct sysdev_class *cls, char *page) > { > return sprintf(page, "%u\n", sched_smt_power_savings); > } > -static ssize_t sched_smt_power_savings_store(struct sys_device *dev, > - struct sysdev_attribute *attr, > +static ssize_t sched_smt_power_savings_store(struct sysdev_class *cls, > const char *buf, size_t count) > { > return sched_power_savings_store(buf, count, 1); > } > -static SYSDEV_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show, > +static SYSDEV_CLASS_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show, > sched_smt_power_savings_store); > #endif > > @@ -7680,13 +7676,13 @@ int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls) > > #ifdef CONFIG_SCHED_SMT > if (smt_capable()) > - err = sysfs_create_file(&cls->kset.kobj, > - &attr_sched_smt_power_savings.attr); > + err = sysdev_class_create_file(cls, > + &attr_sched_smt_power_savings); > #endif > #ifdef CONFIG_SCHED_MC > if (!err && mc_capable()) > - err = sysfs_create_file(&cls->kset.kobj, > - &attr_sched_mc_power_savings.attr); > + err = sysdev_class_create_file(cls, > + &attr_sched_mc_power_savings); > #endif > return err; > } ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 4:22 ` Mike Galbraith @ 2008-07-29 12:09 ` Andi Kleen 2008-07-29 13:56 ` Arjan van de Ven 2008-07-30 9:05 ` Ingo Molnar 1 sibling, 1 reply; 14+ messages in thread From: Andi Kleen @ 2008-07-29 12:09 UTC (permalink / raw) To: Mike Galbraith Cc: Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar, Andi Kleen On Tue, Jul 29, 2008 at 06:22:15AM +0200, Mike Galbraith wrote: > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > Hello Aneesh, > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > > > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 > > > > Does the attached patch solve the problem? > > Patch seems to have missed the boat for rc1 too. Hmm. I'll resend. BTW i think it's clearly a bug that distributions are even accessing that file. It doesn't make any sense in the context they are using it (like at every boot). -Andi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 12:09 ` Andi Kleen @ 2008-07-29 13:56 ` Arjan van de Ven 2008-07-29 14:53 ` Andi Kleen 0 siblings, 1 reply; 14+ messages in thread From: Arjan van de Ven @ 2008-07-29 13:56 UTC (permalink / raw) To: Andi Kleen Cc: Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar, Andi Kleen On Tue, 29 Jul 2008 14:09:11 +0200 Andi Kleen <andi@firstfloor.org> wrote: > On Tue, Jul 29, 2008 at 06:22:15AM +0200, Mike Galbraith wrote: > > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > > Hello Aneesh, > > > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > > [ 163.378265] BUG: unable to handle kernel NULL pointer > > > > dereference at 00000002 [ 163.378276] IP: [<c0124933>] > > > > sched_power_savings_store+0x13/0x70 > > > > > > Does the attached patch solve the problem? > > > > Patch seems to have missed the boat for rc1 too. > > Hmm. I'll resend. > > BTW i think it's clearly a bug that distributions are even accessing > that file. It doesn't make any sense in the context they are using > it (like at every boot). it's a power saving feature that they very likely turn on by default... -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 13:56 ` Arjan van de Ven @ 2008-07-29 14:53 ` Andi Kleen 2008-07-29 15:30 ` Arjan van de Ven 0 siblings, 1 reply; 14+ messages in thread From: Andi Kleen @ 2008-07-29 14:53 UTC (permalink / raw) To: Arjan van de Ven Cc: Andi Kleen, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar On Tue, Jul 29, 2008 at 06:56:35AM -0700, Arjan van de Ven wrote: > On Tue, 29 Jul 2008 14:09:11 +0200 > Andi Kleen <andi@firstfloor.org> wrote: > > > On Tue, Jul 29, 2008 at 06:22:15AM +0200, Mike Galbraith wrote: > > > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > > > Hello Aneesh, > > > > > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > > > [ 163.378265] BUG: unable to handle kernel NULL pointer > > > > > dereference at 00000002 [ 163.378276] IP: [<c0124933>] > > > > > sched_power_savings_store+0x13/0x70 > > > > > > > > Does the attached patch solve the problem? > > > > > > Patch seems to have missed the boat for rc1 too. > > > > Hmm. I'll resend. > > > > BTW i think it's clearly a bug that distributions are even accessing > > that file. It doesn't make any sense in the context they are using > > it (like at every boot). > > it's a power saving feature that they very likely turn on by default... A power saving feature that has a significant trade off between power and performance. This means performance will go down. Perhaps it would be ok on battery, but it's a feature that only makes sense on servers which don't have batteries. So enabling it by default in a standard installation seems quite wrong to me. BTW opensuse seems to even set it to 2 which doesn't even exist. This means there was a BOF at OLS discussing adding more modes, but right now there is only 0 or 1. -Andi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 14:53 ` Andi Kleen @ 2008-07-29 15:30 ` Arjan van de Ven 2008-07-29 16:31 ` Andi Kleen 0 siblings, 1 reply; 14+ messages in thread From: Arjan van de Ven @ 2008-07-29 15:30 UTC (permalink / raw) To: Andi Kleen Cc: Andi Kleen, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar On Tue, 29 Jul 2008 16:53:48 +0200 Andi Kleen <andi@firstfloor.org> wrote: > On Tue, Jul 29, 2008 at 06:56:35AM -0700, Arjan van de Ven wrote: > > On Tue, 29 Jul 2008 14:09:11 +0200 > > Andi Kleen <andi@firstfloor.org> wrote: > > > > > On Tue, Jul 29, 2008 at 06:22:15AM +0200, Mike Galbraith wrote: > > > > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > > > > Hello Aneesh, > > > > > > > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V > > > > > wrote: > > > > > > [ 163.378265] BUG: unable to handle kernel NULL pointer > > > > > > dereference at 00000002 [ 163.378276] IP: [<c0124933>] > > > > > > sched_power_savings_store+0x13/0x70 > > > > > > > > > > Does the attached patch solve the problem? > > > > > > > > Patch seems to have missed the boat for rc1 too. > > > > > > Hmm. I'll resend. > > > > > > BTW i think it's clearly a bug that distributions are even > > > accessing that file. It doesn't make any sense in the context > > > they are using it (like at every boot). > > > > it's a power saving feature that they very likely turn on by > > default... > > A power saving feature that has a significant trade off between power > and performance. do you have numbers to explain "significant tradeoff" ? > This means performance will go down. Perhaps it would be ok on > battery, the illusion that power only matters on battery got buried a few years ago ;) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 15:30 ` Arjan van de Ven @ 2008-07-29 16:31 ` Andi Kleen 2008-07-29 17:22 ` Arjan van de Ven 0 siblings, 1 reply; 14+ messages in thread From: Andi Kleen @ 2008-07-29 16:31 UTC (permalink / raw) To: Arjan van de Ven Cc: Andi Kleen, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar > > A power saving feature that has a significant trade off between power > > and performance. > > do you have numbers to explain "significant tradeoff" ? I don't have numbers, but from the theory it seems pretty clear. When you e.g. have two processes with 6MB cache foot print and you have two 2C CPUs with 6MB cache they will fit in cache, but with power aware scheduler they won't because both processes will run on the single 6MB package. With NUMA the effect is even worse because also the memory controllers are not used evenly. And there's the FSB bandwidth, but that's a secondary issue. > > > > This means performance will go down. Perhaps it would be ok on > > battery, > > the illusion that power only matters on battery got buried a few years > ago ;) My understanding was always that unless you're on battery power saving features that are enabled by default are not supposed to impact performance significantly. When the user says impacting performance is ok then doing that is fine of course, but not by default. And I don't think that's an illusion. In fact if power saving means losing a lot of performance people would get discouraged from using it, and surely you don't want that. -Andi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 16:31 ` Andi Kleen @ 2008-07-29 17:22 ` Arjan van de Ven 2008-07-29 17:50 ` Andi Kleen 0 siblings, 1 reply; 14+ messages in thread From: Arjan van de Ven @ 2008-07-29 17:22 UTC (permalink / raw) To: Andi Kleen Cc: Andi Kleen, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar On Tue, 29 Jul 2008 18:31:13 +0200 Andi Kleen <andi@firstfloor.org> wrote: > > > A power saving feature that has a significant trade off between > > > power and performance. > > > > do you have numbers to explain "significant tradeoff" ? > > I don't have numbers, but from the theory it seems pretty clear. > When you e.g. have two processes with 6MB cache foot print and > you have two 2C CPUs with 6MB cache they will fit in cache, but > with power aware scheduler they won't because both processes will run > on the single 6MB package. With NUMA the effect is even worse because > also the memory controllers are not used evenly. > And there's the FSB bandwidth, but that's a secondary issue. but if you have 2 threads that share a lot of data, it's the opposite. Or if you have a bunch of things which are smaller than the cache... (and they do share, for example glibc will be largely shared). it's not a clear heavy loss, it's one of those "depends" cases. (which sucks) > > > > > > > This means performance will go down. Perhaps it would be ok on > > > battery, > > > > the illusion that power only matters on battery got buried a few > > years ago ;) > > My understanding was always that unless you're on battery power saving > features that are enabled by default are not supposed to impact > performance significantly. That's not what datacenter people say. As long as power gain is bigger than performance loss.. they tend to want it. Also "significantly" is extremely subjective, like in this case it can be a win or a loss, depending. > When the user says impacting performance > is ok then doing that is fine of course, but not by default. that's a fine kernel policy. Distros will override this policy if their users tell them they're willing to do the tradeoff.. they will pick that default. In fact.. that's a big part of their job.. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 17:22 ` Arjan van de Ven @ 2008-07-29 17:50 ` Andi Kleen 0 siblings, 0 replies; 14+ messages in thread From: Andi Kleen @ 2008-07-29 17:50 UTC (permalink / raw) To: Arjan van de Ven Cc: Andi Kleen, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Ingo Molnar, jblunck > That's not what datacenter people say. As long as power gain is bigger > than performance loss.. they tend to want it. That's a special case. It's fine but they should explicitely configure it. I suspect even the data center people prefer "opt in" versus "opt out" here. > Also "significantly" is extremely subjective, like in this case it can > be a win or a loss, depending. My impression is that the losses are more likely than the wins here. > > > When the user says impacting performance > > is ok then doing that is fine of course, but not by default. > > that's a fine kernel policy. > > Distros will override this policy if their users tell them they're > willing to do the tradeoff.. they will pick that default. In fact.. > that's a big part of their job.. I'm not fully convinced that was done intentionally in this case. If there's an explicit setting somewhere that's fine anyways, but I think here it more looks like a mistake. -Andi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-29 4:22 ` Mike Galbraith 2008-07-29 12:09 ` Andi Kleen @ 2008-07-30 9:05 ` Ingo Molnar 2008-07-30 9:26 ` Andrew Morton 1 sibling, 1 reply; 14+ messages in thread From: Ingo Molnar @ 2008-07-30 9:05 UTC (permalink / raw) To: Mike Galbraith, Greg KH Cc: Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Andi Kleen * Mike Galbraith <efault@gmx.de> wrote: > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > Hello Aneesh, > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > > > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 > > > > Does the attached patch solve the problem? > > Patch seems to have missed the boat for rc1 too. Greg? Ingo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-30 9:05 ` Ingo Molnar @ 2008-07-30 9:26 ` Andrew Morton 2008-07-30 16:31 ` Greg KH 0 siblings, 1 reply; 14+ messages in thread From: Andrew Morton @ 2008-07-30 9:26 UTC (permalink / raw) To: Ingo Molnar Cc: Mike Galbraith, Greg KH, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Andi Kleen On Wed, 30 Jul 2008 11:05:49 +0200 Ingo Molnar <mingo@elte.hu> wrote: > > * Mike Galbraith <efault@gmx.de> wrote: > > > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > > Hello Aneesh, > > > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > > > > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 > > > > > > Does the attached patch solve the problem? > > > > Patch seems to have missed the boat for rc1 too. I grabbed Andi's 53rd copy and have sent it Linuswards. > Greg? We should make him maintain 2.6.27-rc1.1 ;) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000002 2008-07-30 9:26 ` Andrew Morton @ 2008-07-30 16:31 ` Greg KH 0 siblings, 0 replies; 14+ messages in thread From: Greg KH @ 2008-07-30 16:31 UTC (permalink / raw) To: Andrew Morton Cc: Ingo Molnar, Mike Galbraith, Frederik Deweerdt, Aneesh Kumar K.V, linux-kernel@vger.kernel.org, suresh.b.siddha, Andi Kleen On Wed, Jul 30, 2008 at 02:26:31AM -0700, Andrew Morton wrote: > On Wed, 30 Jul 2008 11:05:49 +0200 Ingo Molnar <mingo@elte.hu> wrote: > > > > > * Mike Galbraith <efault@gmx.de> wrote: > > > > > On Tue, 2008-07-29 at 00:26 +0200, Frederik Deweerdt wrote: > > > > Hello Aneesh, > > > > > > > > On Fri, Jul 25, 2008 at 03:23:17PM +0530, Aneesh Kumar K.V wrote: > > > > > [ 163.378265] BUG: unable to handle kernel NULL pointer dereference at 00000002 > > > > > [ 163.378276] IP: [<c0124933>] sched_power_savings_store+0x13/0x70 > > > > > > > > Does the attached patch solve the problem? > > > > > > Patch seems to have missed the boat for rc1 too. > > I grabbed Andi's 53rd copy and have sent it Linuswards. > > > Greg? > > We should make him maintain 2.6.27-rc1.1 ;) I know I've been slow in getting back up to speed due to vacations and work issues, but that's just cruel to suggest such a thing :) thanks, greg k-h ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-06-14 17:46 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-06-14 17:45 BUG: unable to handle kernel NULL pointer dereference at 00000002 Pierre-Philipp Braun -- strict thread matches above, loose matches on Subject: below -- 2008-07-25 9:53 Aneesh Kumar K.V 2008-07-28 22:26 ` Frederik Deweerdt 2008-07-29 4:22 ` Mike Galbraith 2008-07-29 12:09 ` Andi Kleen 2008-07-29 13:56 ` Arjan van de Ven 2008-07-29 14:53 ` Andi Kleen 2008-07-29 15:30 ` Arjan van de Ven 2008-07-29 16:31 ` Andi Kleen 2008-07-29 17:22 ` Arjan van de Ven 2008-07-29 17:50 ` Andi Kleen 2008-07-30 9:05 ` Ingo Molnar 2008-07-30 9:26 ` Andrew Morton 2008-07-30 16:31 ` Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.