"USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang
in [Kernel]
|
Prev: "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang
Next: crypto: make Open Firmware device id constant
From: Anssi Hannula on 22 Feb 2010 14:30 On maanantai 22 helmikuu 2010 21:10:33 Alan Stern wrote: > On Mon, 22 Feb 2010, Anssi Hannula wrote: > > I guess that would suggest that the device doesn't allow the > > initialization data to be broken into packets arbitrarily (though some > > differences seem allowed, as the windows driver transmits them > > differently). > > > > Does this mean a tty interface is ill-suited for the microcode upload, > > and instead qcserial should use the kernel's generic microcode upload > > mechanism or the userspace should use libusb to do it? > > I don't know. Didn't the old successful code use a tty interface? Yes, but does the tty interface guarantee that the data of one write call is sent as one packet to the device? If I understood this correctly, it seems the changes have caused it to now concatenate short writes into one packet, which the device doesn't seem to like. -- Anssi Hannula -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 22 Feb 2010 18:30 Am Montag, 22. Februar 2010 19:35:35 schrieb Anssi Hannula: > On maanantai 22 helmikuu 2010 17:28:36 Alan Stern wrote: > > The major difference between the logs is in the way the data get > > divided up into packets. In both the successful logs, there are > > sequences of bulk-OUT packets with lengths like: > > > > 44, 1, 15, 1, 13 > > > > where the unsuccessful transfer just has a single packet of length 74. > > Also, the successful transfers show a lot of bulk-IN traffic where the > > unsuccessful transfer doesn't have any. I don't know if that is > > relevant, however. > > > > No other differences stand out. > > I guess that would suggest that the device doesn't allow the initialization > data to be broken into packets arbitrarily (though some differences seem > allowed, as the windows driver transmits them differently). Hi, let's try testing this hypothesis. Can you change the following line in usb_serial_probe(): if (kfifo_alloc(&port->write_fifo, PAGE_SIZE, GFP_KERNEL)) goto probe_error; to: if (kfifo_alloc(&port->write_fifo, 64, GFP_KERNEL)) goto probe_error; This may shed some light on the behavior. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anssi Hannula on 22 Feb 2010 21:00 On tiistai 23 helmikuu 2010 01:26:02 Oliver Neukum wrote: > Am Montag, 22. Februar 2010 19:35:35 schrieb Anssi Hannula: > > On maanantai 22 helmikuu 2010 17:28:36 Alan Stern wrote: > > > The major difference between the logs is in the way the data get > > > divided up into packets. In both the successful logs, there are > > > > > > sequences of bulk-OUT packets with lengths like: > > > 44, 1, 15, 1, 13 > > > > > > where the unsuccessful transfer just has a single packet of length 74. > > > Also, the successful transfers show a lot of bulk-IN traffic where the > > > unsuccessful transfer doesn't have any. I don't know if that is > > > relevant, however. > > > > > > No other differences stand out. > > > > I guess that would suggest that the device doesn't allow the > > initialization data to be broken into packets arbitrarily (though some > > differences seem allowed, as the windows driver transmits them > > differently). > > Hi, > > let's try testing this hypothesis. Can you change the following line in > usb_serial_probe(): > if (kfifo_alloc(&port->write_fifo, PAGE_SIZE, GFP_KERNEL)) > goto probe_error; > > to: > > if (kfifo_alloc(&port->write_fifo, 64, GFP_KERNEL)) > goto probe_error; > > This may shed some light on the behavior. No effect. However, I added more sleep(1) calls to gobi_loader, now between every magicX string and firmware files (therefore ensuring the data gets flushed to the device at those points). Now the upload was successful. -- Anssi Hannula -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anssi Hannula on 23 Feb 2010 21:40
On maanantai 22 helmikuu 2010 22:12:41 Alan Stern wrote: > On Mon, 22 Feb 2010, Matthew Garrett wrote: > > On Mon, Feb 22, 2010 at 02:10:33PM -0500, Alan Stern wrote: > > > On Mon, 22 Feb 2010, Anssi Hannula wrote: > > > > Does this mean a tty interface is ill-suited for the microcode > > > > upload, and instead qcserial should use the kernel's generic > > > > microcode upload mechanism or the userspace should use libusb to do > > > > it? > > > > > > I don't know. Didn't the old successful code use a tty interface? > > > > Yes. The kfifo changes have caused some sort of alteration in behaviour. > > > > > > Any idea what could be causing the hang, then? > > > > > > No idea, unless it's the device. > > > > Once the device hangs, it then tends to refuse any input until power > > cycled. So it's clearly getting into some sort of undefined state, > > though whether that's because it only gets sent half of its firmware > > (ie, the hang occurs and as a result the hardware dies) or whether it's > > causing the hang by dying is unclear. > > The latest logs did show all the firmware getting sent -- or at least, > they show that as much data was sent by the nonworking driver as by the > working driver. So I'd say the device causes the hang by dying, > although I don't know where the hang is or why a dead device should > cause it. When the hang happens, the complete firmware is *not* sent to the device. The usbmon log is 10 times smaller: http://stuff.onse.fi/gobi2000/gobi-regression2.mon.log For reference, here's the hang with usbserial debug=1: http://stuff.onse.fi/gobi2000/gobi-regression2.dmesg.log The later logs were of runs that did not hang, but did still not work. I added descriptions here, in case someone is confused with all the logs (which I should've named better): http://stuff.onse.fi/gobi2000/ But if a device in corrupt state can cause such a hang, then it is likely that that is happening here (due to the packet bounding issue described in the other messages). -- Anssi Hannula -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |