Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
On 17-01-02 07:40 PM, Ansis Atteka wrote: .. > I think that I am getting closer to the root cause of this bug. Also, > I have a workaround that at least makes r8152 functionally stable in > my Dell TB15 dock. Mark, would you mind giving a chance to the patch > that I have in the bottom of this email to see if it helps your issue > too (you might have to tweak those settings slightly differently if > you use something else than USB 3.0) /* USB_RX_EARLY_TIMEOUT */ -#define COALESCE_SUPER 85000U -#define COALESCE_HIGH 25U -#define COALESCE_SLOW 524280U +#define COALESCE_SUPER 8500U +#define COALESCE_HIGH 25000U +#define COALESCE_SLOW 52428U The RTL_VER_02 chip that I was using does not support interrupt coalescing in the driver [see the rtl8152_set_coalesce() function]. So that workaround would not help here. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord <ml...@pobox.com> > > I find an issue about autosuspend, and it may result in the same > problem with you. I don't sure if this is helpful to you, because > it only occurs when enabling the autosuspend. Thanks. I am using ASIX adapters now. I did try the latest 4.9-rc8, and 4.8.12 kernels with the r8152 dongle yesterday, in hope that perhaps the many EHCI fixes from those kernels might help out. The dongle was unusable with those newer kernels. Most of the time it failed with "Get ether addr fail\n" at startup. On the occasions where it got past that point, it often failed the DHCP negotiation, but this looks more like a bug elsewhere in the kernel, possibly racing against initialization of the random number generators. Adding a 2-second sleep the the r8151 probe function made this error mostly go away. Cheers -- Mark Lord -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 09:22 AM, Greg KH wrote: > On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: >> On 16-11-25 07:34 AM, Mark Lord wrote: >>> On 16-11-25 04:53 AM, Greg KH wrote: >>>> Note, there are "cheap" USB monitors that can be quite handy and that work >>>> on Linux: >>>>http://www.totalphase.com/products/beagle-usb12/ >>> >>> USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle. >> >> Oh, wrong model. That one doesn't do USB2. >> The USB2 version is a mere USD$1300 in quantity. >> >> Seems like rather a lot of money just to report a bug in a USB driver. >> Perhaps the Linux Foundation might purchase one and loan it for this task? > > You already have access to a USB analyzer you said, why would I try to > buy one and ship it around the world instead? Makes no sense... No, the company where I am consulting has a paperweight called a "USB analyzer". It doesn't work with Linux machines. You are the one who suggested purchase of a working Linux compatible unit, so I was just following up to see if you were serious about that. No worries. I'll see if the paperweight can be converted into something useful next week. Cheers -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 04:52 AM, Hayes Wang wrote: .. > What is the value of /sys/bus/usb/devices/.../power/control ? That entry does not exist -- power control is completely disabled on this board. Good try, though -- USB power control still causes me trouble on PCs with mice and remote controls. But not here. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 04:53 AM, Greg KH wrote: > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >> There is no possibility for them to be used for anything other than >> USB receive buffers, for this driver only. Nothing in the driver >> or kernel ever writes to those buffers after initial allocation, >> and only the driver and USB host controller ever have pointers to the >> buffers. > > You really are going to have to break out that USB monitor to verify > that this is the data coming across the wire. Not sure why, because there really is no other way for the data to appear where it does at the beginning of that URB buffer. This does seem a rather unexpected burden to place upon someone reporting a regression in a USB network driver that corrupts user data. I have already spent about 50 hours looking at this issue, and everything now points firmly at some kind of FIFO overflow within the dongle itself. There is no evidence to the contrary. I am very happy to test any driver updates, or data collection mods provided by the author, to help the author find/fix the issue. One idea, might be to have the author try testing with the dongle connected through a USB1.1 hub, forcing it to slower speeds. This might make reproducing the issue (if indeed a FIFO overflow) easier, as the host transfers will then be slower than the ethernet wire speed. I have access to the hardware here next Tuesday. If we can scrounge up the USB analyzer, cables, and a suitable MS-Windows (ugh) machine of some kind, then I'll see if it can be programmed to somewhow capture the event. Probably just set it in continuous capture mode, and have the target system halt when it sees bad data at offset zero. This can take days to reproduce, so don't hold your breaths. Something useful to do in the meanwhile, is to then think about "what next" after the analyzer confirms the issue. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 07:34 AM, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: >> Note, there are "cheap" USB monitors that can be quite handy and that work >> on Linux: >> http://www.totalphase.com/products/beagle-usb12/ > > USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle. Oh, wrong model. That one doesn't do USB2. The USB2 version is a mere USD$1300 in quantity. Seems like rather a lot of money just to report a bug in a USB driver. Perhaps the Linux Foundation might purchase one and loan it for this task? -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 01:51 AM, Hayes Wang wrote: > > Forgive me. I provide wrong information. This is about RTL8153, not RTL8152. No problem. Thanks for trying though. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 04:53 AM, Greg KH wrote: > Note, there are "cheap" USB monitors that can be quite handy and that work on > Linux: > http://www.totalphase.com/products/beagle-usb12/ USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-25 01:11 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> If that "return 0" statement is ever executed, doesn't it result >> in the loss/leak of a buffer? > > They would be found back by calling rtl_start_rx(), when the rx > is restarted. Good. I figured it was probably something like that, but wasn't entirely sure about the control flow around stop/restart there. 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
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 07:27 PM, Francois Romieu wrote: > > Through aliasing the URB was given a page that contains said (previously) > received file. The ethernet chip/usb host does not write anything in it. I don't see how that could be possible. Please elaborate. The URB buffers are statically allocated by the driver at probe time, ten of them in all, allocated with usb_alloc_coherent() in the copy of the driver I am testing with. There is no possibility for them to be used for anything other than USB receive buffers, for this driver only. Nothing in the driver or kernel ever writes to those buffers after initial allocation, and only the driver and USB host controller ever have pointers to the buffers. -- Mark Lord -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 02:00 PM, Greg KH wrote: > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote: >> One thought: bulk data streams are byte streams, not packets. >> Scheduling on the USB bus can break up larger transfers across >> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes. >> The driver is providing 16384-byte buffers, and assumes that data will >> never spill over from one such buffer to the next. >> Yet the observations here consistently show otherwise. > > Wait, how do you know that data will not spill over? What is making > that guarantee? Will the USB device send a "zero packet" in order to > show that all of the "logical" data is now sent for this specific > endpoint? Is there some sort of "framing" that the device does with the > USB data so that the driver "knows" where the end of packet is? Exactly my point. > Check the zero-packet stuff for this device, that's tripped up many a > USB driver writer over the years, myself included. I haven't tripped over it myself, but only because we were careful to allow for such in the USB drivers I have worked on. The r8152 driver just assumes it never happens. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 01:42 PM, Greg KH wrote: > > Have you tried using usbmon? This system is running rootfs over NFS, so usbmon isn't realistically going to be usable in that scenario without a lot of reconfiguration of the setup (which in itself might obscure the original problem). There is a hardware USB analyzer in the building though. But it requires a MS-Windows machine (very scarce here, I don't have one) for the incredibly user-unfriendly software. I'm not sure if it can be setup to stop the trace somehow at the right point either, as it takes overnight runs usually to catch an occurrence of the issue. I also seem to recall that it only exports data captures in a proprietary format that only that brand of software/device can read, but perhaps that might not be true. Would still need to find a MS-Windows machine/license to even check it out though. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 01:34 PM, Mark Lord wrote: >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). Slight correction: the invalidate_dcache_range() is only done when using kmalloc'd buffers. I have converted the driver here to use usb_alloc_coherent() instead, so that now gets skipped since the memory is never cached. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord <ml...@pobox.com> > Date: Thu, 24 Nov 2016 11:43:53 -0500 > >> So even if this were a platform memory coherency issue, one should >> still never see ASCII data at the beginning of an rx buffer. > > I'm not so convinced, since this is the kind of random corruption one > would expect to see when dealing with virtual caches that have > aliasing or similar issues. > > Writes to address X that show up at address Y or not at all are > precisely the signature of virtual cache aliasing problems. > > Is it a case of the chip writing to X but the cpu is still seeing > stale data from a previous CPU store? > > For NFS the cpu is writing into the page cache, so we know that > cpu side stores are where the ASCII text is coming from. > > Now is the r8152 buffer one that the USB host controller is DMA'ing > into directly, or is it one that SWIOMMU or similar bounce buffering > is copying into? In the latter case we are doing cpu stores into > the area and the writes aren't coming from the device. >From tracing through the powerpc arch code, this is the buffer that is being directly DMA'd into. And the USB layer does an invalidate_dcache on that entire buffer before initiating the DMA (confirmed via printk). The driver itself NEVER writes anything to that buffer, and nobody else has a pointer to it other than the USB host controller, so there's nothing else that can write to it either. According to the driver writer, the chip should only ever write a fresh rx_desc struct at the beginning of a buffer, never ASCII data. So how does that buffer end up containing ASCII data from the NFS transfers? The only explanation I can see, is if the URB itself contains the data that we see in the URB buffer. Which is what one would expect. So for that to happen, the ethernet chip must be transferring that data. The thing that is special about the situation here, is that the processor is very slow (800Mhz 32-bit powerpc), and very busy elsewhere. So it can easily fall way behind in servicing the ethernet dongle, something that never happens with most modern faster machines. So perhaps this results in a FIFO overflow somewhere in the chip. We can boot/run this same machine from a USB memory stick, and nary a problem. Ditto for other types of ethernet dongles. But boot/run from that specific ethernet dongle, and we get regular random segfaults from corrupted page fetches over NFS. The only end-to-end data integrity available here is the rx checksum, when verified by software rather than trusting it to the chip/driver. One thought: bulk data streams are byte streams, not packets. Scheduling on the USB bus can break up larger transfers across multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes. The driver is providing 16384-byte buffers, and assumes that data will never spill over from one such buffer to the next. Yet the observations here consistently show otherwise. Cheers -- Mark Lord -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 11:43 AM, Mark Lord wrote: .. But how does this ASCII data end up at offset zero of the rx buffer?? Not possible -- this isn't even stale data, because only an rx_desc could be at that offset in that buffer. Answering my own question here, I suspect it ends up there as a result of overrunning the previous URB. So I have updated the test copy of the driver here now to check for that exact situation. It's running now, but could take hours or a day for the bug to occur again. It seems I am being overly helpful here. Perhaps I should have just stopped with the original regression report (driver works in 3.12.xx, fails on all newer kernels, as a result of enabling hardware checksums). Had I left it there, one might reasonably expect the onus to be on the driver developer to sort it out, with me providing retests of supplied patches as need be. But I've gone WAY BEYOND that, even questioning the sanity of the platform on which it is being used, just to avoid blaming a buggy USB dongle for some other issue. And this is leading people to suspect that I really think the platform is buggy. It isn't. It's been running for years, with a variety of USB hardware attached, and nary a problem. Except with this r8152 dongle on kernels > 3.12. So, yeah, the driver is fixed in our local tree, and has been for some time now. I just was hoping that perhaps others might be interested in it too, since the bug (whatever it is) corrupts data on the NFS server. Cheers -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 11:21 AM, David Miller wrote: From: Hayes WangDate: Thu, 24 Nov 2016 13:26:55 + I don't think the garbage results from our driver or device. This is my impression with what has been presented so far as well. It's not garbage. The latest run with the debug code I posted here earlier just spat out this below. Using coherent (guarded, non-cacheable) RX buffers, with mb() calls: [ 15.199157] r8152_check_rx_desc: rx_desc looks bad. [ 15.204270] r8152_rx_bottom: offset=0/3376 bad rx_desc [ 15.209584] r8152_dump_rx_desc: 3d435253 3034336d 202f3a30 47524154 2f3d5445 3034336d rx_len=21075 The bad data in this case is ASCII: "SRC=m3400:/ TARGET=/m340" This data is what is seen in /run/mount/utab, a file that is read/written over NFS on each boot. "SRC=m3400:/ TARGET=/m3400 ROOT=/ ATTRS=nolock,addr=192.168.8.1\n" But how does this ASCII data end up at offset zero of the rx buffer?? Not possible -- this isn't even stale data, because only an rx_desc could be at that offset in that buffer. So even if this were a platform memory coherency issue, one should still never see ASCII data at the beginning of an rx buffer. The driver NEVER writes anything to the rx buffers. Only the USB hardware ever does. And only the r8152 dongle/driver exhibits this issue. Other USB dongles do not. They *might* still have such issues, but because they use software checksums, the bad packets are caught/rejected. The r8152 driver, without the debug/error-checking additions, would have tried to interpret that ASCII data as an "rx_desc", and would have interpreted the "checksum bits" therein as "valid checksum", and the packet would have passed through the network stack, corrupting data. This driver worked without noticeable issues in 3.12.xx. It hasn't worked since. Because it now trusts the hardware checksums, without first checking to see if noise-on-the-line or something else has corrupted the data before receipt in the rx buffer. Based on the above capture, I suspect a bug in the chip itself, which perhaps is only manifest on a very slow CPU. Nobody here tests with slow CPUs, but they are very prevalent in embedded space. And very few people use USB network dongles nowadays either, as nearly all "computers" have built-in networking. The market for USB network dongles is mostly embedded space. Ergo. Cheers -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 08:26 AM, Hayes Wang wrote: .. Besides, it doesn't seem to occur for all platforms. I have tested the iperf more than 26 hours, and it still works fine. I think I would get the same result on x86 or x86_64 platform. .. x86 has near fully-coherent memory, so it is the "easy" platform to get things working on. But Linux supports a very diverse number of platforms, with varying degrees of cache/memory coherency, and it can be tricky for things to work correctly on all of them. If you are testing with the driver as currently in 4.4.34, then you won't even notice when things are screwing up, because the driver just silently drops packets. Or it passes them on without noticing that they have bad data. Here (attached) is the instrumented driver I am using here now. I suggest you use it or something similar when testing, and not the stock driver. This one has also been converted to use non-cacheable RAM for the receive buffers -- something that is probably a Good Thing for it to do regardless of this investigation. It also never drops a packet without logging the event, so we can see just how often there's an issue. This version behaves almost perfectly here, but I am still experimenting to see what is actually necessary, and what is not. In particular, there are some mb() calls I had put in there that shouldn't be required, so I have yet to try removing them again and see what changes. It takes at least an overnight run to pop up one or two errors, so do expect to hear back again until after the weekend at this point. Also, unrelated, but inside r8152_submit_rx() there is this code: /* The rx would be stopped, so skip submitting */ if (test_bit(RTL8152_UNPLUG, >flags) || !test_bit(WORK_ENABLE, >flags) || !netif_carrier_ok(tp->netdev)) return 0; If that "return 0" statement is ever executed, doesn't it result in the loss/leak of a buffer? Thanks /* * Copyright (c) 2014 Realtek Semiconductor Corp. All rights reserved. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* Information for net-next */ #define NETNEXT_VERSION "08" /* Information for net */ #define NET_VERSION "2" #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION #define DRIVER_AUTHOR "Realtek linux nic maintainers" #define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" #define MODULENAME "r8152" #define R8152_PHY_ID 32 #define PLA_IDR 0xc000 #define PLA_RCR 0xc010 #define PLA_RMS 0xc016 #define PLA_RXFIFO_CTRL0 0xc0a0 #define PLA_RXFIFO_CTRL1 0xc0a4 #define PLA_RXFIFO_CTRL2 0xc0a8 #define PLA_DMY_REG0 0xc0b0 #define PLA_FMC 0xc0b4 #define PLA_CFG_WOL 0xc0b6 #define PLA_TEREDO_CFG 0xc0bc #define PLA_MAR 0xcd00 #define PLA_BACKUP 0xd000 #define PAL_BDC_CR 0xd1a0 #define PLA_TEREDO_TIMER 0xd2cc #define PLA_REALWOW_TIMER 0xd2e8 #define PLA_LEDSEL 0xdd90 #define PLA_LED_FEATURE 0xdd92 #define PLA_PHYAR 0xde00 #define PLA_BOOT_CTRL 0xe004 #define PLA_GPHY_INTR_IMR 0xe022 #define PLA_EEE_CR 0xe040 #define PLA_EEEP_CR 0xe080 #define PLA_MAC_PWR_CTRL 0xe0c0 #define PLA_MAC_PWR_CTRL2 0xe0ca #define PLA_MAC_PWR_CTRL3 0xe0cc #define PLA_MAC_PWR_CTRL4 0xe0ce #define PLA_WDT6_CTRL 0xe428 #define PLA_TCR0 0xe610 #define PLA_TCR1 0xe612 #define PLA_MTPS 0xe615 #define PLA_TXFIFO_CTRL 0xe618 #define PLA_RSTTALLY 0xe800 #define PLA_CR 0xe813 #define PLA_CRWECR 0xe81c #define PLA_CONFIG12 0xe81e /* CONFIG1, CONFIG2 */ #define PLA_CONFIG34 0xe820 /* CONFIG3, CONFIG4 */ #define PLA_CONFIG5 0xe822 #define PLA_PHY_PWR 0xe84c #define PLA_OOB_CTRL 0xe84f #define PLA_CPCR 0xe854 #define PLA_MISC_0 0xe858 #define PLA_MISC_1 0xe85a #define PLA_OCP_GPHY_BASE 0xe86c #define PLA_TALLYCNT 0xe890 #define PLA_SFF_STS_7 0xe8de #define PLA_PHYSTATUS 0xe908 #define PLA_BP_BA 0xfc26 #define PLA_BP_0 0xfc28 #define PLA_BP_1 0xfc2a #define PLA_BP_2 0xfc2c #define PLA_BP_3 0xfc2e #define PLA_BP_4 0xfc30 #define PLA_BP_5 0xfc32 #define PLA_BP_6 0xfc34 #define PLA_BP_7 0xfc36 #define PLA_BP_EN 0xfc38 #define USB_USB2PHY 0xb41e #define USB_SSPHYLINK2 0xb428 #define USB_U2P3_CTRL 0xb460 #define USB_CSR_DUMMY1 0xb464 #define USB_CSR_DUMMY2 0xb466 #define USB_DEV_STAT 0xb808 #define USB_CONNECT_TIMER 0xcbf8 #define USB_BURST_SIZE 0xcfc0 #define USB_USB_CTRL 0xd406 #define USB_PHY_CTRL 0xd408 #define USB_TX_AGG 0xd40a #define USB_RX_BUF_TH 0xd40c #define USB_USB_TIMER 0xd428 #define USB_RX_EARLY_TIMEOUT 0xd42c #define USB_RX_EARLY_SIZE 0xd42e #define USB_PM_CTRL_STATUS 0xd432 #define USB_TX_DMA 0xd434 #define USB_TOLERANCE 0xd490 #define USB_LPM_CTRL 0xd41a #define USB_UPS_CTRL
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-23 02:29 PM, Mark Lord wrote: On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: static void r8153_set_rx_early_size(struct r8152 *tp) { u32 mtu = tp->netdev->mtu; u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4; ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data); } This only works for RTL8153. However, what you use is RTL8152. It is like delay completion. It is used to reduce the loading of CPU by letting a transfer contain more data to reduce the number of transfers. How is ocp_data used by the hardware? Shouldn't the calculation also include sizeof(rx_desc) in there somewhere? The algorithm is from our hw engineers, and it should be (agg_buf_sz - packet size) / 8 You could refer to commit a59e6d815226 ("r8152: correct the rx early size"). Thanks. Right now I am working quite hard trying to narrow things down exactly. You are correct that the driver does appear to be careful about accesses beyond the filled portion of a URB buffer -- for some reason I thought the original driver had issues there, but looking again it does not seem to. One idea that is now looking more likely: Things could be suffering from speculative CPU accesses to RAM (the system here has non-coherent d-cache/RAM). This could incorrectly pre-load data from adjacent URB buffers into the d-cache, creating coherency issues. I am testing now with cacheline-sized guard zones between the buffers to see if that is the issue or not. Nope. Guard zones did not fix it, so it's probably not a prefetch issue. Oddly, adding a couple of memory barriers to specific places in the driver does help, A LOT. Still not 100%, but it did pass 1800 reboot tests over night with only three bad rx_desc's reported. That's a new record here for the driver using kmalloc'd buffers, and put reliability on par with using non-cacheable buffers. Any way we look at it though, the chip/driver are simply unreliable, and relying upon hardware checksums (which fail due to the driver looking at garbage rather than the checksum bits) leads to data corruption. Cheers -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-23 10:12 AM, Hayes Wang wrote: Mark Lord [ml...@pobox.com] [...] What does this code do: static void r8153_set_rx_early_size(struct r8152 *tp) { u32 mtu = tp->netdev->mtu; u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4; ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data); } This only works for RTL8153. However, what you use is RTL8152. It is like delay completion. It is used to reduce the loading of CPU by letting a transfer contain more data to reduce the number of transfers. How is ocp_data used by the hardware? Shouldn't the calculation also include sizeof(rx_desc) in there somewhere? The algorithm is from our hw engineers, and it should be (agg_buf_sz - packet size) / 8 You could refer to commit a59e6d815226 ("r8152: correct the rx early size"). Thanks. Right now I am working quite hard trying to narrow things down exactly. You are correct that the driver does appear to be careful about accesses beyond the filled portion of a URB buffer -- for some reason I thought the original driver had issues there, but looking again it does not seem to. One idea that is now looking more likely: Things could be suffering from speculative CPU accesses to RAM (the system here has non-coherent d-cache/RAM). This could incorrectly pre-load data from adjacent URB buffers into the d-cache, creating coherency issues. I am testing now with cacheline-sized guard zones between the buffers to see if that is the issue or not. Worth repeating: other dongles we have tried, eg. those using the asix driver, do not cause us any troubles here. Only the r8152 dongles do. The other drivers do not use hardware checksums, so even if they did incur similar bad packets, whatever the reason, those bad packets would be detected/rejected by the Linux network stack (software checksums). So everything appears to behave fine with them, as it does with the r8152 driver when hardware checksums are disabled. Still trying to understand exactly how these errors are happening. It takes a very long time to do a conclusive test of anything here, and I only have the hardware for a day or two a week. So my apologies if I am slow in getting back to you on stuff. Cheers -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
What does this code do: >static void r8153_set_rx_early_size(struct r8152 *tp) >{ >u32 mtu = tp->netdev->mtu; >u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4; > >ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data); >} How is ocp_data used by the hardware? Shouldn't the calculation also include sizeof(rx_desc) in there somewhere? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-18 07:03 AM, Mark Lord wrote: On 16-11-18 02:57 AM, Hayes Wang wrote: .. Besides, the maximum data length which the RTL8152 would send to the host is 16KB. That is, if the agg_buf_sz is 16KB, the host wouldn't split it. However, you still see problems for it. How does the RTL8152 know that the limit is 16KB, rather than some other number? Is this a hardwired number in the hardware, or is it a parameter that the software sends to the chip during initialization? .. The first issue is that a packet sometimes begins in one URB, and completes in the next URB, without an rx_desc at the start of the second URB. This I have already reported earlier. Long run tests over the weekend, with the invalidate_dcache_range() call before the inner loop of r8152_rx_bottom(), turned up a few instances where packets were truncated inside a 16384 byte URB buffer, without filling the URB. [10.293228] r8152_rx_bottom: 4278 corrupted urb: head=9d21 urb_offset=2856/3376 pkt_len(1518) exceeds remainder(496) [10.304523] r8152_dump_rx_desc: 044805ee 4008 006005dc 0602 rx_len=1518 .. [ 16.660431] r8152_rx_bottom: 7802 corrupted urb: head=9d1f8000 urb_offset=1544/2064 pkt_len(1518) exceeds remainder(496) [ 16.671719] r8152_dump_rx_desc: 044805ee 4048 004005dc 46020006 rx_len=1518 The r8152.c driver attempted to build skb's for the entire packet size, even though the 1518-byte packets had only 496-bytes of data in the URB. It is not clear what the chip did with the rest of the packets in question, but the next URBs in each case began with a new/real rx_desc and new packet. There were also unconnected events during the test runs where the test code noticed totally invalid rx_desc structs in the middles of URBs. The stock driver would again have attempted to treat those as "valid" (ugh). .. [ 10.273906] r8152_check_rx_desc: rx_desc looks bad. [ 10.279012] r8152_rx_bottom: 4338 corrupted urb. head=9d21 urb_offset=2856/3376 len_used=2880 [ 10.288196] r8152_dump_rx_desc: 312e3239 382e3836 0a20382e 3d435253 3034336d 202f3a30 rx_len=12857 .. [7.184565] r8152_check_rx_desc: rx_desc looks bad. [7.189657] r8152_rx_bottom: 1678 corrupted urb. head=9d21 urb_offset=2856/3376 len_used=2880 [7.198852] r8152_dump_rx_desc: a1388402 803c9001 84380810 a67c5c4c a77c782b c64c782b rx_len=1026 .. [ 10.351251] r8152_check_rx_desc: rx_desc looks bad. [ 10.356356] r8152_rx_bottom: 4397 corrupted urb. head=9d20c000 urb_offset=4400/7984 len_used=4424 [ 10.365543] r8152_dump_rx_desc: 312e3239 382e3836 0a20382e 3d435253 3034336d 202f3a30 rx_len=12857 .. [ 10.518119] r8152_check_rx_desc: rx_desc looks bad. [ 10.523204] r8152_rx_bottom: 4458 corrupted urb. head=9d21 urb_offset=4400/7984 len_used=4424 [ 10.532416] r8152_dump_rx_desc: 54544120 6e3d5352 636f6c6f 65762c6b 343d7372 6464612c rx_len=16672 .. But the driver, as written, sometimes accesses bytes outside of the 16KB URB buffer, because it trusts the non-existent rx_desc in these cases, and also because it accesses bytes from the rx_desc without first checking whether there is sufficient remaining space in the URB to hold an rx_desc. These incorrect accesses sometimes touch memory outside of the URB buffer. Since the driver allocates all of its rx URB buffers at once, they are highly likely to be physically (and therefore virtually) adjacent in memory. So mistakenly accessing beyond the end of one buffer will often result in a read from memory of the next URB buffer. Which causes a portion of it to be loaded in the the D-cache. When that URB is subsequently filled by DMA, there then exists a data-consistency issue: the D-cache contains stale information from before the latest DMA cycle. So this explains the strange memory behaviour observed earlier on. When I add a call to invalidate_dcache_range() to the driver just before it begins examining a new rx URB, the problems go away. So this confirms the observations. Using non-cacheable RAM also makes the problem go away. But neither is a fix for the real buffer overrun accesses in the driver. Fix the "packet spans URBs" bug, and fix the driver to ALWAYS test lengths/ranges before accessing the actual buffer, and everything should begin working reliably. -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-18 02:57 AM, Hayes Wang wrote: .. > Besides, the maximum data length which the RTL8152 would send to > the host is 16KB. That is, if the agg_buf_sz is 16KB, the host > wouldn't split it. However, you still see problems for it. How does the RTL8152 know that the limit is 16KB, rather than some other number? Is this a hardwired number in the hardware, or is it a parameter that the software sends to the chip during initialization? I have a USB analyzer, but it is difficult to figure out how to program an appropriate trigger point for the capture, since the problem (with 16KB URBs) takes minutes to hours or even days to trigger. And the output from the analyzer is in some proprietary format. The in-kernel software analzer could be useful, but I have never figured out how to use it. :) Since my earlier email, I have figured out another piece of the puzzle with this dongle. The first issue is that a packet sometimes begins in one URB, and completes in the next URB, without an rx_desc at the start of the second URB. This I have already reported earlier. But the driver, as written, sometimes accesses bytes outside of the 16KB URB buffer, because it trusts the non-existent rx_desc in these cases, and also because it accesses bytes from the rx_desc without first checking whether there is sufficient remaining space in the URB to hold an rx_desc. These incorrect accesses sometimes touch memory outside of the URB buffer. Since the driver allocates all of its rx URB buffers at once, they are highly likely to be physically (and therefore virtually) adjacent in memory. So mistakenly accessing beyond the end of one buffer will often result in a read from memory of the next URB buffer. Which causes a portion of it to be loaded in the the D-cache. When that URB is subsequently filled by DMA, there then exists a data-consistency issue: the D-cache contains stale information from before the latest DMA cycle. So this explains the strange memory behaviour observed earlier on. When I add a call to invalidate_dcache_range() to the driver just before it begins examining a new rx URB, the problems go away. So this confirms the observations. Using non-cacheable RAM also makes the problem go away. But neither is a fix for the real buffer overrun accesses in the driver. Fix the "packet spans URBs" bug, and fix the driver to ALWAYS test lengths/ranges before accessing the actual buffer, and everything should begin working reliably. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-17 09:14 AM, Mark Lord wrote: .. Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent), Note that the same behaviour also happens with the original kmalloc'd buffers. I can get it to fail extremely regularly by simply reducing the buffer size (agg_buf_sz) from 16KB down to 4KB. This makes reproducing the issue much much easier -- the same problems do happen with the larger 16KB size, but much less often than with smaller sizes. Increasing the buffer size to 64KB makes the problem much less frequent, as one might expect. Thus far I haven't seen it happen at all, but a longer run (1-3 days) is needed to make sure. This however is NOT a "fix". So.. with a 4KB URB transfer_buffer size, along with a ton of added error-checking, I see this behaviour every 10 (rx) URBs or so: First URB (number 593): [ 34.260667] r8152_rx_bottom: 593 corrupted urb: head=bf014000 urb_offset=2856/4096 pkt_len(1518) exceeds remainder(1216) [ 34.271931] r8152_dump_rx_desc: 044805ee 4008 006005dc 0602 rx_len=1518 Next URB (number 594): [ 34.281172] r8152_check_rx_desc: rx_desc looks bad. [ 34.286228] r8152_rx_bottom: 594 corrupted urb. head=bf018000 urb_offset=0/304 len_used=24 [ 34.294774] r8152_dump_rx_desc: 8300 8400 8500 8600 8700 8800 rx_len=768 What the above sample shows, is the URB transfer buffer ran out of space in the middle of a packet, and the hardware then tried to just continue that same packet in the next URB, without an rx_desc header inserted. The r8152.c driver always assumes the URB buffer begins with an rx_desc, so of course this behaviour produces really weird effects, and system crashes, etc.. So until that driver bug is addressed, I would advise disabling hardware RX checksums for all chip versions, not only for version 02. It is not clear to me how the chip decides when to forward an rx URB to the host. If you could describe how that part works for us, then it would help in further understanding why fast systems (eg. a PC) don't generally notice the issue, while much slower embedded systems do see the issue regularly. That last part is critical to understanding things: How does the chip decide that a URB is "full enough" before sending it to the host? Why does a really fast host see fewer packets jammed together into a single URB than a slower host? The answers will help understand if there are more bugs to be found/fixed, or if everything is explained by what has been observed thus far. To recap: the hardware sometimes fills a URB to the very end, and then continues the current packet at the first byte of the following URB. The r8152.c driver does NOT handle this situation; instead it always interprets the first 24 bytes of every URB as an "rx_desc" structure, without any kind of sanity/validation. This results in buffer overruns (it trusts the packet length field, even though the URB is too small to hold such a packet), and other semi-random behaviour. Using software rx checksums prevents Bad Things(tm) happening from most of this, but even that is not perfect given the severity of the bug. Cheers -- 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 net 2/2] r8152: rx descriptor check
On 16-11-13 03:34 PM, Mark Lord wrote: > > The system I use it with is a 32-bit ppc476, with non-coherent RAM, > and using 16KB page sizes. > > The dongle instantly becomes a lot more reliable when r8152.c is updated > to use usb_alloc_coherent() for URB buffers, rather than kmalloc(). > > Not sure why that would be though, as the USB stack normally would handle > kmalloc'd buffers just fine. It is calling the appropriate routines, > which boil down to invalidating the dcache lines (for inbound bulk xfers) > as part of usb_submit_urb(), and yet the problem there persists. > > It could be caused by cache-line sharing with other allocations, but that > seems > unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver > is somehow accessing the buffer space again after doing usb_submit_urb()? > That would certainly produce this kind of behaviour. > > Or maybe there's just a memory barrier missing somewhere in path. > > The really weird thing is that ASIX-based dongles (which use a different > driver) > don't have this problem, and yet they also use kmalloc'd buffers. > > I have access to the test system only for a day or two a week, > and it takes a few hours to do a good test as to whether something helps or > not. > I'll continue to poke at it as time and New Ideas permit. Oh, and the problems did not exist with the 3.14.xx kernels and earlier. They began to show up when we tried 3.16.xx and all newer kernels. The difference there is that RX checksums were enabled in hardware as of 3.16.xx, and thus the network stack began accepting bad packets from the r8152 driver. I don't know if the ASIX driver uses hardware checksums or just software checksums. That might explain why it is more reliable here. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 2/2] r8152: rx descriptor check
On 16-11-13 12:39 PM, David Miller wrote: > From: Hayes Wang <hayesw...@realtek.com> > Date: Fri, 11 Nov 2016 15:15:41 +0800 > >> For some platforms, the data in memory is not the same with the one >> from the device. That is, the data of memory is unbelievable. The >> check is used to find out this situation. >> >> Signed-off-by: Hayes Wang <hayesw...@realtek.com> > > I'm all for adding consistency checks, but I disagree with proceeding > in this manner for this. > > If you add this patch now, there is a much smaller likelyhood that you > will work with a high priority to figure out _why_ this is happening. > > For all we know this could be a platform bug in the DMA API for the > systems in question. > > It could also be a bug elsewhere in the driver, either in setting up > the descriptor DMA mappings or how the chip is programmed. > > Either way the true cause must be found before we start throwing > changes like this into the driver. I agree. The system I use it with is a 32-bit ppc476, with non-coherent RAM, and using 16KB page sizes. The dongle instantly becomes a lot more reliable when r8152.c is updated to use usb_alloc_coherent() for URB buffers, rather than kmalloc(). Not sure why that would be though, as the USB stack normally would handle kmalloc'd buffers just fine. It is calling the appropriate routines, which boil down to invalidating the dcache lines (for inbound bulk xfers) as part of usb_submit_urb(), and yet the problem there persists. It could be caused by cache-line sharing with other allocations, but that seems unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver is somehow accessing the buffer space again after doing usb_submit_urb()? That would certainly produce this kind of behaviour. Or maybe there's just a memory barrier missing somewhere in path. The really weird thing is that ASIX-based dongles (which use a different driver) don't have this problem, and yet they also use kmalloc'd buffers. I have access to the test system only for a day or two a week, and it takes a few hours to do a good test as to whether something helps or not. I'll continue to poke at it as time and New Ideas permit. New Ideas welcome! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 2/2] r8152: rx descriptor check
On 16-11-11 07:13 AM, Francois Romieu wrote: > Hayes Wang <hayesw...@realtek.com> : >> For some platforms, the data in memory is not the same with the one >> from the device. That is, the data of memory is unbelievable. The >> check is used to find out this situation. > > Invalid packet size corrupted receive descriptors in Realtek's device > reminds of CVE-2009-4537. > > Is the silicium of both devices different enough to prevent the same > exploit to happen ? I don't know if the hardware can do it, but the existing Linux device driver regularly attempts to process huge unreal packet sizes here. I've had to patch it to reject "packets" larger than the configured MRU. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: xhci and other woes
On 14-02-04 02:10 PM, Sarah Sharp wrote: On Mon, Feb 03, 2014 at 04:45:14PM +, David Laight wrote: From the end of section 4.10.1.1 (Short transfers) - If the Short Packet occurred while processing a Transfer TRB with only an ISP flag set, then two events shall be generated for the transfer; one for the Transfer TRB that the short packet occurred on, and a second for the last TRB with the IOC flag set. - Software shall not interpret an Short Packet Event as indicating that the TD that it is associated with is “complete”, unless the TRB Pointer field of the Transfer Event references the last TRB of the TD. And there's code in the xHCI driver to ignore the second successful event. See ep-last_td_was_short. Yes, this is a slight race condition, and we should wait for the successful event. However, we have not seen any issues with this race condition. Which means that the controller is obeying the rules, and the software is wrong. .. In this case, the bug has been worked around (not perfectly), but we've had no customer reports that this is an issue. There is no user-visible impact as far as we know. So fixing this race condition is a really low priority for me, and the fix would have to very minimally touch the driver. .. There are a gazillion reports out there (google) that using any XHCI controller other than the NEC chip (and some Intel chips) causes instability, in particular when using the AMD and VIA chips. Right now, Linux USB3 has a very bad reputation -- buggy and unstable. If there's a bug we/you know about, then let's get it fixed. It could help some of those anonymous reports. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: [RFT] xHCI TD fragment revert
On 14-02-04 03:11 PM, Sarah Sharp wrote: Hi Mark and David, Can you test the following two patches against 3.13? Please make sure the adapter works when it's plugged directly into a USB 3.0 port and when it's plugged into a USB 2.0 hub. .. are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 3.13-td-changes-reverted for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20: I tested against the git tree (rather than patching 3.13.x). Seems to work fine here, thanks. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: [RFT] xHCI TD fragment revert
On 14-02-04 05:55 PM, Mark Lord wrote: On 14-02-04 03:11 PM, Sarah Sharp wrote: Hi Mark and David, Can you test the following two patches against 3.13? Please make sure the adapter works when it's plugged directly into a USB 3.0 port and when it's plugged into a USB 2.0 hub. .. are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 3.13-td-changes-reverted for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20: I tested against the git tree (rather than patching 3.13.x). Seems to work fine here, thanks. And now I've tested the two patches, applied against 3.13.1. All Okay again. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On 14-02-01 02:54 AM, Ming Lei wrote: .. With SG enabled, for the iperf client test case, the average urb size for transmission will be increased from ~1500 to ~20K bytes in my test case: iperf -c $SRV -t 30 -P 4 -w 128K So I am wondering you guys do not care the improvement .. No, that's not it. Simply, the recent changes killed the driver for some users, something Linus calls a regression, and does not permit. Far better to have it continue to work than not to work. The plan discussed earlier calls for reintroduction of SG here once the problems are solved outside of the main tree. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On 14-02-01 09:18 AM, Ming Lei wrote: Even real regressions are easily/often introduced, and we are discussing how to fix that. I suggest to unset the flag only for the known buggy controllers. It is not the controllers that are particularly buggy here. But rather the drivers and design of parts of the kernel. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 01:44 PM, Sarah Sharp wrote: .. Since the USB ethernet scatter-gather support wasn't added until the 3.12 kernel, it's unlikely that the xHCI TD fragment issue is actually the root cause. The interesting piece of information in that report is that when the USB 3.0 device falls back to USB 2.0 speeds under xHCI, it works. Could be due to something related to the max URB length: USB 2.0 High-Speed: max URB length 512. USB 3.0 Super-Speed: max URB length 1024. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 02:54 PM, Paul Zimmerman wrote: Can you give a pointer to where we could buy one of these devices? I would like to test this with our (Synopsys) xHCI controller as well. newegg.com, item N82E16817659005 -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On 14-01-30 04:18 PM, Sarah Sharp wrote: Let's do this fix the right way, instead of wall papering over the issue. Here's what we should do: 1. Disable scatter-gather for the ax88179_178a driver when it's under an xHCI host. 2. Revert the following commits: f2d9b991c549 xhci: Set scatter-gather limit to avoid failed block writes. d6c9ea9069af xhci: Avoid infinite loop when sg urb requires too many trbs 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst 3. Dan and Mathias can work together to come up with an overall plan to change the xHCI driver architecture to be fully compliant with the TD fragment rules. That can be done over the next few kernel releases. The end result is that we don't destabilize storage or break userspace USB drivers, we don't break people's xHCI host controllers, the ax88179_178a USB ethernet devices still work under xHCI (a bit with worse performance), and other USB ethernet devices still get the performance improvement introduced in 3.12. Performance before 3.12/3.13 was not all that bad either. My ax88179 dongle (yes, that one, using ax88179_178a.ko) manages very close to 1gbit/sec throughput even without SG, and without a huge cpu tax either. SG done Right will make it better eventually. I can wait. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
Sarah, on a related note: Is there a parameter or knob of some kind to tell the XHCI driver to treat a specific port as USB2 (480mbit/sec max) rather than USB3 ? The Dell XPS-13 Ultrabooks all suffer from some kind of flaw, whereby the left side USB3 port is unreliable at SuperSpeed; the right side port works flawlessly. The MS-Windows driver has a workaround of some sort, but we don't. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On 14-01-30 04:43 PM, Alan Stern wrote: On Thu, 30 Jan 2014, Sarah Sharp wrote: It should not matter what alignment or length of scatter-gather list the upper layers pass the xHCI driver, it should just work. I want to do this fix right, by changing the fundamental way we queue TRBs to the rings to fit the TD rules. We should break each TD into fragment-sized chunks, and add a link TRB in the middle of a segment where necessary. That's a good plan. However _some_ restriction will turn out to be necessary. For example, what will you do if a driver submits an SG list containing 300 elements, each 3 bytes long? Allocate a contiguous (bounce) buffer and copy the fragments to/from it? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 04:41 PM, Sarah Sharp wrote: Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. As expected, this works just fine. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 06:26 PM, Sarah Sharp wrote: On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote: On 14-01-30 04:41 PM, Sarah Sharp wrote: Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. As expected, this works just fine. Did it work when plugged into a USB 2.0 hub? Curiosity, NO. Dies almost immediately when run at USB 2.0 Hi-Speed. With a USB 2.0 hub, with a USB 2.0 port on a USB 3.0 hub, and with a USB 2.0 extension cable in place of a hub. Near instant hangs. Plugged directly to the USB 3.0 port, it works fine. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com log.gz Description: GNU Zip compressed data
Re: Help testing for USB ethernet/xHCI regression
On 14-01-28 11:30 PM, Mark Lord wrote: On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. Vanilla 3.13 does not appear to have the USB3 ethernet lockup issue, and even USB3 hot-plug appears to be working again (was not working in 3.13-rc4). Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On 14-01-03 10:40 AM, walt wrote: On 01/02/2014 11:15 AM, Sarah Sharp wrote: On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote: 3.12-stable review patch. If anyone has any objections, please let me know. -- From: David Laight david.lai...@aculab.com commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream. Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB can only occur at a boundary between underlying USB frames (512 bytes for high speed devices). If this isn't done the USB frames aren't formatted correctly and, for example, the USB3 ethernet ax88179_178a card will stop sending... Unfortunately this patch causes a regression when copying large files to my outboard USB3 drive. (Nothing at all to do with networking.) Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see dmesg output from this statement shortly before your drive fails: if (num_trbs = TRBS_PER_SEGMENT) { xhci_err(xhci, Too many fragments %d, max %d\n, num_trbs, TRBS_PER_SEGMENT - 1); return -ENOMEM; } Well, the answers depend on whether the usb3 drive uses logical volumes or not (lvm2), which I can't explain. What I've described so far is with lvm2. When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect -- the console prints two or three lines stating that the ext4 journal has quit and the drive is remounted ro. That particular drive stays wedged until the next reboot, but no other ill effects to the system. OTOH, when I put a disk with just an ordinary ext4 partition in the usb3 dock, (no logical volumes) the copy failure becomes catastrophic, with kernel panic messages, leaving the system unresponsive and needing a hard reset to recover. I also tried your other suggestion: diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 4265b48..1a6a43d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4714,7 +4714,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks) int retval; /* Accept arbitrarily long scatter-gather lists */ - hcd-self.sg_tablesize = ~0; + hcd-self.sg_tablesize = 31; /* support to build packet from discontinuous buffers */ hcd-self.no_sg_constraint = 1; Sadly it didn't fix the problem. Did I get the patch right? That sounds almost as if the old version is still being loaded/run, possibly from the initramfs image? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On 14-01-02 02:15 PM, Sarah Sharp wrote: On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: .. Unfortunately this patch causes a regression when copying large files to my outboard USB3 drive. (Nothing at all to do with networking.) When I try to copy a large (20GB) file to the USB3 drive, the copy dies after about 7GB, the ext4 journal aborts and the drive is remounted read-only. This bug is 100% reproducible (always pretty close to 7GB) and reverting this patch completely fixes the problem. Ok, I had feared that would be a consequence of this patch. I think the problem is that the usb-storage driver submitted an URB with more scatter-gather entries than would fit on the ring segment, the xHCI driver rejected the URB with -ENOMEM, and the SCSI core eventually gave up on the SCSI command. Is there not a block layer / scheduler tunable for max sg entries or something? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: [GIT PULL] xhci: Regression fix for 3.13.
On 13-12-16 04:21 PM, Sarah Sharp wrote: On Fri, Dec 06, 2013 at 11:10:29PM -0500, Mark Lord wrote: On 13-12-06 10:25 AM, Greg Kroah-Hartman wrote: On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote: On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote: On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote: The following changes since commit c24cb6c8b501ebdf1aacec7960110a9741a45ced: Merge tag 'fixes-for-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus (2013-11-27 09:49:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-12-02 Pulled and pushed out, thanks. Did this commit make it into linux-3.12.3 ? No, it's not there yet, as it's not in Linus's tree yet, give me a chance... Okay, good to see it moving along. I asked about 3.12.3, because something new in that release broke Davids workaround for me here. But I'm with the rest of you: let's let what's in the pipeline make it out there (3.12.4 ?) and then I'll retest and repatch that if necessary to make things work here again. Hi Mark, 3.13-rc4 is out now, and it includes David's work-around. Can you please test with that kernel and confirm it fixes your issues with the USB ethernet adapter? Just giving it a whirl here tonight. Looks good, thanks. I won't have any further opportunity to thrash it until the New Year. Thanks all! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: [GIT PULL] xhci: Regression fix for 3.13.
On 13-12-06 10:25 AM, Greg Kroah-Hartman wrote: On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote: On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote: On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote: The following changes since commit c24cb6c8b501ebdf1aacec7960110a9741a45ced: Merge tag 'fixes-for-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus (2013-11-27 09:49:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-12-02 Pulled and pushed out, thanks. Did this commit make it into linux-3.12.3 ? No, it's not there yet, as it's not in Linus's tree yet, give me a chance... Okay, good to see it moving along. I asked about 3.12.3, because something new in that release broke Davids workaround for me here. But I'm with the rest of you: let's let what's in the pipeline make it out there (3.12.4 ?) and then I'll retest and repatch that if necessary to make things work here again. Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: [GIT PULL] xhci: Regression fix for 3.13.
On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote: On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote: The following changes since commit c24cb6c8b501ebdf1aacec7960110a9741a45ced: Merge tag 'fixes-for-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus (2013-11-27 09:49:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-12-02 Pulled and pushed out, thanks. Did this commit make it into linux-3.12.3 ? I ask, because the NIC still locks up with that kernel, and even with the patch I had been using from David Laight. Reverting the change that originally broke it still works though. Could we please get this reverted until such time as a reworked patch can be prepared for it? This is what I am reverting locally to make it all work as it did prior to linux-3.12 was released. Unmangled copy also attached: --- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0 -0500 +++ linux/drivers/net/usb/ax88179_178a.c2013-11-17 13:23:39.525734277 -0500 @@ -1177,18 +1177,31 @@ int frame_size = dev-maxpacket; int mss = skb_shinfo(skb)-gso_size; int headroom; + int tailroom; tx_hdr1 = skb-len; tx_hdr2 = mss; if (((skb-len + 8) % frame_size) == 0) tx_hdr2 |= 0x80008000; /* Enable padding */ - headroom = skb_headroom(skb) - 8; + headroom = skb_headroom(skb); + tailroom = skb_tailroom(skb); - if ((skb_header_cloned(skb) || headroom 0) - pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) { + if (!skb_header_cloned(skb) + !skb_cloned(skb) + (headroom + tailroom) = 8) { + if (headroom 8) { + skb-data = memmove(skb-head + 8, skb-data, skb-len); + skb_set_tail_pointer(skb, skb-len); + } + } else { + struct sk_buff *skb2; + + skb2 = skb_copy_expand(skb, 8, 0, flags); dev_kfree_skb_any(skb); - return NULL; + skb = skb2; + if (!skb) + return NULL; } skb_push(skb, 4); --- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0 -0500 +++ linux/drivers/net/usb/ax88179_178a.c 2013-11-17 13:23:39.525734277 -0500 @@ -1177,18 +1177,31 @@ int frame_size = dev-maxpacket; int mss = skb_shinfo(skb)-gso_size; int headroom; + int tailroom; tx_hdr1 = skb-len; tx_hdr2 = mss; if (((skb-len + 8) % frame_size) == 0) tx_hdr2 |= 0x80008000; /* Enable padding */ - headroom = skb_headroom(skb) - 8; + headroom = skb_headroom(skb); + tailroom = skb_tailroom(skb); - if ((skb_header_cloned(skb) || headroom 0) - pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) { + if (!skb_header_cloned(skb) + !skb_cloned(skb) + (headroom + tailroom) = 8) { + if (headroom 8) { + skb-data = memmove(skb-head + 8, skb-data, skb-len); + skb_set_tail_pointer(skb, skb-len); + } + } else { + struct sk_buff *skb2; + + skb2 = skb_copy_expand(skb, 8, 0, flags); dev_kfree_skb_any(skb); - return NULL; + skb = skb2; + if (!skb) + return NULL; } skb_push(skb, 4);
Re: net/usb/ax88179_178a driver broken in linux-3.12
On 13-12-02 02:08 PM, Sarah Sharp wrote: On 13-12-02 04:30 AM, David Laight wrote: .. Sarah needs to feed the xhci_ring.c fix through into stable. .. I'm working on it. You will probably have to wait for -rc3, depending on when Greg sends his next pull request. I will Cc you on the pull request and patch, which should be sent out today. Super, exactly what we need, thanks! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: net/usb/ax88179_178a driver broken in linux-3.12
On 13-11-19 08:44 AM, Mark Lord wrote: On 13-11-19 05:04 AM, David Laight wrote: Which changes did you revert? Just the bits that changed how the headroom/tailroom sizes were checked and adjusted. See attachment for the revert patch I am using here. My mailer unfortunately likes to mangle inline patches. =snip=== Revert USB 3.0 network driver changes that break the adapter (lockups) in 3.12. This just puts back the original code from previous kernels. Signed-off-by: Mark Lord ml...@pobox.com --- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0 -0500 +++ linux/drivers/net/usb/ax88179_178a.c2013-11-17 13:23:39.525734277 -0500 @@ -1177,18 +1177,31 @@ int frame_size = dev-maxpacket; int mss = skb_shinfo(skb)-gso_size; int headroom; + int tailroom; tx_hdr1 = skb-len; tx_hdr2 = mss; if (((skb-len + 8) % frame_size) == 0) tx_hdr2 |= 0x80008000; /* Enable padding */ - headroom = skb_headroom(skb) - 8; + headroom = skb_headroom(skb); + tailroom = skb_tailroom(skb); - if ((skb_header_cloned(skb) || headroom 0) - pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) { + if (!skb_header_cloned(skb) + !skb_cloned(skb) + (headroom + tailroom) = 8) { + if (headroom 8) { + skb-data = memmove(skb-head + 8, skb-data, skb-len); + skb_set_tail_pointer(skb, skb-len); + } + } else { + struct sk_buff *skb2; + + skb2 = skb_copy_expand(skb, 8, 0, flags); dev_kfree_skb_any(skb); - return NULL; + skb = skb2; + if (!skb) + return NULL; } skb_push(skb, 4); Two kernels later, and this regression has still not been fixed. A simple revert, folks. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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] mceusb: Add Twisted Melon USB IDs
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon. Signed-off-by: Mark Lord ml...@pobox.com --- Mauro, please queue this up for inclusion in linux-3.6. Patch is also attached to bypass emailer mangling. Thanks. --- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0 -0400 +++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400 @@ -199,6 +199,7 @@ #define VENDOR_REALTEK 0x0bda #define VENDOR_TIVO0x105a #define VENDOR_CONEXANT0x0572 +#define VENDOR_TWISTEDMELON0x2596 enum mceusb_model_type { MCE_GEN2 = 0, /* Most boards */ @@ -391,6 +392,12 @@ /* Conexant Hybrid TV RDU253S Polaris */ { USB_DEVICE(VENDOR_CONEXANT, 0x58a5), .driver_info = CX_HYBRID_TV }, + /* Twisted Melon Inc. - Manta Mini Receiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) }, + /* Twisted Melon Inc. - Manta Pico Receiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) }, + /* Twisted Melon Inc. - Manta Transceiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) }, /* Terminating entry */ { } }; Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon. Signed-off-by: Mark Lord ml...@pobox.com --- Mauro, please queue this up for inclusion in linux-3.6. Thanks. --- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0 -0400 +++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400 @@ -199,6 +199,7 @@ #define VENDOR_REALTEK 0x0bda #define VENDOR_TIVO 0x105a #define VENDOR_CONEXANT 0x0572 +#define VENDOR_TWISTEDMELON 0x2596 enum mceusb_model_type { MCE_GEN2 = 0, /* Most boards */ @@ -391,6 +392,12 @@ /* Conexant Hybrid TV RDU253S Polaris */ { USB_DEVICE(VENDOR_CONEXANT, 0x58a5), .driver_info = CX_HYBRID_TV }, + /* Twisted Melon Inc. - Manta Mini Receiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) }, + /* Twisted Melon Inc. - Manta Pico Receiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) }, + /* Twisted Melon Inc. - Manta Transceiver */ + { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) }, /* Terminating entry */ { } };