Re: rpi/dwc2 kernel panics
On Fri, Feb 14, 2014 at 09:33:54AM +, Nick Hudson wrote: > On 02/13/14 18:47, Andre Heider wrote: > >On Wed, Feb 12, 2014 at 08:00:18PM -0700, Stephen Warren wrote: > >>On 02/12/2014 11:52 AM, Andre Heider wrote: > >>>Hi guys, > >>> > >>>I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) > >>>merged on top to give the latest dwc2 fixes another try. > >>>Unfortunately I'm getting various crashes on system startup. Kernel boots > >>>fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the > >>>init sequence the system panics. > >>I haven't ever seen crashes like that, when running linux-next. I also > >>merged those two exact commits together and didn't see any issue in 10 > >>boot cycles. > >Same thing here with linux-next (Linux rpi 3.14.0-rc2-next-20140213-rpi). > >The last traces has systemd in there, but good old sysvinit crashed > >spectacular too. > > > >>FWIW, I am running: > >>* A rev2 Model B > >>* Firmware commit 9c3d7b6 "Add latest linaro gcc toolchain: > >>gcc-linaro-arm-linux-gnueabihf-raspbian-2012.08-20120724_linux" > >>* Upstream U-Boot (very recent) and kernel > >>* Using Ubuntu 13.10's packaged ARM cross-compiler > >Huh, switching compilers made a difference... > > > >I was using debian's cross compiler [0], 4.8.2, which has a couple of > >patches [1]. > > > >With my old self compiled and unpatched toolchains I didn't yet get > >any crashes, I tried: > >binutils 2.20+ gcc 4.4.4 > >binutils 2.21.1 + gcc 4.4.7 > >binutils 2.23.1 + gcc 4.7.1 > >binutils 2.24+ gcc 4.7.2 > > > >but with these versions (also unpatched) I do get the crashes: > >binutils 2.23.2 + gcc 4.8.1 > >binutils 2.24+ gcc 4.8.2 > > I saw problems with 4.8 on NetBSD/evbarm and my RaspberryPI. They were fixed > by changes to the gcc-4_8-branch some time after 4.8.2. It seems this is gcc bug 58854 [0]. Applying [1] to vanilla 4.8.2 fixes the panics for me. [0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [1] http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=d8e03d55d2e9801086aa8da2f9c347510aef8e11 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rpi/dwc2 kernel panics
On Fri, Feb 14, 2014 at 09:33:54AM +, Nick Hudson wrote: > On 02/13/14 18:47, Andre Heider wrote: > >On Wed, Feb 12, 2014 at 08:00:18PM -0700, Stephen Warren wrote: > >>On 02/12/2014 11:52 AM, Andre Heider wrote: > >>>Hi guys, > >>> > >>>I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) > >>>merged on top to give the latest dwc2 fixes another try. > >>>Unfortunately I'm getting various crashes on system startup. Kernel boots > >>>fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the > >>>init sequence the system panics. > >>I haven't ever seen crashes like that, when running linux-next. I also > >>merged those two exact commits together and didn't see any issue in 10 > >>boot cycles. > >Same thing here with linux-next (Linux rpi 3.14.0-rc2-next-20140213-rpi). > >The last traces has systemd in there, but good old sysvinit crashed > >spectacular too. > > > >>FWIW, I am running: > >>* A rev2 Model B > >>* Firmware commit 9c3d7b6 "Add latest linaro gcc toolchain: > >>gcc-linaro-arm-linux-gnueabihf-raspbian-2012.08-20120724_linux" > >>* Upstream U-Boot (very recent) and kernel > >>* Using Ubuntu 13.10's packaged ARM cross-compiler > >Huh, switching compilers made a difference... > > > >I was using debian's cross compiler [0], 4.8.2, which has a couple of > >patches [1]. > > > >With my old self compiled and unpatched toolchains I didn't yet get > >any crashes, I tried: > >binutils 2.20+ gcc 4.4.4 > >binutils 2.21.1 + gcc 4.4.7 > >binutils 2.23.1 + gcc 4.7.1 > >binutils 2.24+ gcc 4.7.2 > > > >but with these versions (also unpatched) I do get the crashes: > >binutils 2.23.2 + gcc 4.8.1 > >binutils 2.24+ gcc 4.8.2 > > I saw problems with 4.8 on NetBSD/evbarm and my RaspberryPI. They were fixed > by changes to the gcc-4_8-branch some time after 4.8.2. Indeed a current 4.8 snapshot builds working kernels for me: gcc version 4.8.3 20140213 (prerelease) (GCC) Do you have any more infos about this issue? Thanks, Andre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rpi/dwc2 kernel panics
On Thu, Feb 13, 2014 at 10:08:21PM -0700, Stephen Warren wrote: > On 02/13/2014 11:47 AM, Andre Heider wrote: > > On Wed, Feb 12, 2014 at 08:00:18PM -0700, Stephen Warren wrote: > >> On 02/12/2014 11:52 AM, Andre Heider wrote: > >>> Hi guys, > >>> > >>> I just tried today's Linus' master (45f7fdc2ff) with usb-linus > >>> (3635c7e2d5) > >>> merged on top to give the latest dwc2 fixes another try. > >>> Unfortunately I'm getting various crashes on system startup. Kernel boots > >>> fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the > >>> init sequence the system panics. > ... > > Which one are you using? gcc-arm-linux-gnueabi [2] or > > gcc-arm-linux-gnueabihf [3]? Maybe there's a reason the former is 4.7 > > while the latter is 4.8? > > In case you're using 4.7, care to give 4.8 a try? > > I tried gcc-arm-linux-gnueabihf from Ubuntu Saucy, and gcc-arm-none-eabi > from a Debian Unstable chroot, and got an apparently stable system, with > USB enabled and running "apt-get update" over USB network. > > With the Saucy toolchain, I did see the following 3 times, which I > haven't seen before, but the system didn't panic: > > EXT4-fs error (device mmcblk0p2) in ext4_da_write_end:2780: error 579650476 I've seen some variant of that too. Maybe the issue is similar to the last one, where the kernel layout is relevant. Attached my current .config, maybe you can reproduce with that. (I bumped the stack protector option to "strong" for my last gcc 4.9 test drive, downgrade to regular). Thanks, Andre config.gz Description: Binary data
Re: rpi/dwc2 kernel panics
On Thu, Feb 13, 2014 at 07:47:27PM +0100, Andre Heider wrote: > In any case, I'm hesitant to blame this on a compiler bug since > booting any of those kernels with "nousb" didn't yet end is weird > panics. Then again, everything seems just fine with: gcc version 4.9.0 20140209 (experimental) (GCC) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rpi/dwc2 kernel panics
On Wed, Feb 12, 2014 at 08:00:18PM -0700, Stephen Warren wrote: > On 02/12/2014 11:52 AM, Andre Heider wrote: > > Hi guys, > > > > I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) > > merged on top to give the latest dwc2 fixes another try. > > Unfortunately I'm getting various crashes on system startup. Kernel boots > > fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the > > init sequence the system panics. > > I haven't ever seen crashes like that, when running linux-next. I also > merged those two exact commits together and didn't see any issue in 10 > boot cycles. Same thing here with linux-next (Linux rpi 3.14.0-rc2-next-20140213-rpi). The last traces has systemd in there, but good old sysvinit crashed spectacular too. > FWIW, I am running: > * A rev2 Model B > * Firmware commit 9c3d7b6 "Add latest linaro gcc toolchain: > gcc-linaro-arm-linux-gnueabihf-raspbian-2012.08-20120724_linux" > * Upstream U-Boot (very recent) and kernel > * Using Ubuntu 13.10's packaged ARM cross-compiler Huh, switching compilers made a difference... I was using debian's cross compiler [0], 4.8.2, which has a couple of patches [1]. With my old self compiled and unpatched toolchains I didn't yet get any crashes, I tried: binutils 2.20 + gcc 4.4.4 binutils 2.21.1 + gcc 4.4.7 binutils 2.23.1 + gcc 4.7.1 binutils 2.24 + gcc 4.7.2 but with these versions (also unpatched) I do get the crashes: binutils 2.23.2 + gcc 4.8.1 binutils 2.24 + gcc 4.8.2 Which one are you using? gcc-arm-linux-gnueabi [2] or gcc-arm-linux-gnueabihf [3]? Maybe there's a reason the former is 4.7 while the latter is 4.8? In case you're using 4.7, care to give 4.8 a try? In any case, I'm hesitant to blame this on a compiler bug since booting any of those kernels with "nousb" didn't yet end is weird panics. Thanks, Andre [0] https://packages.debian.org/unstable/gcc-arm-none-eabi [1] http://anonscm.debian.org/gitweb/?p=collab-maint/gcc-arm-none-eabi.git;a=tree;f=debian/patches [2] http://packages.ubuntu.com/saucy/devel/gcc-arm-linux-gnueabi [3] http://packages.ubuntu.com/saucy/devel/gcc-arm-linux-gnueabihf -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rpi/dwc2 kernel panics
Hi guys, I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) merged on top to give the latest dwc2 fixes another try. Unfortunately I'm getting various crashes on system startup. Kernel boots fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the init sequence the system panics. Hard to say when exactly, but it looks like it's happening upon setting up the usb ethernet adapter (with dhcp in my case). It doesn't crash on every boot, maybe 3 in 10 times. And it doesn't seem to crash when booting with "nousb", at least not so far. Do the traces below ring any bell? Thanks, Andre [4.299074] Unable to handle kernel paging request at virtual address e313002c [4.311206] pgd = d7a4c000 [4.318606] [e313002c] *pgd= [4.326872] Internal error: Oops: 5 [#1] ARM [4.335802] CPU: 0 PID: 41 Comm: systemd-cgroups Not tainted 3.14.0-rc2-rpi+ #33 [4.347972] task: d7a24000 ti: d7a1e000 task.ti: d7a1e000 [4.358101] PC is at inode_permission+0x18/0x54 [4.367294] LR is at unix_find_other+0x54/0x1c0 [4.376423] pc : []lr : []psr: 2013 [4.376423] sp : d7a1fe80 ip : d7a1fe90 fp : d7a1fe8c [4.397063] r10: r9 : d7a1e000 r8 : c04fc488 [4.406784] r7 : d7a1ff04 r6 : 0002 r5 : e3130010 r4 : [4.417816] r3 : c00e6c60 r2 : 0004 r1 : 0002 r0 : e3130010 [4.428785] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [4.440448] Control: 00c5387d Table: 17a4c008 DAC: 0015 [4.450734] Process systemd-cgroups (pid: 41, stack limit = 0xd7a1e1b8) [4.461869] Stack: (0xd7a1fe80 to 0xd7a2) [4.470656] fe80: d7a1febc d7a1fe90 c033c1c0 c00e4674 d79fbb40 c02b9d50 c00e538c c00e6c60 [4.483433] fea0: c033d80c d79fbb40 d7558580 001e d7a1fef4 d7a1fec0 c033e904 c033c178 [4.496224] fec0: c000ea24 d7a1fecc c000ea24 001e 001d d7558580 001d c04dc00c [4.509034] fee0: bead9c84 c000ea24 d7a1ffa4 d7a1fef8 c02b7c74 c033e86c d79fbb40 [4.521849] ff00: 722f0001 732f6e75 65747379 6a2f646d 6e72756f 732f6c61 656b636f [4.534715] ff20: c00d0074 c00f4314 fff7 d7a1ff78 d7a1ff7c d7a1ff54 2b00f9de [4.547651] ff40: c00f4314 0001 0004 d7558580 0007 bead9c60 d7a1e000 [4.560624] ff60: d7a1ffa4 d7a1ff70 c02b8118 c02bb9b4 0004 d7a1ff80 [4.573643] ff80: c01df21c 2b00f9de bead9c86 b6f86f10 00016010 011b d7a1ffa8 [4.586697] ffa0: c000e800 c02b7c00 bead9c86 b6f86f10 bead9c84 001d [4.599704] ffc0: bead9c86 b6f86f10 00016010 011b b6f87000 [4.612690] ffe0: bead9c7c a1c4 b6ea07ac 4010 17ffd821 17ffdc21 [4.625747] [] (inode_permission) from [] (unix_find_other+0x54/0x1c0) [4.638971] [] (unix_find_other) from [] (unix_dgram_connect+0xa4/0x1e0) [4.652398] [] (unix_dgram_connect) from [] (SyS_connect+0x80/0xbc) [4.665441] [] (SyS_connect) from [] (ret_fast_syscall+0x0/0x30) [4.678194] Code: e24cb004 e52de004 e8bd4000 e3110002 (e590201c) [4.689255] ---[ end trace 4cdca67b25fe5ac6 ]--- note the corrupt process name on this one: [9.242673] Unable to handle kernel paging request at virtual address e313002c [9.254126] pgd = d7b38000 [9.260862] [e313002c] *pgd= [9.268450] Internal error: Oops: 5 [#1] ARM [9.276689] CPU: 0 PID: 154 Comm: (ystemctl) Not tainted 3.14.0-rc2-rpi+ #33 [9.287829] task: d7b3eec0 ti: d604 task.ti: d604 [9.297317] PC is at inode_permission+0x18/0x54 [9.305991] LR is at unix_find_other+0x54/0x1c0 [9.314686] pc : []lr : []psr: 2013 [9.314686] sp : d6041e68 ip : d6041e78 fp : d6041e74 [9.334610] r10: r9 : 001e r8 : d759b2c0 [9.344132] r7 : 7fff r6 : 0001 r5 : e3130010 r4 : [9.355028] r3 : c00e6c60 r2 : 0004 r1 : 0002 r0 : e3130010 [9.365886] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [9.377401] Control: 00c5387d Table: 17b38008 DAC: 0015 [9.387548] Process (ystemctl) (pid: 154, stack limit = 0xd60401b8) [9.398222] Stack: (0xd6041e68 to 0xd6042000) [9.406954] 1e60: d6041ea4 d6041e78 c033c1c0 c00e4674 7fff d759b2c0 [9.419738] 1e80: c00e538c c00e6c60 c02ba5f4 d7ae2000 d7ae2d20 d7a40300 d6041ef4 d6041ea8 [9.432623] 1ea0: c033db90 c033c178 c04dc00c d6041ec4 c04fc488 d6041efc d6041f04 001d [9.445525] 1ec0: c04dc00c fff4 c000ea24 d759b2c0 001d c04dc00c beda2404 c000ea24 [9.458411] 1ee0: d604 d6041fa4 d6041ef8 c02b7c74 c033daa4 d6041f24 [9.471280] 1f00: 722f0001 732f6e75 65747379 6a2f646d 6e72756f 732f6c61 756f6474 [9.484200] 1f20: c00d0074 c00dd310 c04dce60 d759b2c0 d759b2c0 d6041f7c d6041f48 [9.497087] 1f40: c02b69c0 c00dd430 d780d470 d76433b8
[PATCH] usb: dwc2: bail out early when booting with "nousb"
Add usb_disabled() check to prevent kernel oops when booting with "nousb"
in the cmdline:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at bus_add_device+0xe0/0x18c
LR is at device_add_groups+0x1c/0x20
...
[] (bus_add_device) from [] (device_add+0x41c/0x538)
[] (device_add) from [] (usb_new_device+0x270/0x35c)
[] (usb_new_device) from [] (usb_add_hcd+0x4fc/0x760)
[] (usb_add_hcd) from [] (dwc2_hcd_init+0x434/0x510)
[] (dwc2_hcd_init) from [] (dwc2_driver_probe+0x130/0x170)
[] (dwc2_driver_probe) from []
(platform_drv_probe+0x28/0x58)
Signed-off-by: Andre Heider
Acked-by: Paul Zimmerman
---
drivers/usb/dwc2/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d01d0d3..eaba547 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
+ if (usb_disabled())
+ return -ENODEV;
+
match = of_match_device(dwc2_of_match_table, &dev->dev);
if (match && match->data) {
params = match->data;
--
1.9.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc2: bail out early when booting with "nousb"
On Tue, Feb 04, 2014 at 08:10:19PM +, Paul Zimmerman wrote: > > From: Andre Heider [mailto:a.hei...@gmail.com] > > Sent: Tuesday, February 04, 2014 10:44 AM > > > > Add usb_disabled() check to prevent kernel oops when booting with "nousb" > > in the cmdline: > > Hi Andre, > > Please resend this with GregKH on Cc, since he is the maintainer of the > USB tree and is the one who will apply the patch. You can add my: > > Acked-by: Paul Zimmerman Okay, thanks -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc2: bail out early when booting with "nousb"
Add usb_disabled() check to prevent kernel oops when booting with "nousb"
in the cmdline:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at bus_add_device+0xe0/0x18c
LR is at device_add_groups+0x1c/0x20
...
[] (bus_add_device) from [] (device_add+0x41c/0x538)
[] (device_add) from [] (usb_new_device+0x270/0x35c)
[] (usb_new_device) from [] (usb_add_hcd+0x4fc/0x760)
[] (usb_add_hcd) from [] (dwc2_hcd_init+0x434/0x510)
[] (dwc2_hcd_init) from [] (dwc2_driver_probe+0x130/0x170)
[] (dwc2_driver_probe) from []
(platform_drv_probe+0x28/0x58)
Signed-off-by: Andre Heider
---
drivers/usb/dwc2/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d01d0d3..eaba547 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
+ if (usb_disabled())
+ return -ENODEV;
+
match = of_match_device(dwc2_of_match_table, &dev->dev);
if (match && match->data) {
params = match->data;
--
1.9.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Move DWC2 driver out of staging
On Mon, Feb 03, 2014 at 08:51:48PM +, Paul Zimmerman wrote: > > From: Paul Zimmerman > > Sent: Monday, February 03, 2014 9:36 AM > > > >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] > >> Sent: Saturday, February 01, 2014 7:44 PM > >> > >> On 02/01/2014 03:00 AM, Andre Heider wrote: > >>> On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote: > >>>> On 01/31/2014 11:12 AM, Andre Heider wrote: > >>>>> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote: > >>>>>> The DWC2 driver should now be in good enough shape to move out of > >>>>>> staging. I have stress tested it overnight on RPI running mass > >>>>>> storage and Ethernet transfers in parallel, and for several days > >>>>>> on our proprietary PCI-based platform. > >>>> ... > >>>>> this looks just fine, but for whatever reason it breaks sdhci on my rpi. > >>>>> With today's Linus' master the dwc2 controller seems to initialize fine, > >>>>> but I get this upon boot: > >>>>> > >>>>> [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12 > >>>>> [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error > >>>>> -12 > >> ... > >>>> This is due to the following code: > >> ... > >>>> What ends up happening, simply due to memory allocation order, is that > >>>> the memory writes inside usb_settoggle() end up setting the SDHCI struct > >>>> platform_device's num_resources to 0, so that it's call to > >>>> platform_get_resource() fails. > >>>> > >>>> With the DWC2 move patch reverted, some other random piece of memory is > >>>> being corrupted, which just happens not to cause any visible problem. > >>>> Likely it's some other struct platform_device that's already had its > >>>> resources read by the time DWC2 probes and corrupts them. > >>>> > >>>> (Yes, this was hard to find!) > >>> > >>> Nice work, but how did you pinpoint this? Am I missing some option/tool > >>> or did I just not stare for long enough? > >> > >> Well, there was a clear place where an issue was present; the resource > >> lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs > >> into that function to dump out the data platform_get_resource() used. > >> This clearly pointed at num_resources==0 being the problem. Next, I > >> dumped the same data from the code in drivers/of that sets it up, and it > >> was OK there, so I knew it was getting over-written somewhere. I then > >> basically added hundreds of calls to the same data dumping function > >> throughout kernel functions like really_probe() to track down the > >> location of the problem. Luckily, the behaviour was stable, so I wasn't > >> chasing a race/timing condition. Eventually I narrowed the window to the > >> few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would > >> have been much harder if it was e.g. the USB HW DMAing to memory that > >> caused the corruption, so I was lucky:-) > > > > Nice work Stephen, thanks. I will try to come up with a patch to fix this > > ASAP, along the lines of what Alan suggested. > > Stephen, Andre, > > Can you test the attached patch, please? It works for my on the Synopsys > PCIe-based FPGA board. Unfortunately my RPI board is currently broken, > so I am unable to test it there to verify it actually fixes the problem > you are seeing. > > The dwc2 driver doesn't use the usb_device toggle bits anywhere else, > so the quickest fix is to just remove the problematic code from > _dwc2_hcd_endpoint_reset(). > > If you give me your tested-bys, I will submit this as a proper patch > to Greg. LGTM, sdhci works again and there're no glaring USB issues with lan, hid nor mass storage: Tested-by: Andre Heider Thanks Paul, Andre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Move DWC2 driver out of staging
On Mon, Feb 03, 2014 at 08:51:48PM +, Paul Zimmerman wrote: > > From: Paul Zimmerman > > Sent: Monday, February 03, 2014 9:36 AM > > > >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] > >> Sent: Saturday, February 01, 2014 7:44 PM > >> > >> On 02/01/2014 03:00 AM, Andre Heider wrote: > >>> On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote: > >>>> On 01/31/2014 11:12 AM, Andre Heider wrote: > >>>>> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote: > >>>>>> The DWC2 driver should now be in good enough shape to move out of > >>>>>> staging. I have stress tested it overnight on RPI running mass > >>>>>> storage and Ethernet transfers in parallel, and for several days > >>>>>> on our proprietary PCI-based platform. > >>>> ... > >>>>> this looks just fine, but for whatever reason it breaks sdhci on my rpi. > >>>>> With today's Linus' master the dwc2 controller seems to initialize fine, > >>>>> but I get this upon boot: > >>>>> > >>>>> [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12 > >>>>> [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error > >>>>> -12 > >> ... > >>>> This is due to the following code: > >> ... > >>>> What ends up happening, simply due to memory allocation order, is that > >>>> the memory writes inside usb_settoggle() end up setting the SDHCI struct > >>>> platform_device's num_resources to 0, so that it's call to > >>>> platform_get_resource() fails. > >>>> > >>>> With the DWC2 move patch reverted, some other random piece of memory is > >>>> being corrupted, which just happens not to cause any visible problem. > >>>> Likely it's some other struct platform_device that's already had its > >>>> resources read by the time DWC2 probes and corrupts them. > >>>> > >>>> (Yes, this was hard to find!) > >>> > >>> Nice work, but how did you pinpoint this? Am I missing some option/tool > >>> or did I just not stare for long enough? > >> > >> Well, there was a clear place where an issue was present; the resource > >> lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs > >> into that function to dump out the data platform_get_resource() used. > >> This clearly pointed at num_resources==0 being the problem. Next, I > >> dumped the same data from the code in drivers/of that sets it up, and it > >> was OK there, so I knew it was getting over-written somewhere. I then > >> basically added hundreds of calls to the same data dumping function > >> throughout kernel functions like really_probe() to track down the > >> location of the problem. Luckily, the behaviour was stable, so I wasn't > >> chasing a race/timing condition. Eventually I narrowed the window to the > >> few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would > >> have been much harder if it was e.g. the USB HW DMAing to memory that > >> caused the corruption, so I was lucky:-) > > > > Nice work Stephen, thanks. I will try to come up with a patch to fix this > > ASAP, along the lines of what Alan suggested. > > Stephen, Andre, > > Can you test the attached patch, please? It works for my on the Synopsys > PCIe-based FPGA board. Unfortunately my RPI board is currently broken, > so I am unable to test it there to verify it actually fixes the problem > you are seeing. > > The dwc2 driver doesn't use the usb_device toggle bits anywhere else, > so the quickest fix is to just remove the problematic code from > _dwc2_hcd_endpoint_reset(). > > If you give me your tested-bys, I will submit this as a proper patch > to Greg. I'll give it a spin this evening, thanks. Is that really just redundant code or could this removal have side effects? Should I look out for anything specific? Oh, and I'm not sure if I poked the right spot with the "nousb" fix, but I'll send that out as well. Regards, Andre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Move DWC2 driver out of staging
On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
> On 01/31/2014 11:12 AM, Andre Heider wrote:
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> >> The DWC2 driver should now be in good enough shape to move out of
> >> staging. I have stress tested it overnight on RPI running mass
> >> storage and Ethernet transfers in parallel, and for several days
> >> on our proprietary PCI-based platform.
> ...
> > this looks just fine, but for whatever reason it breaks sdhci on my rpi.
> > With today's Linus' master the dwc2 controller seems to initialize fine,
> > but I get this upon boot:
> >
> > [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
> > [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
> >
> > That is:
> >
> > struct sdhci_host *sdhci_pltfm_init(struct platform_device
> > *pdev,
> > const struct
> > sdhci_pltfm_data *pdata,
> > size_t priv_size)
> > {
> > ...
> >
> > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!iomem) {
> > ret = -ENOMEM;
> > goto err;
> > }
>
> This is due to the following code:
>
> static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
>struct usb_host_endpoint *ep)
> {
> struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> ...
> struct usb_device *udev;
> ...
> udev = to_usb_device(hsotg->dev);
> ...
> usb_settoggle(udev, epnum, is_out, 0);
> if (is_control)
> usb_settoggle(udev, epnum, !is_out, 0);
>
> The problem is that hsotg->dev is assigned as follows:
>
> static int dwc2_driver_probe(struct platform_device *dev)
> ...
> hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
> ...
> hsotg->dev = &dev->dev;
>
> As such, it's not legal to call to_usb_device() on it.
>
> What ends up happening, simply due to memory allocation order, is that
> the memory writes inside usb_settoggle() end up setting the SDHCI struct
> platform_device's num_resources to 0, so that it's call to
> platform_get_resource() fails.
>
> With the DWC2 move patch reverted, some other random piece of memory is
> being corrupted, which just happens not to cause any visible problem.
> Likely it's some other struct platform_device that's already had its
> resources read by the time DWC2 probes and corrupts them.
>
> (Yes, this was hard to find!)
Nice work, but how did you pinpoint this? Am I missing some option/tool
or did I just not stare for long enough?
> I honestly can't see how to solve this myself, since the whole DWC2
> driver doesn't seem to have a struct usb_device * hanging around that we
> can stash somewhere for it to look up later. Perhaps someone more
> familiar with the USB stack can help with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Move DWC2 driver out of staging
On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > Hi,
> >
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > > The DWC2 driver should now be in good enough shape to move out of
> > > staging. I have stress tested it overnight on RPI running mass
> > > storage and Ethernet transfers in parallel, and for several days
> > > on our proprietary PCI-based platform.
> > >
> > > Signed-off-by: Paul Zimmerman
> > > ---
> > > v4: Also change directory path in MAINTAINERS
> > >
> > > Greg,
> > > I believe I have addressed all of the feedback since I last
> > > submitted this. Is there still time to do this before you
> > > close your trees?
> > >
> > > MAINTAINERS | 2 +-
> > > drivers/staging/Kconfig | 2 --
> > > drivers/staging/Makefile | 1 -
> > > drivers/staging/dwc2/TODO | 33
> > > ---
> > > drivers/usb/Kconfig | 2 ++
> > > drivers/usb/Makefile | 1 +
> > > drivers/{staging => usb}/dwc2/Kconfig | 0
> > > drivers/{staging => usb}/dwc2/Makefile| 0
> > > drivers/{staging => usb}/dwc2/core.c | 0
> > > drivers/{staging => usb}/dwc2/core.h | 0
> > > drivers/{staging => usb}/dwc2/core_intr.c | 0
> > > drivers/{staging => usb}/dwc2/hcd.c | 0
> > > drivers/{staging => usb}/dwc2/hcd.h | 0
> > > drivers/{staging => usb}/dwc2/hcd_ddma.c | 0
> > > drivers/{staging => usb}/dwc2/hcd_intr.c | 0
> > > drivers/{staging => usb}/dwc2/hcd_queue.c | 0
> > > drivers/{staging => usb}/dwc2/hw.h| 0
> > > drivers/{staging => usb}/dwc2/pci.c | 0
> > > drivers/{staging => usb}/dwc2/platform.c | 0
> > > 19 files changed, 4 insertions(+), 37 deletions(-)
> > > delete mode 100644 drivers/staging/dwc2/TODO
> > > rename drivers/{staging => usb}/dwc2/Kconfig (100%)
> > > rename drivers/{staging => usb}/dwc2/Makefile (100%)
> > > rename drivers/{staging => usb}/dwc2/core.c (100%)
> > > rename drivers/{staging => usb}/dwc2/core.h (100%)
> > > rename drivers/{staging => usb}/dwc2/core_intr.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd.h (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_ddma.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_intr.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_queue.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hw.h (100%)
> > > rename drivers/{staging => usb}/dwc2/pci.c (100%)
> > > rename drivers/{staging => usb}/dwc2/platform.c (100%)
> >
> > this looks just fine, but for whatever reason it breaks sdhci on my rpi.
> > With today's Linus' master the dwc2 controller seems to initialize fine,
> > but I get this upon boot:
> >
> > [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
> > [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
> >
> > That is:
> >
> > struct sdhci_host *sdhci_pltfm_init(struct platform_device
> > *pdev,
> > const struct
> > sdhci_pltfm_data *pdata,
> > size_t priv_size)
> > {
> > ...
> >
> > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!iomem) {
> > ret = -ENOMEM;
> > goto err;
> > }
> >
> > ...
> >
> > So far it's 100% reproducible. No further infos since my root device
> > went away. Same behavior with bcm2835_defconfig.
> >
> > Bisecting points to this commit, and if I move this driver back to
> > staging (revert 197ba5f406cc) usb and sdhci are both working properly.
> >
> > Without the revert, this patch on top...
> >
> > diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> > index d01d0d3..eaba547 100644
> > --- a/drivers/usb/dwc2/platform.c
> > +++ b/drivers/usb/dwc2/platform.c
> > @@
Re: [PATCH v4] Move DWC2 driver out of staging
On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > Hi,
> >
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > > The DWC2 driver should now be in good enough shape to move out of
> > > staging. I have stress tested it overnight on RPI running mass
> > > storage and Ethernet transfers in parallel, and for several days
> > > on our proprietary PCI-based platform.
> > >
> > > Signed-off-by: Paul Zimmerman
> > > ---
> > > v4: Also change directory path in MAINTAINERS
> > >
> > > Greg,
> > > I believe I have addressed all of the feedback since I last
> > > submitted this. Is there still time to do this before you
> > > close your trees?
> > >
> > > MAINTAINERS | 2 +-
> > > drivers/staging/Kconfig | 2 --
> > > drivers/staging/Makefile | 1 -
> > > drivers/staging/dwc2/TODO | 33
> > > ---
> > > drivers/usb/Kconfig | 2 ++
> > > drivers/usb/Makefile | 1 +
> > > drivers/{staging => usb}/dwc2/Kconfig | 0
> > > drivers/{staging => usb}/dwc2/Makefile| 0
> > > drivers/{staging => usb}/dwc2/core.c | 0
> > > drivers/{staging => usb}/dwc2/core.h | 0
> > > drivers/{staging => usb}/dwc2/core_intr.c | 0
> > > drivers/{staging => usb}/dwc2/hcd.c | 0
> > > drivers/{staging => usb}/dwc2/hcd.h | 0
> > > drivers/{staging => usb}/dwc2/hcd_ddma.c | 0
> > > drivers/{staging => usb}/dwc2/hcd_intr.c | 0
> > > drivers/{staging => usb}/dwc2/hcd_queue.c | 0
> > > drivers/{staging => usb}/dwc2/hw.h| 0
> > > drivers/{staging => usb}/dwc2/pci.c | 0
> > > drivers/{staging => usb}/dwc2/platform.c | 0
> > > 19 files changed, 4 insertions(+), 37 deletions(-)
> > > delete mode 100644 drivers/staging/dwc2/TODO
> > > rename drivers/{staging => usb}/dwc2/Kconfig (100%)
> > > rename drivers/{staging => usb}/dwc2/Makefile (100%)
> > > rename drivers/{staging => usb}/dwc2/core.c (100%)
> > > rename drivers/{staging => usb}/dwc2/core.h (100%)
> > > rename drivers/{staging => usb}/dwc2/core_intr.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd.h (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_ddma.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_intr.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hcd_queue.c (100%)
> > > rename drivers/{staging => usb}/dwc2/hw.h (100%)
> > > rename drivers/{staging => usb}/dwc2/pci.c (100%)
> > > rename drivers/{staging => usb}/dwc2/platform.c (100%)
> >
> > this looks just fine, but for whatever reason it breaks sdhci on my rpi.
> > With today's Linus' master the dwc2 controller seems to initialize fine,
> > but I get this upon boot:
> >
> > [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
> > [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
> >
> > That is:
> >
> > struct sdhci_host *sdhci_pltfm_init(struct platform_device
> > *pdev,
> > const struct
> > sdhci_pltfm_data *pdata,
> > size_t priv_size)
> > {
> > ...
> >
> > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!iomem) {
> > ret = -ENOMEM;
> > goto err;
> > }
> >
> > ...
> >
> > So far it's 100% reproducible. No further infos since my root device
> > went away. Same behavior with bcm2835_defconfig.
> >
> > Bisecting points to this commit, and if I move this driver back to
> > staging (revert 197ba5f406cc) usb and sdhci are both working properly.
> >
> > Without the revert, this patch on top...
> >
> > diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> > index d01d0d3..eaba547 100644
> > --- a/drivers/usb/dwc2/platform.c
> > +++ b/drivers/usb/dwc2/platform.c
> > @@ -
Re: [PATCH v4] Move DWC2 driver out of staging
Hi,
On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> The DWC2 driver should now be in good enough shape to move out of
> staging. I have stress tested it overnight on RPI running mass
> storage and Ethernet transfers in parallel, and for several days
> on our proprietary PCI-based platform.
>
> Signed-off-by: Paul Zimmerman
> ---
> v4: Also change directory path in MAINTAINERS
>
> Greg,
> I believe I have addressed all of the feedback since I last
> submitted this. Is there still time to do this before you
> close your trees?
>
> MAINTAINERS | 2 +-
> drivers/staging/Kconfig | 2 --
> drivers/staging/Makefile | 1 -
> drivers/staging/dwc2/TODO | 33
> ---
> drivers/usb/Kconfig | 2 ++
> drivers/usb/Makefile | 1 +
> drivers/{staging => usb}/dwc2/Kconfig | 0
> drivers/{staging => usb}/dwc2/Makefile| 0
> drivers/{staging => usb}/dwc2/core.c | 0
> drivers/{staging => usb}/dwc2/core.h | 0
> drivers/{staging => usb}/dwc2/core_intr.c | 0
> drivers/{staging => usb}/dwc2/hcd.c | 0
> drivers/{staging => usb}/dwc2/hcd.h | 0
> drivers/{staging => usb}/dwc2/hcd_ddma.c | 0
> drivers/{staging => usb}/dwc2/hcd_intr.c | 0
> drivers/{staging => usb}/dwc2/hcd_queue.c | 0
> drivers/{staging => usb}/dwc2/hw.h| 0
> drivers/{staging => usb}/dwc2/pci.c | 0
> drivers/{staging => usb}/dwc2/platform.c | 0
> 19 files changed, 4 insertions(+), 37 deletions(-)
> delete mode 100644 drivers/staging/dwc2/TODO
> rename drivers/{staging => usb}/dwc2/Kconfig (100%)
> rename drivers/{staging => usb}/dwc2/Makefile (100%)
> rename drivers/{staging => usb}/dwc2/core.c (100%)
> rename drivers/{staging => usb}/dwc2/core.h (100%)
> rename drivers/{staging => usb}/dwc2/core_intr.c (100%)
> rename drivers/{staging => usb}/dwc2/hcd.c (100%)
> rename drivers/{staging => usb}/dwc2/hcd.h (100%)
> rename drivers/{staging => usb}/dwc2/hcd_ddma.c (100%)
> rename drivers/{staging => usb}/dwc2/hcd_intr.c (100%)
> rename drivers/{staging => usb}/dwc2/hcd_queue.c (100%)
> rename drivers/{staging => usb}/dwc2/hw.h (100%)
> rename drivers/{staging => usb}/dwc2/pci.c (100%)
> rename drivers/{staging => usb}/dwc2/platform.c (100%)
this looks just fine, but for whatever reason it breaks sdhci on my rpi.
With today's Linus' master the dwc2 controller seems to initialize fine,
but I get this upon boot:
[1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
[1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
That is:
struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
const struct
sdhci_pltfm_data *pdata,
size_t priv_size)
{
...
iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!iomem) {
ret = -ENOMEM;
goto err;
}
...
So far it's 100% reproducible. No further infos since my root device
went away. Same behavior with bcm2835_defconfig.
Bisecting points to this commit, and if I move this driver back to
staging (revert 197ba5f406cc) usb and sdhci are both working properly.
Without the revert, this patch on top...
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d01d0d3..eaba547 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
+ if (usb_disabled())
+ return -ENODEV;
+
match = of_match_device(dwc2_of_match_table, &dev->dev);
if (match && match->data) {
params = match->data;
...and "nousb" in the cmdline (with crashes without the patch), sdhci works
again. I don't see any obvious clues, any idea what's going on?
Regards,
Andre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Haswell C2, xHCI and S3
Hi list, blunt question, because I'm about to assemble a new Haswell box and I wonder if waiting for C2 boards makes sense: Does Linux care about the apparent C1 stepping xHCI bug [1]? Are workarounds required for the kernel? If so, does C2 get rid of them? [1] http://www.guru3d.com/news_story/intel_confirms_haswell_chipset_usb_bug.html Thanks in advance, Andre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
