Jean Tourrilhes <[EMAIL PROTECTED]> writes: > ir247_drv_region-2.diff is a cosmetic change and won't help. > That's a know problem without any good solution. It's more > generic, you have other places where two drivers can claim the same > hardware (for example irda-usb and ir-usb). The only solution is to > remove the serial module or set uart to none. > That's also why I usually advise people to try first with > irtty...
OK. Thanks for the clarification. > I don't have any SMC hardware, and no maintainer for the SMC > driver, so I will need convincing before accepting the patch. Yes, I can understand that. I was hoping there were others on this list with the same problem (there must be...), and that they could test the patch as well. I am also certainly interested if anyone can get suspend/resume working with the smc-ircc driver _without_ this change. I don't think that's possible, but I've been wrong before.. I also know you are looking for a SMC maintainer, but I still don't feel up to it. There's surely a lot to do. Just a quick glance at it shows several places where return values that should have been checked are just thrown away. And I still can't get FIR working against a irlan access point. And.. > One > question that come to mind is if the IrDA port is still working after > a resume. It does for me. That's all I can say. But I assume this depends on more than just the chip, and that there may be systems that need some sort of reinitialisation after resume. But they can achieve what the current code _tries_ to do by creating a simple /etc/apm/event.d/irda script running ifconfig. I really can't see the point of trying to do this from within the driver. Now, that may of course be just me being stupid. > I don't really understand all this Power Management stuff, but > it looks to me that in wakeup you would need to reset the chip (power > up, change speed, whatever). Also, you may want to investigate a bit > the cause of the crash (run oops through ksymoops)... Yes, I know I should have. I didn't. Sorry. And now I can't without rebooting again.... Well, I'll see if I feel like another boot later. At least what I've got leaves no doubt that the crash is in the apm system: Jan 10 19:01:27 rasputin kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Jan 10 19:01:27 rasputin kernel: printing eip: Jan 10 19:01:27 rasputin kernel: ccc6f375 Jan 10 19:01:27 rasputin kernel: *pde = 00000000 Jan 10 19:01:27 rasputin kernel: Oops: 0000 Jan 10 19:01:27 rasputin kernel: CPU: 0 Jan 10 19:01:27 rasputin kernel: EIP: 0010:[<ccc6f375>] Not tainted Jan 10 19:01:27 rasputin kernel: EFLAGS: 00210296 Jan 10 19:01:27 rasputin kernel: eax: ccc6f394 ebx: c7d7eba1 ecx: 00000000 edx: 00000000 Jan 10 19:01:27 rasputin kernel: esi: 00000000 edi: 00000003 ebp: c021d1c0 esp: c1311f48 Jan 10 19:01:27 rasputin kernel: ds: 0018 es: 0018 ss: 0018 Jan 10 19:01:27 rasputin kernel: Process kapm-idled (pid: 3, stackpage=c1311000) Jan 10 19:01:27 rasputin kernel: Stack: c011f7a6 c7d7eba0 00000000 00000003 c7d7ebbc 00000000 c7d7eba0 c011f859 Jan 10 19:01:27 rasputin kernel: c7d7eba0 00000000 00000003 0000000a 0000000a 00000002 c1311fcc c0110220 Jan 10 19:01:27 rasputin kernel: 00000000 00000003 0000000a c0110477 0000000a c1310000 00026dd2 c0110591 Jan 10 19:01:27 rasputin kernel: Call Trace: [pm_send+62/112] [pm_send_all+69/144] [send_event+32/116] [check_events+247/408] [apm_event_handler+121/124] Jan 10 19:01:27 rasputin kernel: [apm_mainloop+127/284] [apm+622/640] [kernel_thread+31/56] [kernel_thread+40/56] Jan 10 19:01:27 rasputin kernel: Jan 10 19:01:27 rasputin kernel: Code: 8b 11 f6 c6 01 74 07 45 83 ff ff 0f 44 fb 81 e2 00 02 00 00 Bj�rn _______________________________________________ Linux-IrDA mailing list - [EMAIL PROTECTED] http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
