Re: [PATCH 1/13] speedtch: Clean up printk()'s in drivers/usb/atm/speedtch.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH wrote:
| On Sat, Mar 05, 2005 at 05:37:13PM -0600, James Nelson wrote:
|
|>Add a KERN_WARNING constant to a printk() that is missing it, and add a driver
|>prefix to another two in drivers/usb/atm/speedtch.c
|
|
| Please CC: usb patches to the usb maintainer, it makes it a bit hard for
| him to apply them otherwise :)
|
Sorry, screwed up with my patchbomb script...
|
|>Signed-off-by: James Nelson <[EMAIL PROTECTED]>
|>
|>diff -Nurp -x dontdiff-osdl --exclude='*~'
linux-2.6.11-mm1-original/drivers/usb/atm/speedtch.c
linux-2.6.11-mm1/drivers/usb/atm/speedtch.c
|>--- linux-2.6.11-mm1-original/drivers/usb/atm/speedtch.c 2005-03-05
13:29:48.0 -0500
|>+++ linux-2.6.11-mm1/drivers/usb/atm/speedtch.c2005-03-05
13:36:44.0 -0500
|>@@ -192,8 +192,8 @@ static int speedtch_set_swbuff(struct sp
|> 0x32, 0x40, state ? 0x01 : 0x00,
|> 0x00, NULL, 0, 100);
|> if (ret < 0) {
|>- printk("Warning: %sabling SW buffering: usb_control_msg returned
%d\n",
|>- state ? "En" : "Dis", ret);
|>+ printk(KERN_WARNING "%s: %sabling SW buffering: usb_control_msg
returned %d\n",
|>+ speedtch_driver_name, state ? "En" : "Dis", ret);
|
|
| No, please, if you are going to convert anything like this, use the
| dev_dbg(), dev_warn(), and assorted macros instead. Or if nothing else,
| the usb subsystem has it's own dbg(), err() and warn() macros that
| should be gotten rid of, but that's a lot of changes...
|
Okay. A bit more work, but it makes sense.
| These comments pretty much go for all of your patches in this series,
| please rework them all.
|
Any other tips on how the usb printk()s should be formatted to maintain
consistency? Or some driver that I could use as an example?
| thanks,
|
| greg k-h
|
Jim
- --
GPG Public key at pgp.mit.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCKvUhevfmjTWdv3MRAnkvAJ99aKDoqxVsblwktEyrAm26fymAogCfXhkm
7zsxDwAjbqEZZksxgfJKg1k=
=m+mZ
-END PGP SIGNATURE-
-
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: [PATCH 1/13] speedtch: Clean up printk()'s in drivers/usb/atm/speedtch.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH wrote:
| On Sat, Mar 05, 2005 at 05:37:13PM -0600, James Nelson wrote:
|
|Add a KERN_WARNING constant to a printk() that is missing it, and add a driver
|prefix to another two in drivers/usb/atm/speedtch.c
|
|
| Please CC: usb patches to the usb maintainer, it makes it a bit hard for
| him to apply them otherwise :)
|
Sorry, screwed up with my patchbomb script...
|
|Signed-off-by: James Nelson [EMAIL PROTECTED]
|
|diff -Nurp -x dontdiff-osdl --exclude='*~'
linux-2.6.11-mm1-original/drivers/usb/atm/speedtch.c
linux-2.6.11-mm1/drivers/usb/atm/speedtch.c
|--- linux-2.6.11-mm1-original/drivers/usb/atm/speedtch.c 2005-03-05
13:29:48.0 -0500
|+++ linux-2.6.11-mm1/drivers/usb/atm/speedtch.c2005-03-05
13:36:44.0 -0500
|@@ -192,8 +192,8 @@ static int speedtch_set_swbuff(struct sp
| 0x32, 0x40, state ? 0x01 : 0x00,
| 0x00, NULL, 0, 100);
| if (ret 0) {
|- printk(Warning: %sabling SW buffering: usb_control_msg returned
%d\n,
|- state ? En : Dis, ret);
|+ printk(KERN_WARNING %s: %sabling SW buffering: usb_control_msg
returned %d\n,
|+ speedtch_driver_name, state ? En : Dis, ret);
|
|
| No, please, if you are going to convert anything like this, use the
| dev_dbg(), dev_warn(), and assorted macros instead. Or if nothing else,
| the usb subsystem has it's own dbg(), err() and warn() macros that
| should be gotten rid of, but that's a lot of changes...
|
Okay. A bit more work, but it makes sense.
| These comments pretty much go for all of your patches in this series,
| please rework them all.
|
Any other tips on how the usb printk()s should be formatted to maintain
consistency? Or some driver that I could use as an example?
| thanks,
|
| greg k-h
|
Jim
- --
GPG Public key at pgp.mit.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCKvUhevfmjTWdv3MRAnkvAJ99aKDoqxVsblwktEyrAm26fymAogCfXhkm
7zsxDwAjbqEZZksxgfJKg1k=
=m+mZ
-END PGP SIGNATURE-
-
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: diff command line?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russell King wrote: | On Sat, Mar 05, 2005 at 10:48:00AM -0500, Gene Heskett wrote: | |>What are the options normally used to generate a diff for public |>consumption on this list? | | | diff -urpN orig new | | where "orig" and "new" both contain the top level "linux" directory, | so the resulting patch can be applied with patch -p1. | You'd also want to add "-x dontdiff", using http://developer.osdl.org/rddunlap/scripts/dontdiff-osdl That way, you can do a diff, even if you have run a compile in one of the directory trees. - -- GPG Public key at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCKeIZevfmjTWdv3MRAjPYAJ9s3PrU/hjuILrGlIh3nuO/Scd4TACghQwQ WD5p8VRpp6mfI+b+FOHZIn0= =n8/k -END PGP SIGNATURE- - 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: diff command line?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russell King wrote: | On Sat, Mar 05, 2005 at 10:48:00AM -0500, Gene Heskett wrote: | |What are the options normally used to generate a diff for public |consumption on this list? | | | diff -urpN orig new | | where orig and new both contain the top level linux directory, | so the resulting patch can be applied with patch -p1. | You'd also want to add -x dontdiff, using http://developer.osdl.org/rddunlap/scripts/dontdiff-osdl That way, you can do a diff, even if you have run a compile in one of the directory trees. - -- GPG Public key at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCKeIZevfmjTWdv3MRAjPYAJ9s3PrU/hjuILrGlIh3nuO/Scd4TACghQwQ WD5p8VRpp6mfI+b+FOHZIn0= =n8/k -END PGP SIGNATURE- - 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: Huge unreliability - does Linux have something to do with it?
jerome lacoste wrote: [Sorry for the sensational title] I have had this laptop for three years. It ran Linux (Debian unstable) from the start and its hardware has been very unreliable: I changed hard disks twice and the motherboard thrice. My DVD drive started failing some days ago (this one is 'original', 3 years old). But I don't mind as I am not under warranty anymore... This morning the machine booted with fsck errors on my hard disk. I am not sure if I did the right thing, but I said clear the inodes, and I ended up loosing some programs(*) (du, dircolors, etc..). The day starts well isn't it? Sounds like I will have to switch disks again... I halted the machine correctly yesterday night. I never dropped the box in 3 years. Am I just being unlucky? Or could the fact that I am using Linux on the box affect the reliability in some ways on that particular hardware (Dell Inspiron 8100)? I run Linux on 3 other computers and never had single problems with them. How can the file system (ext3) be messed up the way it was this morning after I stopped the machine correctly yesterday? Could a hardware failure look like bad sectors to fsck? It can. I had a drive crash on my server a couple of months ago, and I had ext3 errors show up before the syslog filled up with the ide errors. The hard disk was only 1 1/2 years old. If the bad sectors happen where directory inodes are written, your directory structure will be turned into swiss cheese. That will *definitely* cause ext3 errors, and dump you (in Red Hat systems, at least) to a shell on reboot. Attached the output of smartctl -a /dev/hda, whatever that helps. Jerome (*) I accept tips on discovering and maybe recovering which files have been taken out of my system... You might not have any luck. After fsck -f, I thought I had saved the drive, copied everything that was left onto another machine, and found that most of the larger files had holes in them - mp3's had skips, jpegs were completely corrupted, etc. That's what made me get a backup FireWire drive... :) - 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: Huge unreliability - does Linux have something to do with it?
jerome lacoste wrote: [Sorry for the sensational title] I have had this laptop for three years. It ran Linux (Debian unstable) from the start and its hardware has been very unreliable: I changed hard disks twice and the motherboard thrice. My DVD drive started failing some days ago (this one is 'original', 3 years old). But I don't mind as I am not under warranty anymore... This morning the machine booted with fsck errors on my hard disk. I am not sure if I did the right thing, but I said clear the inodes, and I ended up loosing some programs(*) (du, dircolors, etc..). The day starts well isn't it? Sounds like I will have to switch disks again... I halted the machine correctly yesterday night. I never dropped the box in 3 years. Am I just being unlucky? Or could the fact that I am using Linux on the box affect the reliability in some ways on that particular hardware (Dell Inspiron 8100)? I run Linux on 3 other computers and never had single problems with them. How can the file system (ext3) be messed up the way it was this morning after I stopped the machine correctly yesterday? Could a hardware failure look like bad sectors to fsck? It can. I had a drive crash on my server a couple of months ago, and I had ext3 errors show up before the syslog filled up with the ide errors. The hard disk was only 1 1/2 years old. If the bad sectors happen where directory inodes are written, your directory structure will be turned into swiss cheese. That will *definitely* cause ext3 errors, and dump you (in Red Hat systems, at least) to a shell on reboot. Attached the output of smartctl -a /dev/hda, whatever that helps. Jerome (*) I accept tips on discovering and maybe recovering which files have been taken out of my system... You might not have any luck. After fsck -f, I thought I had saved the drive, copied everything that was left onto another machine, and found that most of the larger files had holes in them - mp3's had skips, jpegs were completely corrupted, etc. That's what made me get a backup FireWire drive... :) - 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/
2.6.11-rc2-mm2 - kernel panic with SysRq-f
This is copied from a serial console. This is repeatable - every time I do sysrq-f, it panics - keyboard, VGA and network go down, but USB and the serial console stay up (can tell from the hid-input messages the mouse is spewing in -mm2). I end up having to pull the power cord to shut it down. .config attached. SysRq : Manual OOM execution oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 4, high 12, batch 2 cpu 0 cold: low 0, high 4, batch 2 HighMem per-cpu: empty Free pages:2952kB (0kB HighMem) Active:2407 inactive:8976 dirty:23 writeback:0 unstable:0 free:738 slab:1103 mapped:705 pagetables:62 DMA free:1376kB min:256kB low:320kB high:384kB active:580kB inactive:9444kB present:16384kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 46 46 Normal free:1576kB min:752kB low:940kB high:1128kB active:9048kB inactive:26460kB present:48064kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 92*4kB 28*8kB 13*16kB 4*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1376kB Normal: 22*4kB 28*8kB 11*16kB 6*32kB 4*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1576kB HighMem: empty Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 498952kB Total swap = 498952kB Out of Memory: Killed process 1782 (sshd). scheduling while atomic: swapper/0x00010002/0 [] dump_stack+0x17/0x20 [] schedule+0x573/0x580 [] schedule_timeout+0x5b/0xb0 [] __handle_sysrq+0x82/0x140 [] kbd_event+0x93/0xf0 [] input_event+0xd3/0x3b0 [] atkbd_report_key+0x2f/0x90 [] atkbd_interrupt+0x1ee/0x530 [] serio_interrupt+0x44/0xa8 [] i8042_interrupt+0x140/0x310 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xdd/0x150 [] do_IRQ+0x4a/0x70 === [] common_interrupt+0x1a/0x20 [] cpu_idle+0x50/0x60 [] start_kernel+0x151/0x170 [] 0xc010019f bad: scheduling from the idle thread! [] dump_stack+0x17/0x20 [] schedule+0x538/0x580 [] schedule_timeout+0x5b/0xb0 [] __handle_sysrq+0x82/0x140 [] kbd_event+0x93/0xf0 [] input_event+0xd3/0x3b0 [] atkbd_report_key+0x2f/0x90 [] atkbd_interrupt+0x1ee/0x530 [] serio_interrupt+0x44/0xa8 [] i8042_interrupt+0x140/0x310 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xdd/0x150 [] do_IRQ+0x4a/0x70 === [] common_interrupt+0x1a/0x20 [] cpu_idle+0x50/0x60 [] start_kernel+0x151/0x170 [] 0xc010019f Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01143b4 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: tulip CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010092 (2.6.11-rc2-mm2) EIP is at dequeue_task+0x14/0x70 eax: c0414ba0 ebx: c0414b80 ecx: c0414b80 edx: esi: edi: 0086 ebp: c04e3e10 esp: c04e3e08 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c04e3000 task=c0414b80) Stack: c0414b80 c04e3e70 c04e3e1c c01146a0 c0414b80 c04e3e5c c03b4fae c03cb6d8 c0414d20 00010002 c04e3e70 3b9aca00 55393de2 0019 c0414b80 c0414ca4 fffcc59e c04e3e70 0086 c04e3e98 c03b5f8b c04e3e7c Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x149/0x1b0 [] die+0xdd/0x170 [] do_page_fault+0x30a/0x65a [] error_code+0x2b/0x30 [] deactivate_task+0x10/0x20 [] schedule+0x12e/0x580 [] schedule_timeout+0x5b/0xb0 [] __handle_sysrq+0x82/0x140 [] kbd_event+0x93/0xf0 [] input_event+0xd3/0x3b0 [] atkbd_report_key+0x2f/0x90 [] atkbd_interrupt+0x1ee/0x530 [] serio_interrupt+0x44/0xa8 [] i8042_interrupt+0x140/0x310 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xdd/0x150 [] do_IRQ+0x4a/0x70 === [] common_interrupt+0x1a/0x20 [] cpu_idle+0x50/0x60 [] start_kernel+0x151/0x170 [] 0xc010019f Code: e8 42 0e 00 00 5d b8 e0 83 4e c0 c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 83 ec 08 89 1c 24 89 c3 8d 40 20 89 74 24 04 89 d6 0a 8b 48 04 39 0 <0>Kernel panic - not syncing: Fatal exception in interrupt # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2-mm2 # Tue Feb 1 16:51:53 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_LTT is not set
2.6.11-rc2-mm2 - kernel panic with SysRq-f
This is copied from a serial console. This is repeatable - every time I do sysrq-f, it panics - keyboard, VGA and network go down, but USB and the serial console stay up (can tell from the hid-input messages the mouse is spewing in -mm2). I end up having to pull the power cord to shut it down. .config attached. SysRq : Manual OOM execution oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 4, high 12, batch 2 cpu 0 cold: low 0, high 4, batch 2 HighMem per-cpu: empty Free pages:2952kB (0kB HighMem) Active:2407 inactive:8976 dirty:23 writeback:0 unstable:0 free:738 slab:1103 mapped:705 pagetables:62 DMA free:1376kB min:256kB low:320kB high:384kB active:580kB inactive:9444kB present:16384kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 46 46 Normal free:1576kB min:752kB low:940kB high:1128kB active:9048kB inactive:26460kB present:48064kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 92*4kB 28*8kB 13*16kB 4*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1376kB Normal: 22*4kB 28*8kB 11*16kB 6*32kB 4*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1576kB HighMem: empty Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 498952kB Total swap = 498952kB Out of Memory: Killed process 1782 (sshd). scheduling while atomic: swapper/0x00010002/0 [c0103e07] dump_stack+0x17/0x20 [c03b53f3] schedule+0x573/0x580 [c03b5f8b] schedule_timeout+0x5b/0xb0 [c027b332] __handle_sysrq+0x82/0x140 [c02762d3] kbd_event+0x93/0xf0 [c02f8343] input_event+0xd3/0x3b0 [c02fac4f] atkbd_report_key+0x2f/0x90 [c02fae9e] atkbd_interrupt+0x1ee/0x530 [c02919f4] serio_interrupt+0x44/0xa8 [c0292660] i8042_interrupt+0x140/0x310 [c013955a] handle_IRQ_event+0x2a/0x60 [c013966d] __do_IRQ+0xdd/0x150 [c010526a] do_IRQ+0x4a/0x70 === [c010398e] common_interrupt+0x1a/0x20 [c0101100] cpu_idle+0x50/0x60 [c04ad831] start_kernel+0x151/0x170 [c010019f] 0xc010019f bad: scheduling from the idle thread! [c0103e07] dump_stack+0x17/0x20 [c03b53b8] schedule+0x538/0x580 [c03b5f8b] schedule_timeout+0x5b/0xb0 [c027b332] __handle_sysrq+0x82/0x140 [c02762d3] kbd_event+0x93/0xf0 [c02f8343] input_event+0xd3/0x3b0 [c02fac4f] atkbd_report_key+0x2f/0x90 [c02fae9e] atkbd_interrupt+0x1ee/0x530 [c02919f4] serio_interrupt+0x44/0xa8 [c0292660] i8042_interrupt+0x140/0x310 [c013955a] handle_IRQ_event+0x2a/0x60 [c013966d] __do_IRQ+0xdd/0x150 [c010526a] do_IRQ+0x4a/0x70 === [c010398e] common_interrupt+0x1a/0x20 [c0101100] cpu_idle+0x50/0x60 [c04ad831] start_kernel+0x151/0x170 [c010019f] 0xc010019f Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01143b4 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: tulip CPU:0 EIP:0060:[c01143b4]Not tainted VLI EFLAGS: 00010092 (2.6.11-rc2-mm2) EIP is at dequeue_task+0x14/0x70 eax: c0414ba0 ebx: c0414b80 ecx: c0414b80 edx: esi: edi: 0086 ebp: c04e3e10 esp: c04e3e08 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c04e3000 task=c0414b80) Stack: c0414b80 c04e3e70 c04e3e1c c01146a0 c0414b80 c04e3e5c c03b4fae c03cb6d8 c0414d20 00010002 c04e3e70 3b9aca00 55393de2 0019 c0414b80 c0414ca4 fffcc59e c04e3e70 0086 c04e3e98 c03b5f8b c04e3e7c Call Trace: [c0103dda] show_stack+0x7a/0x90 [c0103f59] show_registers+0x149/0x1b0 [c010414d] die+0xdd/0x170 [c01133ea] do_page_fault+0x30a/0x65a [c0103a57] error_code+0x2b/0x30 [c01146a0] deactivate_task+0x10/0x20 [c03b4fae] schedule+0x12e/0x580 [c03b5f8b] schedule_timeout+0x5b/0xb0 [c027b332] __handle_sysrq+0x82/0x140 [c02762d3] kbd_event+0x93/0xf0 [c02f8343] input_event+0xd3/0x3b0 [c02fac4f] atkbd_report_key+0x2f/0x90 [c02fae9e] atkbd_interrupt+0x1ee/0x530 [c02919f4] serio_interrupt+0x44/0xa8 [c0292660] i8042_interrupt+0x140/0x310 [c013955a] handle_IRQ_event+0x2a/0x60 [c013966d] __do_IRQ+0xdd/0x150 [c010526a] do_IRQ+0x4a/0x70 === [c010398e] common_interrupt+0x1a/0x20 [c0101100] cpu_idle+0x50/0x60 [c04ad831] start_kernel+0x151/0x170 [c010019f] 0xc010019f Code: e8 42 0e 00 00 5d b8 e0 83 4e c0 c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 83 ec 08 89 1c 24 89 c3 8d 40 20 89 74 24 04 89 d6 ff 0a 8b 48 04 39 0 0Kernel panic - not syncing: Fatal exception in interrupt # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2-mm2 # Tue Feb 1 16:51:53 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION=
Re: 2.6.11-rc2-mm2 (& bk9) - rowdy little warn in drivers/usb/input/hid-input.c
Cal wrote:
With 2.6.11-rc2-mm2 & 2.6.11-rc2-bk9 and usb mouse, the warn("event
field not found") in drivers/usb/input/hid-input.c is hyperactive
whenever the mouse moves.
hihone kernel: drivers/usb/input/hid-input.c: event field not found
hihone last message repeated 619 times
hihone last message repeated 919 times
hihone last message repeated 1325 times
hihone last message repeated 1045 times
On the deviant case, both type and code appear to have the value 4 (if
that helps). The mouse reports as
hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft
IntelliMouse Optical] on usb-:00:07.2-2
cheers, Cal
(not subscribed, pls cc if needed)
I'm seeing the same thing on 2.6.11-rc2-mm2 with a Logitech USB mouse - every time
the mouse moves, it throws these messages.
Jim
-
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: 2.6.11-rc2-mm2
Laurent Riffard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 31.01.2005 22:15, Andre Eisenbach a écrit : | Andrew, | | My PCMCIA slot (yenta_socket) doesn't work anymore with | 2.6.11-rc2-m2. See the dmesg output below. It works fine with | 2.6.11-rc1-mm1. | | Let me know if you need any additional information. | | Thanks, | Andre | | --- snipp --- | | Linux Kernel Card Services | options: [pci] [cardbus] [pm] | kobject_register failed for pcmcia_core (-17) | [] kobject_register+0x5b/0x70 | [] mod_sysfs_setup+0x50/0xb0 | [] load_module+0x959/0xaa0 | [] sys_init_module+0x5b/0x1a0 | [] sysenter_past_esp+0x52/0x75 | rsrc_nonstatic: Unknown symbol release_cis_mem | rsrc_nonstatic: Unknown symbol pcmcia_socket_list | rsrc_nonstatic: Unknown symbol pccard_validate_cis | rsrc_nonstatic: Unknown symbol destroy_cis_cache | rsrc_nonstatic: Unknown symbol pcmcia_socket_list_rwsem | yenta_socket: Unknown symbol dead_socket | yenta_socket: Unknown symbol pcmcia_register_socket | yenta_socket: Unknown symbol pcmcia_socket_dev_resume | yenta_socket: Unknown symbol pcmcia_parse_events | yenta_socket: Unknown symbol pcmcia_socket_dev_suspend | yenta_socket: Unknown symbol pccard_nonstatic_ops | yenta_socket: Unknown symbol pcmcia_unregister_socket | kobject_register failed for pcmcia_core (-17) | [] kobject_register+0x5b/0x70 | [] mod_sysfs_setup+0x50/0xb0 | [] load_module+0x959/0xaa0 | [] sys_init_module+0x5b/0x1a0 | [] sysenter_past_esp+0x52/0x75 | pcmcia: Unknown symbol pcmcia_get_socket | pcmcia: Unknown symbol pcmcia_get_window | pcmcia: Unknown symbol pcmcia_suspend_card | pcmcia: Unknown symbol pcmcia_replace_cis [snip] I had the same type of problem while loading modules. Fixed this evening by the following patch : http://marc.theaimsgroup.com/?l=linux-kernel=110715631504335 - -- laurent I can confirm that patch took care of a similar kobject_register failure in tulip on my test machine. - 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: 2.6.11-rc2-mm2
Laurent Riffard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 31.01.2005 22:15, Andre Eisenbach a écrit : | Andrew, | | My PCMCIA slot (yenta_socket) doesn't work anymore with | 2.6.11-rc2-m2. See the dmesg output below. It works fine with | 2.6.11-rc1-mm1. | | Let me know if you need any additional information. | | Thanks, | Andre | | --- snipp --- | | Linux Kernel Card Services | options: [pci] [cardbus] [pm] | kobject_register failed for pcmcia_core (-17) | [c021686b] kobject_register+0x5b/0x70 | [c0130620] mod_sysfs_setup+0x50/0xb0 | [c0131999] load_module+0x959/0xaa0 | [c0131b6b] sys_init_module+0x5b/0x1a0 | [c010300d] sysenter_past_esp+0x52/0x75 | rsrc_nonstatic: Unknown symbol release_cis_mem | rsrc_nonstatic: Unknown symbol pcmcia_socket_list | rsrc_nonstatic: Unknown symbol pccard_validate_cis | rsrc_nonstatic: Unknown symbol destroy_cis_cache | rsrc_nonstatic: Unknown symbol pcmcia_socket_list_rwsem | yenta_socket: Unknown symbol dead_socket | yenta_socket: Unknown symbol pcmcia_register_socket | yenta_socket: Unknown symbol pcmcia_socket_dev_resume | yenta_socket: Unknown symbol pcmcia_parse_events | yenta_socket: Unknown symbol pcmcia_socket_dev_suspend | yenta_socket: Unknown symbol pccard_nonstatic_ops | yenta_socket: Unknown symbol pcmcia_unregister_socket | kobject_register failed for pcmcia_core (-17) | [c021686b] kobject_register+0x5b/0x70 | [c0130620] mod_sysfs_setup+0x50/0xb0 | [c0131999] load_module+0x959/0xaa0 | [c0131b6b] sys_init_module+0x5b/0x1a0 | [c010300d] sysenter_past_esp+0x52/0x75 | pcmcia: Unknown symbol pcmcia_get_socket | pcmcia: Unknown symbol pcmcia_get_window | pcmcia: Unknown symbol pcmcia_suspend_card | pcmcia: Unknown symbol pcmcia_replace_cis [snip] I had the same type of problem while loading modules. Fixed this evening by the following patch : http://marc.theaimsgroup.com/?l=linux-kernelm=110715631504335 - -- laurent I can confirm that patch took care of a similar kobject_register failure in tulip on my test machine. - 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: 2.6.11-rc2-mm2 ( bk9) - rowdy little warn in drivers/usb/input/hid-input.c
Cal wrote: With 2.6.11-rc2-mm2 2.6.11-rc2-bk9 and usb mouse, the warn(event field not found) in drivers/usb/input/hid-input.c is hyperactive whenever the mouse moves. hihone kernel: drivers/usb/input/hid-input.c: event field not found hihone last message repeated 619 times hihone last message repeated 919 times hihone last message repeated 1325 times hihone last message repeated 1045 times On the deviant case, both type and code appear to have the value 4 (if that helps). The mouse reports as hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouseAE Optical] on usb-:00:07.2-2 cheers, Cal (not subscribed, pls cc if needed) I'm seeing the same thing on 2.6.11-rc2-mm2 with a Logitech USB mouse - every time the mouse moves, it throws these messages. Jim - 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: [PATCH 0/13] remove cli()/sti() in drivers/char/*
Alan Cox wrote: On Sul, 2005-01-16 at 21:04, Andrew Morton wrote: James Nelson <[EMAIL PROTECTED]> wrote: This series of patches removes the last cli()/sti()/save_flags()/restore_flags() function calls in drivers/char. I don't see much point in this, really. Those cli() calls are a big fat sign saying "broken on smp" and they now generate compile-time warnings emphasising that. These drivers still need to be fixed up - we may las well leave them as-is until someone gets onto doing that. Please drop all the serial ones. I'm slowly working through the serial drivers that are relevant to any kind of users and fixing them up or importing fixes from vendor branches as appropriate. Simple substitions don't work here, and in some cases even simple tty device locks because many cards are chip level interfaces not port level. Alan Right. Please disregard this set of patches - I think I'm done flogging this directory for awhile :) - 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: [PATCH 0/13] remove cli()/sti() in drivers/char/*
Randy.Dunlap wrote: James Nelson wrote: This series of patches removes the last cli()/sti()/save_flags()/restore_flags() function calls in drivers/char. to what end? I guess I don't get it. What makes these drivers SMP-safe now? Or is this series of patches only done to kill off the use of deprecated functions? If that's the case, they could easily give someone the (false) expectation that the drivers are SMP-safe, couldn't they? Well, ftape (for one) is still marked as BROKEN_ON_SMP, but will people know why it's marked that way? Have you read Documentation/cli-sti-removal.txt ? I have. This is just to get rid of the deprecated functions - most of this stuff is already marked BROKEN_ON_SMP (stallion, serial_tx3912, epca, esp, istallion, riscom8, ftape, pcxx and moxa), and ite_gpio.c is a driver for a UP system board. Maybe later (when I have more of an understanding of serial_core, and major driver overhaul) I can tackle actually fixing them, but right now, I'm just doing cleanup work. Jim - 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: [PATCH 0/13] remove cli()/sti() in drivers/char/*
Randy.Dunlap wrote: James Nelson wrote: This series of patches removes the last cli()/sti()/save_flags()/restore_flags() function calls in drivers/char. to what end? I guess I don't get it. What makes these drivers SMP-safe now? Or is this series of patches only done to kill off the use of deprecated functions? If that's the case, they could easily give someone the (false) expectation that the drivers are SMP-safe, couldn't they? Well, ftape (for one) is still marked as BROKEN_ON_SMP, but will people know why it's marked that way? Have you read Documentation/cli-sti-removal.txt ? I have. This is just to get rid of the deprecated functions - most of this stuff is already marked BROKEN_ON_SMP (stallion, serial_tx3912, epca, esp, istallion, riscom8, ftape, pcxx and moxa), and ite_gpio.c is a driver for a UP system board. Maybe later (when I have more of an understanding of serial_core, and major driver overhaul) I can tackle actually fixing them, but right now, I'm just doing cleanup work. Jim - 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: [PATCH 0/13] remove cli()/sti() in drivers/char/*
Alan Cox wrote: On Sul, 2005-01-16 at 21:04, Andrew Morton wrote: James Nelson [EMAIL PROTECTED] wrote: This series of patches removes the last cli()/sti()/save_flags()/restore_flags() function calls in drivers/char. I don't see much point in this, really. Those cli() calls are a big fat sign saying broken on smp and they now generate compile-time warnings emphasising that. These drivers still need to be fixed up - we may las well leave them as-is until someone gets onto doing that. Please drop all the serial ones. I'm slowly working through the serial drivers that are relevant to any kind of users and fixing them up or importing fixes from vendor branches as appropriate. Simple substitions don't work here, and in some cases even simple tty device locks because many cards are chip level interfaces not port level. Alan Right. Please disregard this set of patches - I think I'm done flogging this directory for awhile :) - 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/
