Fredag 24 september 2010 21:45:28 skrev du: > Did you check the dmesg log? Did you make sure that the modified > driver module was loaded? I will check again. > The logs do show a difference. It involves the baud rate; the > not_working log sets a baud rate of 115200 whereas the working log sets > a baud rate of 9600. That's the problem with using "cat" on a serial > port -- you have no control over the port settings. Instead you should > use a program designed for serial ports, like minicom. Sure. I did make a small application that just openens the device and closes it again which the same result. > I don't know why the higher baud rate caused the open call to block. > And I don't know what caused the difference in baud rates. It could be > some other program completely, like a network manager trying to use the > serial port for a network link. It that correct. AFAIK the baudrate is set after getting af filedescriptor from the open call - at least from a user-space perspective. Correct me of I'm wrong :) I have tried it in single user mode and open still blocks, so I guess that other applications are not a problem. Reloading pl2303 and usbserial brings thing in a working state in any runlevel. Reloading pl2303 only is not enough, so maybe it relates to usbserial too. I will add DEBUG in that source file also I think. > > If you want. You started this conversation by posting to linux-usb. > Instead you could have added linux-usb to the bug report's CC list and > held the conversation that way. I would be happy to add the list to this bug but bugzilla tells me that the list address does not match anything. -- /Søren Holm -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
