similar to: Lose XHCI Device on HP Ivybridge While Resuming on Battery

On October 1, 2020 11:58:11 AM EDT, Bruce Ferrell <bferrell at baywinds.org> wrote: >On 9/30/20 8:52 AM, H wrote: >> 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset >Family USB 3.0 xHCI Controller >My system has these: > >00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset >Family USB xHCI (rev 05) >00:1a.0 USB controller: Intel

On Mar 19, 2012, at 6:11 PM, Sarah Sharp wrote: > On Mon, Mar 19, 2012 at 05:05:47PM -0400, Tom Goetz wrote: >> On Mar 19, 2012, at 12:45 PM, Tom Goetz wrote: >>> On Mar 19, 2012, at 9:32 AM, Tom Goetz wrote: >>> I''ve just found that if the xHCI is in D3, has a USB device plugged in, and is not waking up, it will wake up when another device in D3 wakes up.

On 9/30/20 8:52 AM, H wrote: > 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller My system has these: 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1d.0 USB controller: Intel Corporation 8

On 10 August 2014 09:05, Charles Lepple <clepple at gmail.com> wrote: > On Aug 7, 2014, at 7:57 AM, Leith Bade <leith at leithalweapon.geek.nz> wrote: > > Error -32 is EPIPE, which means that the PC didn't see a reply from the device during the descriptor read. I don't know that we have ever successfully run one of these issues to ground. > Considering Eaton do

On 09/29/2020 11:11 PM, Bruce Ferrell wrote: > On 9/29/20 7:21 PM, H wrote: >> kernel: usb 1-9: unable to read config index 0 descriptor/all > > Those error messages mean that the device isn't responding to the Get-Descriptor request. > > I think a step back and checking the usb subsystem, in general, might be a good idea: > > Let's start with the full output of

On Aug 7, 2014, at 7:57 AM, Leith Bade <leith at leithalweapon.geek.nz> wrote: > I have tried to plug it into every USB port (including the USB 3.0 > ones) and I still get these errors. I discovered that power cycling > the UPS will fix it for a while, and also unplugging and replugging > the USB cable will also fix it sometimes. Error -32 is EPIPE, which means that the PC

On 9/23/2020 1:09 PM, Stuart D. Gathman wrote: > I solved this problem a few years back. > > https://github.com/sdgathman/trippfix > > The short answer is USB is broken on the model (but the power management > is excellent, handling switchover to generator power without a hitch). > > The workaround is to do a usb port power off when the Tripplite USB > hangs.  But hubs

Hi, I recently purchased a new Easton 5E UPS. I plugged the USB cable into my computer so I could use the NUT UPS tools. However every so often NUT fails to connect to the device after a boot. Looking at dmesg I see errors like this: [ 3.277075] usb 1-9: new low-speed USB device number 6 using xhci_hcd [ 3.302091] usb 1-9: device descriptor read/8, error -32 [ 3.430241] usb 1-9: device

Installed a new Tripplite Smart1500LCD on a CentOS 7 host using the usb connector. Nut does connect: $upsc ups battery.charge: 100 battery.runtime: 1407 battery.type: PbAC ... But after a half hour or so the connection is lost. Restarting nut re-establishes the connection. Any idea what might be causing the dissconnection?

Hello, following up on myself, it was suggested on IRC that I better attach a dmesg output. Here's the output of a clean boot & echo 0f > /sys/.../pstate cycle. I can't spot a message that relates to the reclock action, and there's only one weird "nouveau 0000:04:00.0: clk: base: 7 MHz, boost: 7 MHz" message. On the other hand: # cat

https://bugs.freedesktop.org/show_bug.cgi?id=109681 Bug ID: 109681 Summary: Nvidia GT710 => nouveau + wayland + swayWM => crash when use acceleration (open Firefox) Product: Mesa Version: 18.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical

Hi Konrad, Due to a 2.6.37-merge-window kernel now being able to boot under Xen i was able to test my xhci controller under dom0 which i previously couldn''t. The results: A) 2.6.37-merge-window kernel baremetal: Videograbbing while doing 20 iterations of make -j6 of kernel works. B) Xen + 2.6.37-merge-window kernel as Dom0: Videograbbing while doing 20 iterations of make -j6 of kernel

Three different external hard drives (Seagate, Western Digital and noname USB 3.0 enclosure) refused to be recognized as the umass devices. Reverting /usr/src/sys/dev/bsd/controller to r248085, building and loading just xhci module makes drives appear again. Below are snippets from the log in both cases: Non working: Jul 4 14:35:17 twinhead kernel: xhci0: <XHCI (generic) USB 3.0

On 09/29/2020 09:09 PM, John Pierce wrote: > do other USB 3 (XHCI) devices work on this system ? > > On Tue, Sep 29, 2020 at 5:27 PM H <agents at meddatainc.com> wrote: > >> On 09/29/2020 02:11 PM, Bruce Ferrell wrote: >>> Try >>> >>> lsusb -v >>> >>> and >>> >>> sudo dmesg >>> >>> ... Be

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u3 Severity: grave Hello, I am trying to install the XEN Hypervisor on a Debian Jessie Server. When I am booting without the Hypervisor, everything works fine, but when I am Booting WITH the XEN-Hypervisor, then System crashes / reboots after the "Scrubbing Free RAM" Message without any Error-message, just a blank screen.

On Wed, 2016-02-03 at 15:28 -0500, Konrad Rzeszutek Wilk wrote: > > > And I wonder if the XEN_DOMCTL_irq_permission aka, > > > xc_domain_irq_permission > > > had been called. I remember that at some point we missed it for > > > Xend.. > > > > > False alarm. > > It was all in Linux. Attached are four patches (the first two > are for

Hello All, after update to Centos7.5 all our Latitudes 3570 - some 150- suffer usb problems. Plug and play doesn't work any more, people need to insert usb devices - mouse, keyboard, eidreader - first and then boot in order to use them. dmesg | tail -n15 gives these EM: [ 25.164396] usb 1-8: device descriptor read/64, error -110 [ 25.418387] usb 1-8: new full-speed USB device number 6

----- Oorspronkelijk bericht ----- Van: "Nataraj" <incoming-centos at rjl.com> Aan: "CentOS mailing list" <centos at centos.org> Verzonden: Maandag 2 juli 2018 23:21:39 Onderwerp: Re: [CentOS] usb problem on Dell Latitude 3570 On 07/02/2018 01:49 AM, johan.vermeulen7 at telenet.be wrote: > Hello All, > > after update to Centos7.5 all our Latitudes 3570 -

Hi Folks, CentOS 5.5 x86_64 Asrock-Board with 2 USB3 plugs. Normally USB3-drive is detected. But occasionaly after "umount" next time this drive or other ones will not be detected. I have to boot the PC - than it works - till next unrecognition. On USB2 plugs all works correct. No messages in /var/log/messages nor dmesg. What happens here? Board failure - or other reasons? Some

Dear R-listers, It seems that predict() behaves differently within panel.xyplot. Am I doing something stupid? Thanks, Carlisle First, without xyplot(): > lmtest <- lm(t~s,data=subset(P100,whichLon100==1 & whichLat100==1)) > lmtest Call: lm(formula = s ~ t, data = subset(P100, whichLon100 == 1 & whichLat100 == 1)) Coefficients: (Intercept) t 33.3307