USB (internally fixed) card reader questions
Daniel Eischen
deischen at freebsd.org
Fri Jun 5 15:42:52 UTC 2009
On Fri, 5 Jun 2009, Bernd Walter wrote:
> On Sat, May 30, 2009 at 10:25:02AM -0400, Daniel Eischen wrote:
>> On Sat, 30 May 2009, Daniel Eischen wrote:
>>
>>> On Sat, 30 May 2009, Hans Petter Selasky wrote:
>>>
>>>> On Saturday 30 May 2009, Daniel Eischen wrote:
>>>>> On Sat, 30 May 2009, Hans Petter Selasky wrote:
>>>>
>>>>> It is not just USB flash cards. I have similar problem with
>>>>> external USB disk drives. See earlier (unanswered) posting:
>>>>>
>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006964.html
>>>>>
>>>>> And usbconfig(8) could be a little more helpful (the commands
>>>>> could use a description for what they do).
>>>>
>>>> I'm not sure who is at fault, USB or hald. It looks to me like hald does
>>>> not
>>>> detect that the flash card is plugged in during startup, and does not
>>>> mount
>>>> it.
>>>
>>> Is hald needed for this? I am not currently running X because
>>> it doesn't work any longer with my Intel 945GM chipset.
>>>
>>> I will try removing hald from the equation.
>>
>> Hmm, how about that! Removing hald (and dbus) solved the
>> problem. I can attach and detach the external drive without
>> any problems.
>
> It is just guessing, but maybe hald keeps the device opened, so GEOM
> never retastes the drive.
I don't know, but I was able to "dd if=/dev/da0 of=/tmp/da0.bb count=1"
from a good and bad attachment. When the problem occurs, it seems like
the data read by dd is skewed off by 12 bytes. The first 12 bytes are
0, followed by the same data (from byte 0) as the dd from the good
attachment.
[deischen at rigel ~]$ od -x da0.mbr.noworky
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 31fc 8ec0 8ec0 8ed8
0000040 bcd0 7c00 e689 00bf b906 0100 a5f3 fd89
0000060 08b1 abf3 45fe e9f2 8a00 46f6 20bb 0875
...
0000720 02b1 8f80 00b6 0100 0001 fe06 043f 003f
0000740 0000 3986 0001 0000 0501 fe07 ffff 39c5
0000760 0001 f44f 01ba 0080 ffc1 fea5 ffff 2e14
[deischen at rigel ~]$ od -x da0.mbr.worky
0000000 31fc 8ec0 8ec0 8ed8 bcd0 7c00 e689 00bf
0000020 b906 0100 a5f3 fd89 08b1 abf3 45fe e9f2
0000040 8a00 46f6 20bb 0875 d284 0778 4e80 40bb
0000060 568a 88ba 0056 fae8 5200 c2bb 3107 88d2
...
0000720 0501 fe07 ffff 39c5 0001 f44f 01ba 0080
0000740 ffc1 fea5 ffff 2e14 01bc 7275 0513 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
There are other side-effects from hald also. Trying to use
camcontrol rescan, reset, and disconnecting/reconnecting
the drive eventually leads to a hung system necessitating
a reboot. Without hald, it seems I can connect/disconnect
the drive as many times as I want.
--
DE
More information about the freebsd-current
mailing list