On Fri, Apr 14, 2023 at 8:27 AM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > > > > On 4/14/2023 5:14 AM, Jim Quinlan wrote: > > On Thu, Apr 13, 2023 at 4:06 PM Cyril Brulebois <kibi@xxxxxxxxxx> wrote: > >> > >> Hi Jim, > >> > >> Jim Quinlan <jim2101024@xxxxxxxxx> (2023-04-13): > >>> Can you provide (a) the full boot log prior to applying the patch > >>> series and (b) full boot log after applying the series, using an > >>> IDENTICAL setup. If it fails on both then it has little to do with my > >>> patch series. > >> > >> Just to be clear, the issue I reported was with: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> > >> This was my minimal reproducer for the kernel panic at boot-up, which > >> goes away with either v1 or v2. When I realized I didn't actually check > >> whether the SupaHub board was working correctly, I plugged 2 devices to > >> obtain this setup: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> - Kingston DataTraveler G4 32GB on USB-A port #1 of the SupaHub board. > >> - Logitech K120 keyboard on USB-A port #2 of the SupaHub board. > >> > >> It turns out that this particular revision of the SupaHub board isn't > >> supported by xhci_hcd directly (failing to probe with error -110) and > >> one needs to enable CONFIG_USB_XHCI_PCI_RENESAS=m and also ship its > >> accompanying firmware (/lib/firmware/renesas_usb_fw.mem). With this > >> updated kernel config, I'm able to use the keyboard and to read data > >> from the memory stick without problems (70 MB/s). > >> > >>> In my last series your testing somehow conflated the effect of an > >>> unrelated MMC interrupt issue so please be precise. > >> > >> I wish things would be simpler and didn't involve combinatorics, let > >> alone other bugs/regressions at times, but I'm really trying my best to > >> navigate and report issues and test patches when I can spare some time… > > > > Hi Cyril, > > > > I want to encourage you and others doing testing and bug reporting: > > everyone wins when a bug or issue is reported, fixed, and tested. > > I'm just asking that when you have negative results, that you provide > > information on the "before" and "after" test results of > > the patch series, and run both on the same test environment. > > Cyril, based upon the table and logs you provided whereby you have used > the following: > > - Raspberry Pi Compute Module 4 (Rev 1.0, 8G RAM, 32G storage) > - Raspberry Pi Compute Module 4 IO Board > - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > > in the before/unpatched case we have a PCIe link down and in the > after/patched we have a PCIe link up but a kernel panic. Neither are > great nor resulting in a fully functional PCIe device. The data do not make sense to me. My new code is executed AFTER pcie link up/down determination. Both test results should have the same link status -- either "link up" or "link down". If the system is wishy-washy, i.e. it has link-up in 5/10 boots, then we need to repeat the experiment to compare the "link up" cases only. Or discount the test completely If the system is not wishy-washy, then something has been changed between the "before" and "after" tests. > > Looking at: > > https://www.amazon.co.uk/SupaHub-Express-BandWidth-Capable-Expanding/dp/B092ZQWG5B > > it would appear that it can accept an external power supply, do you have > one connected to that USB expansion card by any chance? Are you able to > boot the kernel before/after if you disconnect any USB peripheral? > > This looks like a broader electrical problem than the scope of this > patch, though it would be neat if we could find a combination that > works. At least with Jim's patch we have a PCIe link with > uni-directional CLKREQ# so we could try a variety of things. > > Does that SupaHub board plugged to the CM4 1.0 system work fine in the > Raspberry Pi kernel tree? > -- > Florian
