It couldn't have been nomsi because I forgot to preface it with pci= I also have the nic plugged in via a hub which I included in all my messing around lol. [ 96.210387] usb 9-4: Product: USB3.0 Hub [ 96.210391] usb 9-4: Manufacturer: GenesysLogic [ 96.213442] hub 9-4:1.0: USB hub found [ 96.214050] hub 9-4:1.0: 4 ports detected [ 96.426198] usb 6-4: new high-speed USB device number 2 using xhci_hcd [ 96.553004] usb 6-4: New USB device found, idVendor=05e3, idProduct=0610 [ 96.553011] usb 6-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 96.553016] usb 6-4: Product: USB2.0 Hub [ 96.553020] usb 6-4: Manufacturer: GenesysLogic [ 96.555184] hub 6-4:1.0: USB hub found [ 96.556005] hub 6-4:1.0: 4 ports detected [ 96.633247] usb 9-4.3: new SuperSpeed USB device number 4 using xhci_hcd [ 96.649945] usb 9-4.3: Parent hub missing LPM exit latency info. Power management will be impacted. [ 96.656079] usb 9-4.3: New USB device found, idVendor=0b95, idProduct=1790 [ 96.656086] usb 9-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 96.656091] usb 9-4.3: Product: AX88179 [ 96.656095] usb 9-4.3: Manufacturer: ASIX Elec. Corp. [ 96.656098] usb 9-4.3: SerialNumber: 00803F5D080C65 I'm just feeling like a bit of uptime for tonight it could have been a bios option I flipped. I'll peel things back a bit tomorrow. I got a feeling if I plug the nic into the Asmedia again i'm still going to get a bunch of kevent 4 spam. Regards, Will Trives On Wednesday 05 February 2014 13:26:20 David Laight wrote: > From: renevant@xxxxxxxxxxxxxxxx > > > Messing with the Realtek nic driver didn't work my pc crashed soon after. > > > > > > It looks like i've hit on a stable combination at the moment. It's looking > > like either... > > > > * Passing "nomsi" as a kernel parameter has worked somehow, when doing > > /proc/interrupts it looks like everything that used to be using msi is > > still using msi, except possibly the hdmi audio on the video card. > > I've not tried that, but I know that MSI interrupts can be a bag of worms. > > > * This patch: > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/bui > > ld&id=b399fe355b30d0102e7690 c99e6f764ddfd32ec3 > > Ah yes gcc developers: when I say -fno-sse I want that to disable sse2, > sse3, avx, avx2 and all the other extra instructions that might appear in > the next version. In a local driver makefile I have: > # With gcc 4.7 (and maybe some earlier ones) we have to explicitly > # disable sse in order to stop the xmm registers being saved to stack > # in every varargs function. > # I think we have to explicitly disable all the newer instructions, so set > # core2 (the first sane Intel 64bit cpu) and disable all its simd > instructions. CFLAGS += -mno-mmx -mno-sse -mno-sse2 -mno-sse3 > # The compiler on kapit doesn't support these option... > XOPTS := -march=core2 -mtune=generic > XFLAGS := $(shell $(CC) $(XOPTS) -E - </dev/null >/dev/null 2>&1 && echo > $(XOPTS)) CFLAGS += $(XFLAGS) > > I must have a look at the NetBSD kernel build options. > i386 still targets 486 so is ok, but amd64 will need the instructions > disabled. > > I'm currently running a bit of a frankenstien kernel because I have tried > > a > > bunch of stuff. > > > > Everything is working at the moment stabily for me, i'm only seeing this > > when doing transfers through the wireless VPN.... > > > > [ 839.482251] xhci_hcd 0000:02:00.0: WARN Successful completion on short > > TX: needs XHCI_TRUST_TX_LENGTH quirk? > > [ 844.480798] handle_tx_event: 2158 callbacks suppressed > > If you are seeing that, you need to add the quirk. > (Or make the code in xhci-ring.c assume the quirk is set.) > Without the quirk the xhci code believes that the transfer filled the > RX buffer, even though the controller indicated a short length. > > Given that one of the VHDL definitions used to build xhci controllers > has this bug. It would make sense for this to be enabled without a quirk. > The driver is already unconditionally doing the check. > > > * I set the TRBS per segment back to 64 and the sg list back to "~0u" > > 256 is probably a better value for TRBS per segment. > It will save some ring expansion requests happening later. > > > * readq/writeq reversion > > Definitely, that one wasn't tested on a range of hosts at all. > > > * LPM reversion > > That didn't make any difference to the problems I'm seeing with > the ax88179 card using the ASMedia controller. > > > * merged usb3-port-power-v4 from > > https://git.kernel.org/cgit/linux/kernel/git/djbw/usb.git/ > > > > * merged x86/build and x86/urgent from > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/ > > I wonder if there is anything in there that has a real effect? > > David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
