Date: Wed, 16 Jan 2002 11:05:20 -0600 From: "Mike Meyer" <mwm-dated-1011632720.0d5a85@mired.org> To: "Anthony Atkielski" <anthony@freebie.atkielski.com> Cc: <questions@freebsd.org> Subject: Re: USB CF reader (SanDisk) epilog Message-ID: <15429.45776.491932.646543@guru.mired.org> In-Reply-To: <01b301c19e55$f11330a0$0a00000a@atkielski.com> References: <15428.34332.870130.2946@guru.mired.org> <00cc01c19e06$8dafddf0$0a00000a@atkielski.com> <15428.38970.224790.33804@guru.mired.org> <00ee01c19e0d$4c518960$0a00000a@atkielski.com> <15428.53337.168408.720031@guru.mired.org> <01b301c19e55$f11330a0$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@freebie.atkielski.com> types: > Mike writes: > > > True, but in my experience it's not the main > > one. The main one is that debugging problems > > remotely means you've got fragmentary and often > > inaccurate information to work with. > > Yes, but the fragmentary and incomplete information refers to the vendor's > own documentation. First, note that I didn't say "incomplete", I said "innacurate". "fragmentary and incomplete" is redundant. And it's the information from the user that suffers from this. Often a series of guesses at the missing information is *faster* than trying to extract the information required to correctly diagnose the problem. In extreme cases, it's faster to fly an expert to the spot so they can gather information than it is to try and extract it remotely. My favorite example is a system that had a register that failed in kernel mode, but not in user mode. Worse yet, said kernel wasn't used in the previous version of the kernel, so that OS and all diagnostic software ran flawlessly. But the system crashed on trying to boot the newer version of the kernel, which ran flawlessly on identical hardware sitting next to that box. > > You don't care how error 123 is processed, > > you want to know why it occurred. That's a > > different question. > I have to know why it occurred before I can determine whether or not the way > it was processed was appropriate. Intuitively it seems inappropriate that > an error should stall the system or prevent a reboot, as this one does, but > I cannot be sure unless I know what the error means. Right. So what have you done to figure out why it occured? Have you checked LINT for debugging options for USB devices, and built a kernel with the appropriate ones enabled? If so, have you run that kernel to see which USB request is getting an error? Once you've got that in hand, you can check the sources that generate that request to see what quirks change the handling of the response packet or the generation of the request, and try those. > > Since I never detach my usb devices, I don't > > use usbd. > I don't detach my usb devices, either (although I do remove and insert cards > in the CF reader). Does this mean that I can remove usbd from rc.conf? Yup. The very first thing on the usbd man page is that usbd handles USB device attachment and detachment. If those things don't happen, you don't need it. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15429.45776.491932.646543>