Re: Possible big endian bug in latest stable kernel

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Jan 21, 2022 at 07:13:59PM +0000, Rory Bolt wrote:
> Hello,
> 
> I am working on a big endian port to test endian cleanness on our NVMe device drivers and software. I originally performed this port on a RockPro64 with kernel 5.10.88 and the USB subsystem performed flawlessly in both big and little endian modes. Hurray!
> 
> When I upgraded to 5.15.11 (and subsequently 5.15.14 and 5.15.16) I ran into problems that appear to be endian. If I boot the exact same board/firmware/kernel in little endian mode, the USB system works correctly. If I switch to big endian, my USB attached disks are no longer usable (they are detected, read capacity commands work, but read operations time out). Interestingly, if I unplug and replug the USB attached disk, it will begin working correctly with the newer kernels in big endian mode. Looking at the output of lsusb -v, it appears there are two changes between the 5.10 and 5.15 USB stacks:
> 
> 1) Enumeration order is different. I do not believe this is a problem at all.
> 2) Link speed. The 5.10 kernels negotiate 5000M in both little and big endian configurations. The 5.15 kernels negotiate 5000M in little endian mode, but 480M in big endian mode if the device is plugged in at boot time. In big endian mode, if the device has incorrectly negotiated 480M at boot time, if I unplug and replug the drive it will negotiate 5000M and begin working.
> 
> This all leads me to suspect that during initialization, when the USB ports are being scanned, there is a big-endian error in the latest kernels. I will happily test any patches if the cause of this is obvious. I am not versed in USB or I would investigate further myself.
> 
> Below are three lsusb -v outputs:
> 
> 5.10.88 in big endian mode
> 5.15.11 in the big endian "bad state" where the device is connected at 480M
> 5.15.11 in the big endian "good state" achieved by transitioning out of the "bad state" by unplugging and re-plugging the drive.
> 

Can you use 'git bisect' between the good and bad kernel versions to
track down the offending commit here?  As you can easily reproduce this,
that would be the simplest thing to do.

thanks,

greg k-h