8139cp misses interrupts during resume
I'm having problem with the interrupt getting killed after suspend with my 8139cp controller. The problem only appears if the cable is connected during resume (before suspend is irrelevant) and the interface is down. Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from suspend-to-ram included. I find it a bit strange that 8139cp's interrupt handler isn't included when it dumps the handlers. Could this be related to the problem? Rgds Pierre (gpe 28) ACPI: Power Resource [C18D] (on) ACPI: Power Resource [C195] (on) ACPI: Power Resource [C19C] (on) ACPI: Power Resource [C1A6] (on) ACPI: PCI Interrupt Link [C0C2] (IRQs 5 *10) ACPI: PCI Interrupt Link [C0C3] (IRQs 5 *10) ACPI: PCI Interrupt Link [C0C4] (IRQs *5 10) ACPI: PCI Interrupt Link [C0C5] (IRQs *5 10) ACPI: PCI Interrupt Link [C0C6] (IRQs 5 10) *0, disabled. ACPI: PCI Interrupt Link [C0C7] (IRQs 5 10) *11 ACPI: PCI Interrupt Link [C0C8] (IRQs 5 10) *0, disabled. ACPI: PCI Interrupt Link [C0C9] (IRQs *5 10) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 15 devices PnPBIOS: Disabled by ACPI PNP usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report pnp: the driver 'system' has been registered pnp: match found with the PnP device '00:00' and the driver 'system' pnp: match found with the PnP device '00:0c' and the driver 'system' pnp: match found with the PnP device '00:0d' and the driver 'system' pnp: 00:0d: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:0d: ioport range 0x1000-0x107f could not be reserved pnp: 00:0d: ioport range 0x1100-0x113f has been reserved pnp: 00:0d: ioport range 0x1200-0x121f has been reserved pnp: match found with the PnP device '00:0e' and the driver 'system' audit: initializing netlink socket (disabled) audit(1121799313.818:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SGI XFS with ACLs, security attributes, no debug enabled SGI XFS Quota Management subsystem Initializing Cryptographic API isapnp: Scanning for PnP cards... isapnp: No Plug Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 855PM Chipset. agpgart: AGP aperture is 256M @ 0xb000 [drm] Initialized drm 1.0.0 20040925 pnp: the driver 'i8042 kbd' has been registered pnp: match found with the PnP device '00:0a' and the driver 'i8042 kbd' pnp: the driver 'i8042 aux' has been registered pnp: match found with the PnP device '00:0b' and the driver 'i8042 aux' PNP: PS/2 Controller [PNP0303:C1A3,PNP0f13:C1A4] at 0x60,0x64 irq 1,12 i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A pnp: the driver 'serial' has been registered pnp: match found with the PnP device '00:03' and the driver 'serial' ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: PCI Interrupt Link [C0C3] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:1f.6[B] - Link [C0C3] - GSI 10 (level, low) - IRQ 10 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH4: IDE controller at PCI slot :00:1f.1 PCI: Enabling device :00:1f.1 (0005 - 0007) ACPI: PCI Interrupt Link [C0C4] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI Interrupt :00:1f.1[A] - Link [C0C4] - GSI 5 (level, low) - IRQ 5 ICH4: chipset revision 1 ICH4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x4c40-0x4c47, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x4c48-0x4c4f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: TOSHIBA MK4025GAS, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4241N, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 pnp: the driver 'ide' has been registered ide2: I/O resource 0x3EE-0x3EE not free. ide2: ports already in use, skipping probe Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 78140160 sectors (40007 MB), CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hda5 hda6 hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA Uniform CD-ROM
Re: [PATCH] 8139cp - redetect link after suspend
John W. Linville wrote: On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote: After suspend the driver needs to retest link status in case the cable has been inserted or removed during the suspend. Signed-off-by: Pierre Ossman [EMAIL PROTECTED] Please copy netdev@vger.kernel.org for network driver patches. Other than that, the patch looks acceptable to me, fwiw... Has anyone had else had the time to review this? Jeff especially. Rgds Pierre - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8139cp misses interrupts during resume
Pierre Ossman wrote: I'm having problem with the interrupt getting killed after suspend with my 8139cp controller. The problem only appears if the cable is connected during resume (before suspend is irrelevant) and the interface is down. Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from suspend-to-ram included. I find it a bit strange that 8139cp's interrupt handler isn't included when it dumps the handlers. Could this be related to the problem? Anyone familiar with this driver that can give me some pointers on what to look for? I'd prefer not to have to learn how the entire thing works just to fix one bug. :) Rgds Pierre - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 8139cp: Catch all interrupts
Register interrupt handler when net device is registered. Avoids missing interrupts if the interrupt mask gets out of sync. Signed-off-by: Pierre Ossman [EMAIL PROTECTED] --- The reason this patch is needed for me is that the resume function is broken. It enables interrupts unconditionally, but the interrupt handler is only registered when the device is up. I don't have enough knowledge about the driver to fix the resume function so this patch will instead make sure that the interrupt handler is registered at all times (which can be a nice safeguard even when the resume function gets fixed). Index: linux-wbsd/drivers/net/8139cp.c === --- linux-wbsd/drivers/net/8139cp.c (revision 165) +++ linux-wbsd/drivers/net/8139cp.c (working copy) @@ -1204,20 +1204,11 @@ cp_init_hw(cp); - rc = request_irq(dev-irq, cp_interrupt, SA_SHIRQ, dev-name, dev); - if (rc) - goto err_out_hw; - netif_carrier_off(dev); mii_check_media(cp-mii_if, netif_msg_link(cp), TRUE); netif_start_queue(dev); return 0; - -err_out_hw: - cp_stop_hw(cp); - cp_free_rings(cp); - return rc; } static int cp_close (struct net_device *dev) @@ -1238,7 +1229,6 @@ spin_unlock_irqrestore(cp-lock, flags); synchronize_irq(dev-irq); - free_irq(dev-irq, dev); cp_free_rings(cp); return 0; @@ -1813,6 +1803,10 @@ if (rc) goto err_out_iomap; + rc = request_irq(dev-irq, cp_interrupt, SA_SHIRQ, dev-name, dev); + if (rc) + goto err_out_unreg; + printk (KERN_INFO %s: RTL-8139C+ at 0x%lx, %02x:%02x:%02x:%02x:%02x:%02x, IRQ %d\n, @@ -1832,6 +1826,8 @@ return 0; +err_out_unreg: + unregister_netdev(dev); err_out_iomap: iounmap(regs); err_out_res: @@ -1852,6 +1848,7 @@ if (!dev) BUG(); + free_irq(dev-irq, dev); unregister_netdev(dev); iounmap(cp-regs); if (cp-wol_enabled) pci_set_power_state (pdev, PCI_D0);
Re: [PATCH 0/7] 8139cp: misc minor changes
Ehm... why am I included in this? :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] 8139cp: misc minor changes
Francois Romieu wrote: Pierre Ossman [EMAIL PROTECTED] : Ehm... why am I included in this? :) To preserve an happy 8139cp user :o) A noble endeavor. Carry on. ;) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 02/12] 8139cp: register interrupt handler when net device is registered
[EMAIL PROTECTED] wrote: From: Pierre Ossman [EMAIL PROTECTED] Avoids missing interrupts if the interrupt mask gets out of sync. The reason this patch is needed for me is that the resume function is broken. It enables interrupts unconditionally, but the interrupt handler is only registered when the device is up. I don't have enough knowledge about the driver to fix the resume function so this patch will instead make sure that the interrupt handler is registered at all times (which can be a nice safeguard even when the resume function gets fixed). (akpm: carry this in -mm pending a fix of the resume function) Signed-off-by: Pierre Ossman [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- This was fixed properly by Francois Romieu, so please merge those instead: http://bugzilla.kernel.org/show_bug.cgi?id=5681 Rgds Pierre - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: networking crash in current mainline: sk_filter_delayed_uncharge()
Andrew Morton wrote: powerpc mac G5 config: http://userweb.kernel.org/~akpm/config-g5.txt screenshot: http://userweb.kernel.org/~akpm/dsc5.jpg It does this shortly after bringing up eth0 (tg3), in dhclient. +1 A Pentium M laptop here. Problem both with a ipw2200 wifi card and 8139 ethernet card. [ 174.237818] BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 [ 174.237828] printing eip: c05b6ed1 *pde = [ 174.237834] Oops: [#1] PREEMPT [ 174.237837] Modules linked in: tun rfcomm l2cap sunrpc binfmt_misc radeon drm ipv6 snd_intel8x0m snd_intel8x0 snd_seq_dummy snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd hci_usb pcmcia ipw2200 soundcore button bluetooth rtc_cmos parport_pc smsc_ircc2 firewire_ohci i2c_i801 yenta_socket rsrc_nonstatic ieee80211 rtc_core 8139cp parport snd_page_alloc irda firewire_core crc_itu_t 8139too ieee80211_crypt battery ac pcmcia_core pcspkr i2c_core wbsd mmc_core video output rtc_lib crc_ccitt mii sr_mod sg cdrom ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ehci_hcd [ 174.237880] CPU:0 [ 174.237881] EIP:0060:[c05b6ed1]Not tainted VLI [ 174.237882] EFLAGS: 00210246 (2.6.23 #11) [ 174.237892] EIP is at sk_filter_delayed_uncharge+0x1/0x20 [ 174.237895] eax: c3cefc00 ebx: ecx: edx: [ 174.237898] esi: c3cefc00 edi: ebp: c3e05efc esp: c3e05edc [ 174.237901] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [ 174.237904] Process dhclient (pid: 2997, ti=c3e05000 task=c3e753b0 task.ti=c3e05000) [ 174.237906] Stack: c3e05efc c05b7032 0068 c3cf3080 0058 c3e05f24 c3cefc00 c3a86300 [ 174.237913]c3e05f48 c05a366e c3d039f8 c3e2c180 0004 bfca000b 0001 [ 174.237918]bfca000b c3756080 bfca000b 080b3320 c3e05f5c c3e05f48 c059f2f0 c3e05f58 [ 174.237924] Call Trace: [ 174.237926] [c04051da] show_trace_log_lvl+0x1a/0x30 [ 174.237933] [c0405299] show_stack_log_lvl+0xa9/0xd0 [ 174.237937] [c04054c6] show_registers+0x206/0x350 [ 174.237940] [c0405711] die+0x101/0x200 [ 174.237944] [c060cd7e] do_page_fault+0x3de/0x6c0 [ 174.237950] [c060b402] error_code+0x6a/0x70 [ 174.237953] [c05a366e] sock_setsockopt+0x58e/0x5b0 [ 174.237958] [c059f4c5] sys_setsockopt+0x95/0xb0 [ 174.237964] [c05a0f8a] sys_socketcall+0x21a/0x280 [ 174.237968] [c040428a] syscall_call+0x7/0xb [ 174.237972] === [ 174.237973] Code: 77 c8 eb e6 8d b6 00 00 00 00 83 7c d9 04 0f 76 b9 eb d7 8d b4 26 00 00 00 00 8b 44 d9 04 85 c0 75 a8 eb c6 8d b6 00 00 00 00 55 8b 4a 04 89 e5 8d 0c cd 10 00 00 00 29 48 5c 8d 42 08 ba 40 6f [ 174.237999] EIP: [c05b6ed1] sk_filter_delayed_uncharge+0x1/0x20 SS:ESP 0068:c3e05edc Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
net: alignment problem in icmp code
Structure assignment have to be aligned just like any assignment, and the skb
could point to anything. So take the safe route and use a memcpy().
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..a7e2ec9 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -783,7 +783,7 @@ static void icmp_echo(struct sk_buff *skb)
if (!sysctl_icmp_echo_ignore_all) {
struct icmp_bxm icmp_param;
- icmp_param.data.icmph = *icmp_hdr(skb);
+ memcpy(icmp_param.data.icmph, icmp_hdr(skb), sizeof(struct
icmphdr));
icmp_param.data.icmph.type = ICMP_ECHOREPLY;
icmp_param.skb = skb;
icmp_param.offset = 0;
@@ -819,7 +819,7 @@ static void icmp_timestamp(struct sk_buff *skb)
icmp_param.data.times[2] = icmp_param.data.times[1];
if (skb_copy_bits(skb, 0, icmp_param.data.times[0], 4))
BUG();
- icmp_param.data.icmph = *icmp_hdr(skb);
+ memcpy(icmp_param.data.icmph, icmp_hdr(skb), sizeof(struct icmphdr));
icmp_param.data.icmph.type = ICMP_TIMESTAMPREPLY;
icmp_param.data.icmph.code = 0;
icmp_param.skb = skb;
signature.asc
Description: PGP signature
Re: net: alignment problem in icmp code
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Pierre Ossman [EMAIL PROTECTED] Date: Sat, 20 Oct 2007 23:35:40 +0200 Structure assignment have to be aligned just like any assignment, and the skb could point to anything. So take the safe route and use a memcpy(). Signed-off-by: Pierre Ossman [EMAIL PROTECTED] Unfortunately this doesn't work, GCC can inline the memcpy just like the assignment. I tried to use a similar trick in the net/xfrm/xfrm_user.c code but in the end it doesn't work at all. Inlining isn't the problem, but the defined semantics of assignment versus memcpy(). memcpy() must work on any region of memory, whilst assignment must only work on a properly aligned object. Since icmphdr contains a u32, the compiler knows the object will always be 32-bit aligned and generates assembly based on this assumption. Of course this is incorrect if the lower layers didn't have a multiple of 4 bytes of headers. Anyway, I discovered the hard way that there are lots and lots of places in the IP code that assumes alignment, so this seems to be a rather daunting task to fix. So this patch will just be one very small piece of the puzzle. :/ (Perhaps something for kernel newbies, to track down and fix all the alignment assumptions in the IP stack?) Rgds Pierre signature.asc Description: PGP signature
Re: net: alignment problem in icmp code
On Sun, 21 Oct 2007 12:48:14 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: You are missing a crucial point. The compiler may emit the same exact loads and stores when it inlines memcpy() if it knows the objects are aligned properly. And it very much will do this. Not sure that would be valid. memcpy() is defined as having void* arguments, and the compiler cannot just ignore that if it chooses to inline it. Still, just give it the char* from the skb and it cannot make any assumption on alignment. Rgds Pierre signature.asc Description: PGP signature
Re: net: alignment problem in icmp code
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Pierre Ossman [EMAIL PROTECTED] Date: Sun, 21 Oct 2007 23:21:13 +0200 Not sure that would be valid. memcpy() is defined as having void* arguments, and the compiler cannot just ignore that if it chooses to inline it. Yes it can, there are C language rules about the alignment of types that the compiler completely can take advantage of in those kinds of situations. I'm not debating that. What I'm saying is that calling memcpy() casts your pointers to void* with the included semantical changes. It can't just ignore that because it decides to inline the function. It would be the same thing as when gcc decided to ignore the volatile qualifier on a pointer just because it could optimize away to the real object and discover it wasn't marked with volatile. Something that was considered a bug and was fixed. If you don't believe me, compile something like the following with optimizations enabled: gcc has had bugs in the past. You will get a 64-bit load and a 64-bit store emitted by the compiler. Here is what we get on sparc64: I assume those ops cause a bus error on unaligned addresses? However, instead of relying upon magic like this, let's just tell the compiler explicitly what it going on by using get_unaligned(). It wouldn't be magic: memcpy(icmp_param.data.icmph, skb_transport_header(skb), sizeof(struct icmphdr)); I believe platforms without alignment requirements could optimize this better than the series of assignments. Not that I think this will be a potential bottle neck, but still. Next, there are redundant stores being done here since the code and type are explicitly overwritten in various ways. Indeed. Rgds Pierre signature.asc Description: PGP signature
Re: net: alignment problem in icmp code
On Sun, 21 Oct 2007 22:15:24 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: Sure. But the language defines that the types in question must be 64-bit aligned, so it is legal for the compiler to emit this code. It's not a GCC bug. I've confirmed this behaviour on the AVR32 arch, and had a second look in the spec. The only way GCC can get away with this is by using a very creative interpretation of the result of casting a pointer to one type to a pointer to another type (which ISO C leaves undefined). Basically: 1. A cast from a pointer to one type to a pointer to a second type does not change the value. (GCC behaviour which we rely on heavily, even in your suggested patch). 2. A cast from a pointer to one type to a pointer to a second type changes the value so that it properly aligns with the second type. (As a cast to void*, which memcpy() requires, is safe according to ISO C, the pointer modification must be from char* to struct icmphdr*). As 1 and 2 conflict, GCC's behaviour for pointer casts is still rather undefined. So although within the requirements of ISO C, it's rather user hostile. And it casts doubt on every pointer cast used. If you want to let the compiler know that a pointer to a type might not be aligned, you have to tell it so. Which you can't do within the confines of ISO C. The get_unaligned() macro uses some GCC trickery (even outside what GCC documents as defined behaviour). To stay clean, you have to avoid casting char* to foo*. With all that said, as GCC does what it does, we can't really rely on a memcpy() anyway, so I support your patch. As for other instances of unaligned accesses, is there any active work on getting rid of those? And would you accept more patches for fixing them? (Code complexity being the downside) Rgds Pierre signature.asc Description: PGP signature
Re: net: alignment problem in icmp code
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Pierre Ossman [EMAIL PROTECTED] Date: Mon, 22 Oct 2007 10:42:08 +0200 This seems like a rather evil layering violation. This has a 10+ year precedence and it's why the Linux networking stack is so fast. If you read any other driver you would have seen the skb_reserve() call every one of them do to align the headers. The norm seems to be to not comment this call. It's hardly obvious. I think I've tolerated this long enough. Are you going keep teaching me how the C language works, how GCC interprets it, and how evil the Linux networking is, or are you going to fix the bug in your driver? :-) Settle down, bug fixed even before this discussion even began. I just don't like papering over problems so I want to know why this is needed and if it isn't indicative of a larger problem. If you don't want the discussions, make sure people know the gotchas. (And I wasn't try to teach anyone. I was giving my view on things, and if you think I'm off my meds, feel free to say so. Groveling and excessively putting every statement as a question demeans us both. ;)) Rgds Pierre signature.asc Description: PGP signature
keyboard dead with 45b5035
The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ I've tried just creating another vt with chvt 2, but that is insufficient to trigger the bug. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 20:50:01 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 18 of February 2008, Pierre Ossman wrote: The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . That solved it. I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 21:50:12 +0100 Pierre Ossman [EMAIL PROTECTED] wrote: On Mon, 18 Feb 2008 20:50:01 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 18 of February 2008, Pierre Ossman wrote: The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . That solved it. Perhaps not quite. When I returned to my laptop this morning, the keyboard was gone again. Did a hard reboot, and the machine locked up a few seconds after starting X. I'll see if it can be reproduced... Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
