> So in order to hit this hypothetical corner case today you would
> need to be using a real world type-C device something such as a
> Dell WD15 on another OEM's machine that has type-C and the exact
> same ACPI object name that does $BADSTUFF other than return a
> buffer.
Exactly what I meant.
> From: Mario Limonciello
> Date: Mon, 11 Jul 2016 19:58:04 -0500
>
> > The RTL8153-AD supports a persistent system specific MAC address.
> > This means a device plugged into two different systems with host
> > side support will show different (but persistent) MAC addresses.
> >
> > This informa
> Hi,
>
> looking at this patch
>
> USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails
>
> it seems to me that pretty much all kernels are affected.
> Should this go into the stable trees?
Hi,
Alan Stern was reluctant to fix this bug because there is a small
chance that somebody somewher
> If anybody else was relying on the driver exceeding the
> maximum allowed bandwidth, wouldn't they run across the same BUG as
> you did?
>
> In which case there wouldn't be any downside to putting your patch in
> the -stable kernels.
>
> Alan Stern
>
Hey,
So it turns out, I wasn't completely
> If the list pointer contains LIST_POISON then it's already too late;
> we've been accessing memory that was deallocated.
Not really. I figured that LIST_POISON happens if the ED had been
linked and unlinked normally before being submitted abnormally.
And in fact, knowing that, I justs managed t
> Greg, in principle this should go to -stable. However, it looks like
> this might break some applications that currently sort-of work, even
> though they shouldn't. Therefore we have decided not to mark this
> patch for -stable at present.
This means leaving three longterm branches with a k
Since ed_schedule begins with marking the ED as "operational",
the ED may be left in such state even if scheduling actually
fails.
This allows future submission attempts to smuggle this ED to the
hardware behind the scheduler's back and without linking it to
the ohci->eds_in_use list.
The former
> That's clear enough.
>
> ISO IN 1007 bytes -> 793 us
> INT IN 32 bytes -> 35 us
>--
>825 us
>
> The additional requirements are:
>
> ISO IN 48 bytes -> 45 us -> 870 us total
> ISO IN 192 bytes -> 158 us
> > As I said, it now reports ENOSPC errors if there are low-speed
> > devices or significant isochronous transfers on the bus.
>
> It's quite possible that those are genuine errors. That is, the
> requested bandwidth may be more than the bus can provide.
Possible. This modem runs 1007 byte I
> Apparently this bug also prevented scheduling of endpoints which
> failed to schedule once in the past. Formerly I was getting only one
>
> usbatm_submit_urb: urb 0x8807f1568b00 submission failed (-28)!
>
> from ueagle-atm and now I'm getting regular spam. I think there's good
> chance that
> Try moving the first executable line:
>
> ed->state = ED_OPER;
>
> to the end of the routine, just before the "return 0;". That should
> fix the problem.
Yep, this does the trick. I removed my NULL-check before list_del and
nothing bad happens anymore.
Apparently this bug also prevent
OK, so I added those printks and I think I know what's going on.
Apparently, ed_schedule failure triggers 'goto fail' and leaves the ed
in some non-IDLE state so that it never gets added to the list indeed.
The failing EP 0x88 is 1kB isochronous, btw, so it all looks plausible.
Code (v3.18, newe
Hi,
Why high-bandwidth USB 1.1 isochronous devices don't work on 2.0 hosts?
I have an ADSL modem of this kind which I would like to use on a
companion-less 2.0 host in my router, but I can't because it fails with
ENOSPC errors. Same thing happens on my PC when connected through a 2.0
hub, but it
> Hi, I think I have a bug in the OHCI driver.
>
> Kernel version: 4.4.11 (some old 3.14 seems fine, didn't try others)
3.18.34 and 4.7-rc1 are affected too.
The bug seems to have been introduced by "add I/O watchdog for orphan
TDs" (81e38333). I couldn't run bisect because those old kernels don
Hi, I think I have a bug in the OHCI driver.
Kernel version: 4.4.11 (some old 3.14 seems fine, didn't try others)
Hardware: AMD SB850, Eagle III USB ADSL modem
Steps to reproduce:
1. boot with a USB keyboard
2. connect the modem
3. wait for the firmware, re-enumeration, etc
4. disconnect the mo
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations double
> > + u32 baseline, mantissa, exponent;
>
> Please keep these as unsigned int.
What's the reason for that? u32 is the exact width needed to perform
these computations, while unsigned int is something a bit unspecified.
> > + /* Calculate and return the exact baud rate. */
> > + baud = (ba
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations double
> Looks nice and clean otherwise.
>
> Were you already going to send a v2 or was this version complete?
I didn't intend to change anything. This works fine for me.
Maybe proper rounding would be a nice addition, but I'm not sure if
it's worth the effort. Now we can at least guarantee that the rat
t started
working with actual hardware without realizing that the comment is wrong
and doesn't describe the code anymore.
> On Mon, Jul 13, 2015 at 06:08:50PM +0200, Michał Pecio wrote:
> > > Commit 57ce61aad748 might be helpful... ;)
> > >
> > > Good luck,
>
> Commit 57ce61aad748 might be helpful... ;)
>
> Good luck,
> Frank
>
>
Pretty much the same thing I have done, except that I didn't notice that
0 = 512 :)
Apparently, 57ce61aad748 fell victim of a mass-revert caused by some
underdebugged issues. Is it known what they were? Is there any chance
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations double
22 matches
Mail list logo
