On Wed, 17 May 2017, Rainer Koenig wrote:
> Oops, pressed the "send button too quickly, sorry"
>
> Am 16.05.2017 um 16:20 schrieb Alan Stern:
> > You've got a BIOS developer in the same building? That's a great
> > resource! Maybe together you can find out what condition is causing
> > the BIOS
Oops, pressed the "send button too quickly, sorry"
Am 16.05.2017 um 16:20 schrieb Alan Stern:
> You've got a BIOS developer in the same building? That's a great
> resource! Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.
We got everything here. We got
Am 16.05.2017 um 16:20 schrieb Alan Stern:
> You've got a BIOS developer in the same building? That's a great
> resource! Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.
We got everything here. We got hardware developers for our mainboards
and systems,
On Tue, 16 May 2017, Rainer Koenig wrote:
> >> We also attached an USB analyzer to the system to see what is going on.
> >> In the "bad" case we actually see a "resume" on the USB bus when the
> >> machine is shutdown. Problem is that we cannot see *who* initiated this
> >> resume, but my own gues
Am 15.05.2017 um 20:56 schrieb Alan Stern:
>> Interesting in this case is that we see a "USB disconnect" message
>> for device number 3. And even more strange are the last 3 lines
>> that show that new low-speed SUB devices are found even after all
>> USB controllers are shutdown.
>
> The shutdown
On Mon, 15 May 2017, Rainer Koenig wrote:
> Hi,
>
> I'm working on a very strange and bad problem related to USB and system
> shutdown.
>
> Problem description:
>
> We have a Thin Client system based on the AMD eKabini-Chipset that
> does not shutdown properly if
> - we allo
