[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@××.com> posted 48C90384.9070804@××.com,
excerpted below, on  Thu, 11 Sep 2008 13:39:48 +0200:

> I'll think of it, although I'm afraid I might not find the time to
> follow up on the possible developer's requests. Since you have done it
> already, do you have pointers to get me started? I assume there's some
> fixed format needed to get the bug filed.
>
> Thanks for helping solve this problem!

Not really a fixed format.  Just provide everything you can think they 
might want... mentioning the other bug by number (as in bug #xxxxxxx) so 
it gets auto-linked, telling them the kernel you are using and any where 
you noticed changes in behavior, attaching your kernel .config file and a 
kernel boot log (dmsg, there's an option in the config to change the size 
of the log buffer if necessary), plus any post-boot syslog messages that 
seem relevant, mentioning Gentoo/amd64, the gcc version in case it's a 
mis-compile, the mobo and chipset, what you've already done to try to 
trace it down, etc.  You'll probably want to run the vanilla kernel for 
reporting and testing, just so no weird patches from anything else are 
confusing things.

My cases have all been regressions, in which case I noted the last kernel 
that worked and the first that didn't, usually to the -rc level.  One can 
then bisect down to the daily snapshot and beyond if one has the time tho 
it's not entirely necessary once they start debugging, usually.

Of course your bug will be somewhat different, in that it's not really a 
regression (you may want to test that for sure, try a couple older 
kernels just to see), but what's likely a bit of an extension from the 
other bug, so they already have a decent amount of data on how this thing 
normally behaves.  I'd put that in the explanation.

I don't expect this one to be too major, actually.  They may simply add 
the chipset to a list of boards that needs a reverse order or something, 
or may just give you a (grup) kernel command line option to reverse it 
and tell you that's the solution...

If it were me, in keeping with the provide any info that might be 
relevant theme... since there's already some discussion of it here, I'd 
put a link to the thread as well.  Who knows what bit of info might be 
here that would otherwise take several rounds of back and forth before 
you or they even realize it's relevant?  FWIW, here's the gmane link to 
your original post:

http://permalink.gmane.org/gmane.linux.gentoo.amd64/13127

FWIW, if you post the bug number here once you have it, I'll probably CC 
myself.  As I said all the ones I've filed have been regressions, so it'd 
be interesting to see how this runs.

BTW, unlike Gentoo and most FLOSS projects, many of which strongly prefer 
that you file a bug in bugzilla, the kernel mode of operation is more 
mailing list oriented, and they only have a bugzilla since that's what 
many users have come to expect for filing bugs and tend to be comfortable 
with.  If you prefer mailing, you can mail the LKML, CCing the 
appropriate area maintainer, etc.  However, for those not already in the 
kernel loop, bugzilla is likely much simpler, and Andrew and others do 
watch it and make sure the bugs get channeled to the right place.

BTW, http://bugzilla.kernel.org .

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman