Re: Endless CAM messages with recent CURRENT

On 14.01.2011 20:10 (UTC+1), Hans Petter Selasky wrote:
> Marcus,
>
> Can you have a look at this?

Are there any news?

Thanks,
Rainer

> --HPS
>
> On Friday 14 January 2011 16:21:00 Rainer Hurling wrote:
>> After looking around I had been able to localise the cause for the
>> described messages, see below:
>>
>> On 14.01.2011 10:07 (UTC+1), Rainer Hurling wrote:
>>> Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After
>>> rebooting I get the following messages two times per second in an
>>> endless run:
>>>
>>>
>>> ---------------------------------------------
>>> ...
>>> Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0):
>>> cam_periph_release_locked: release 0xfffffe0009f41200 when refcount is
>>> zero Jan 14 09:37:47 krabat kernel:
>>> Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1):
>>> cam_periph_release_locked: release 0xfffffe0009f41100 when refcount is
>>> zero Jan 14 09:37:48 krabat kernel:
>>> ...
>>> ---------------------------------------------
>>
>> When turning off hald no more of these messages appear. hald is trying
>> to poll the card reader, but it does not like this. So prohibiting the
>> polling in /usr/local/share/hal/fdi/preprobe/20thirdparty/ solves my
>> problem:
>>
>> #cat 10-broken-usb-card-reader.fdi
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <deviceinfo version="0.2">
>>     <device>
>>
>>       <!-- Generic STORAGE DEVICE 9744 -->
>>       <match key="storage.bus" string="usb">
>>         <!-- usb card reader Silverstone SST-FP35B doesn't like polling -->
>>         <match key="_at_storage.originating_device:usb.vendor_id" int="0x05e3">
>>           <match key="_at_storage.originating_device:usb.product_id"
>> int="0x0716">
>>             <merge key="storage.media_check_enabled"
>> type="bool">false</merge>
>>           </match>
>>         </match>
>>       </match>
>>
>>     </device>
>> </deviceinfo>
>>
>>> sg1 and sg2 are devices from my front panel card reader Silverstone
>>> SST-FP35B:
>>>
>>> #camcontrol devlist
>>> [..snip..]
>>> <Generic STORAGE DEVICE 9744>  at scbus6 target 0 lun 0 (sg1,pass3,da0)
>>> <Generic STORAGE DEVICE 9744>  at scbus6 target 0 lun 1 (sg2,pass4,da1)
>>>
>>>
>>> Is it possible that the last changes in usb code (xhci) or in cam code
>>> are responsible for this? Does anyone else observe this behaviour?
>>
>> A more generic approach would be to integrate the polling info into
>> /usr/local/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi.
>> Is anyone willing to integrate the code (.fdi file or some quirks) in
>> the usb stuff?
>>
>>
>> In that case Linux is offering some more info about this device:
>>
>> #lssub
>> Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot
>> Card Reader/Writer
>> idVendor 0x05e3 Genesys Logic, Inc.
>>
>> #usb-devices
>> T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
>> D: Ver=2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
>> P: Vendor=05e3 ProdID=0176 Rev=97.44
>> S: Product=USB Storage
>> S: SerialNumber=000000009744
>> C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
>> I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
>>
>>
>> Note, that the card reader from Benesys Logic is only one device of some
>> more (firewire, eSATA, USB slots ...), which are provided from the
>> 'Silverstone SST-FP35B' front panel access unit.
>>
>>> Please let me know if you need more info or if I can test something.