Am Mon, 23 Mar 2015 09:50:32 -0400 (EDT)
schrieb Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Mon, 23 Mar 2015, Marc Joliet wrote:
>
> > > > > Please capture a couple of usbmon traces showing what happens during a
> > > > > connect when the wrong sector size is detected and a connect when the
> > > > > right sector size is detected. You can post the traces here (if there
> > > > > is a lot of repetitious stuff after the beginning, you can trim it out)
> > > > > or post them somewhere for people to see.
> > > >
> > > > I'm still in the process of doing this, it turns out it's not so easy:
> > > >
> > > > - If I try to run usbmon as early as possible (as a systemd unit, but maybe
> > > > there's a better way?) to catch the drive when the wrong sector size is
> > > > detected, I have a lot of stuff to trim from the logs, such as keyboard input
> > > > and mouse movement (which I'm doing now). Do the logs give information about
> > > > which keys are pressed?
>
> It's doubtful whether you can run usbmon early enough to capture
> communications with devices that are present when the system boots.
Yeah, I know, but given the other behaviour I described in the forwarded
message, I don't know how else to go about this.
I might be able to get it to start on time with the right dependencies (since
systemd creates units for devices, too), but first I'll see if the current log
is enough.
> > > Looks like I can answer my own question: yes, at least each key is easily
> > > differentiated by what is IIUC its data stream.
> > [...]
> >
> > I think I've got this done. I removed messages from bus 1 and 2, which contain
> > my mouse and keyboard.
>
> Instead of removing messages from buses 1 and 2, you can simply capture
> the messages from the bus that the drive is attached to.
Yes, but it doesn't always show up on the same bus, so I can't do that. For
example, right now it's on bus 3 together with one of two 2.0 root hubs, but
last time I looked it wsa on bus 4 with the 3.0 root hub. I think it's weird,
is that behaviour expected? Of course, maybe I'm misremembering.
> > Without trying to trim duplicate messages, the resulting
> > log is 3937 lines long and 324K large. Everything up to line 1229 is from the
> > initial connect, the rest from the reconnect. I left some kernel messages in
> > there for context. Trimmings are marked with "[...]".
>
> What kernel messages are you talking about? usbmon output doesn't
> contain any kernel messages.
By starting usbmon as a systemd service I get its output interleaved with all
the other system logs in the output of journalctl.
> > Is that manageable enough, or should I trim it further before sending? Also,
> > should I send it compressed, or in plain-text?
>
> Try trimming it down to the first 200 lines or so following each
> connection. If that's not enough I'll let you know. Plain text is
> okay.
OK, I got it down to 763 lines total because of various kernel messages and I
was worried that they might provide important context, so it's not quite down to
200 lines, but I hope that's close enough. The logs for the reconnect start
after line 323 ("kernel: usb 4-2: USB disconnect, device number 2").
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
Attachment:
trimmed_log_for_email.output
Description: Binary data
Attachment:
pgpvrarhZl5gh.pgp
Description: Digitale Signatur von OpenPGP
