On Tue, Jun 11, 2019 at 07:26:54PM +0200, Fredrik Noring wrote: > Hi Guenter, > > > > This patch results in usb access failures when trying to boot from the > > > sm501-usb controller on sh4 with qemu. > > > > > > usb 1-2.1: reset full-speed USB device number 4 using sm501-usb > > > sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 > > > sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 08 7c 00 00 f0 00 > > > print_req_error: I/O error, dev sda, sector 2172 flags 80700 > > > usb 1-2.1: reset full-speed USB device number 4 using sm501-usb > > > sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 > > > sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 da 00 00 f0 00 > > > print_req_error: I/O error, dev sda, sector 474 flags 84700 > > > usb 1-2.1: reset full-speed USB device number 4 using sm501-usb > > > sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 > > > sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 02 da 00 00 f0 00 > > > print_req_error: I/O error, dev sda, sector 730 flags 84700 > > > usb 1-2.1: reset full-speed USB device number 4 using sm501-usb > > > sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 > > > sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 0b 50 00 00 f0 00 > > > print_req_error: I/O error, dev sda, sector 2896 flags 84700 > > > > > > Qemu command line is: > > > > > > The qemu command line is: > > > > > > qemu-system-sh4 -M r2d \ > > > -kernel ./arch/sh/boot/zImage \ > > > -snapshot \ > > > -usb -device usb-storage,drive=d0 \ > > > -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > > > -append 'panic=-1 slub_debug=FZPUA root=/dev/sda rootwait console=ttySC1,115200 earlycon=scif,mmio16,0xffe80000 noiotrap' \ > > > -serial null -serial stdio \ > > > -net nic,model=rtl8139 -net user -nographic -monitor null > > > > > > Reverting this patch as well as "USB: drop HCD_LOCAL_MEM flag" fixes the > > > problem. Reverting "USB: drop HCD_LOCAL_MEM flag" alone does not help. > > > > > > > This problem is still seen in next-20190611. > > Has anyone actually tested this code ? > > I tested patches 1, 2 and 5 with v5.0.19. Perhaps yet another part of the > OHCI subsystem allocates memory from the wrong pool? With some luck it is > relatively easy to trace backwards from the error messages to the point > where the memory is being allocated. One way to establish this is to > sprinkle printk around if-statements. There may be 10-20 levels of calls > including one or two indirect calls via pointers. Would you be able to do > that? > I don't think I'll have time to do that anytime soon. Not that I know what exactly to look for in the first place. Can you do that debugging yourself ? All you would need is a cross-compiler (eg from kernel.org), qemu, and a working configuration (the root file system doesn't really matter since the code doesn't get to the point of loading it, but you can use [1]). For the configuration file, you can use rts7751r2dplus_defconfig with CONFIG_CMDLINE and CONFIG_CMDLINE_OVERWRITE removed. Thanks, Guenter --- [1] https://github.com/groeck/linux-build-test/blob/master/rootfs/sh/rootfs.ext2.gz
