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? Fredrik
