On 4/13/07, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
On Friday 13 April 2007 13:16, Dmitry Torokhov wrote: > On 4/13/07, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > On Tuesday 20 February 2007 06:52, marco wrote: > > > I have a thinkpad X41-tablet which uses the linuxwacom serial drivers. > > > The tablet works perfectly when the laptop first boots, but does not work > > > at all after resuming from sleep. I posted to the linuxwacom list but > > > think that the problem might be more general in how acpi resumes the > > > serial ports. > > > > > > As suggested here: > > > http://www.thinkwiki.org/wiki/Installing_Ubuntu_6.10_on_a_ThinkPad_X41_Tablet > > > I have added a script to resume.d which calls the setserial command: > > > /bin/setserial /dev/ttyS0 port 0x0200 irq 5 autoconfig > > > > Using setserial to change port or IRQ usage is a good clue that the > > kernel is doing something wrong. Usually it's "we KNOW that ttyS0 > > lives at 0x3f8 and IRQ 4, so we'll ignore what ACPI is telling us." > > But it sounds like this is a tangent and not related to your current > > problem. > > > > Can you post the dmesg log from a boot where the tablet works > > correctly? That will tell us exactly what kernel you're running > > and how the kernel detected the serial port. There've been some > > serial port resume changes in the not-too-distant past, and I > > don't know whether they're in the Ubuntu kernel yet. > > It has nothing to do with changes to serial. Wacom driver for tablets > connected to serial ports lives completely in userspace (X) and is > completelyunaware that the box is coming out of sleep and that > conncted device needs to be reinitialized. OK, that sounds good, because if it's an X issue, it's Someone Else's Problem :-)
Exactly ;)
I'm a little concerned because Marco said that after a resume, "cat /dev/ttyS0" caused his system to hang, and not even Ctrl-Alt-Del worked. Can we blame that all on X?
No, I don't think we can. The device connected to the port is simply not re-initialized and mey either transmit garbage or not transmit data at all. However accessing the port should not hang kernel.
Would stopping the X server before suspend and restarting it after resume be a workaround?
I do not think it is feasible. If you have to shut down X you might as well shut down entire box. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
