On 2/16/2008 12:16 PM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Andrew Buehler wrote:
> 
>> (Note: I consider it blatantly incorrect to send a reply both to a
>> mailing list and directly to the address of someone who is
>> subscribed to that list unless you have reason to believe that that
>> someone will not see the message otherwise, but in this case I am
>> doing so anyway because I see no way to avoid it and still make
>> sure all relevant people receive the message.)

(I did not expect to receive any significant response to this part of
the message, and any discussion ensuing from it is unquestionably
offtopic for the kernel mailing lists. I will respond here for the
moment rather than sending a separate, private mail, but I am more than
willing to take further responses on this topic offlist or drop the
subject entirely as soon as that is requested.)

> I (and a lot of other people as well, to judge by the email I
> receive) don't think this is incorrect.  For one thing, it's not
> always possible to tell whether or not the recipient is subscribed to
> any of the lists.

This is indeed why I did not see any way to avoid it in this instance.
However, that has no bearing on the question of whether or not it is
correct or appropriate to do so, only whether or not it is avoidable.

> For another, getting two copies of a message is no big deal --

I disagree.

(For that matter, I am not in fact getting two copies; in fact, I am not
receiving through the list either messages which I send to the list or
messages which are sent both to the list and to me. Whether this is the
list's fault or Gmail's I don't know, though I suspect the former - but
it is very irritating, because it means that I do not see this thread on
the mailing list itself and have to carry on list-related discussion
from my Inbox.)

> more irritating (IMO) is getting a rejection message as a result of
> replying to message which was cross-posted to a closed list.  But in
> each case, hitting the "d" key will delete the unwanted message.

I keep complete archives of everything I receive except for spam and (in
some cases) duplicates. Deleting received mail is a highly unpalatable
option, and in any case the ability to delete it is not the point; the
important question is whether it should have been there to begin with.

When I receive a message sent directly to me in a discussion which is on
a list, I expect that it is because someone either considered it
important enough to warrant making certain it came to my attention
specifically, or wanted to continue the discussion but felt that it
should not continue to take place on the mailing list.

> In fact, the thing that bothers me the most is when people reply to a
> long email with just a few lines of new text but don't bother to
> prune the long message down to its essential parts.  This forces me
> to read through hundreds of lines containing nothing new or of
> interest in order to obtain a minimal amount of useful information.

On the matter of quoting correctly and snipping correctly, you are
preaching to the choir where I am concerned. My standards for how much
context to leave in before beginning to snip are perhaps a bit looser
than those of some people (I leave up to three levels of quote in total
unless more is strictly necessary, since I find that fewer than that
frequently does not provide enough context if one does not have the
discussion in recent memory), but in principle I agree with you
completely.

>> On 2/16/2008 10:20 AM, Alan Stern wrote:
> 
>>> To make a long story short, the USB symptoms you describe
>>> indicate a problem with interrupt routing.  This could well
>>> explain the other difficulties too.  There are various kernel
>>> parameters you can try putting on the boot command line to work
>>> around it:  acpi=noirq or acpi=off or pci=noacpi or a few others.
>> 
>> I have now tried all three of these, with no apparent effect; the
>> USB drive is still not detected when plugged in after boot. A naive
>> search on Google provides no indication of other possible
>> parameters to try; the only list I have found of ACPI-related
>> kernel parameters includes no others which seem likely to be
>> helpful without more knowledge of the specifics of the situation
>> (and the subsystem) than I have.
>> 
>> What would the next step be?
> 
> People on LKML who are more familiar with interrupt routing problems
> might be able to offer more help.  For now, you can try things like
> turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting
> the contents of /proc/interrupts (say before and after a new USB
> device is plugged in).

In my current testing kernel, which I believe is the one with which I
captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG
is on. The associated dmesg (obtained yesterday from booting with the
Flash drive connected) is attached. (The flood of 'no version magic,
tainting kernel' messages between line 600 and line 1160 are a side
effect of Novell's custom environment which I have not yet made the
effort to fix; the boot scripts attempt to detect the network card by
modprobing every network driver available until they find one which
works. Here, because the correct one fails, they wind up trying each one
twice.)

I have transcribed the contents of /proc/interrupts both before and
after plugging in the Flash drive I have been using for testing, and
they are also attached. I have been as careful as I could to be sure
that the contents of the attached 'r61-interrupts-[12].txt' files is the
same as what was shown on the laptop, but cannot absolutely guarantee
that I have not missed something. For the record, the '1' is from before
connecting the drive, and the '2' is from after.

I did try booting again with the Flash drive attached, in hopes of being
able to mount it and dump the contents of /proc/interrupts there to
obtain them with guaranteed accuracy, but it was not recognized after
being disconnected and reconnected again.

> Assuming that the 2.6.23 kernel works on your computer, you can go
> the extreme route of installing git and doing a bisection to find the
> first patch causing your difficulty.

That would require me to learn enough of how git works, as distinct from
more traditional VCSes, to be able to use it with some confidence. This
is not impossible - indeed I want to do it at some point - but for the
time being I have no idea where to start, and indeed I am not especially
clear on exactly what (from a user's perspective) the differences been
git and e.g. CVS or Subversion are. I know that the entire concept
relies around a lack of centralization, but I have not been able to get
my head around what that means in a practical sense.

-- 
    Andrew Buehler