Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200:
I have just got around to trying this pen-drive again and have been
trying tracking down data corruptions. If I mount the drive, write a
file, umount/mount again the file is different.
Using cmp I have found that
On Sat, 13 Sep 2003, John-Mark Gurney wrote:
Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200:
I have just got around to trying this pen-drive again and have been
trying tracking down data corruptions. If I mount the drive, write a
file, umount/mount again the file is
Nate Lawson wrote:
On Sat, 13 Sep 2003, John-Mark Gurney wrote:
Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200:
I have just got around to trying this pen-drive again and have been
trying tracking down data corruptions. If I mount the drive, write a
file, umount/mount
Nate Lawson wrote:
dmesg:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
umass0: Get Max Lun not supported (IOERROR)
Enabling quirks for device
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SigmaTel MSCN 0001 Removable Direct Access SCSI-4 device
da0: 1.000MB/s transfers
da0:
On Sat, 9 Aug 2003, Andrew Thompson wrote:
On Fri, 2003-08-08 at 15:41, Nate Lawson wrote:
I have applied Kevins DA_Q_NO_PREVENT patch and now the device is
working perfectly, here is the diff and new dmesg.
Thanks Nate and Kevin for your help. Should I send a PR?
Please do and then send me
On Fri, 2003-08-08 at 15:41, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
If I were you, I'd look first into
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
Hi Nate,
I have just purchased a usb pendrive/mp3 player and I am having a bit of
trouble.
I built a fresh kernel today as I saw you have been working with the da
quirks. When I insert the
On Fri, 8 Aug 2003, Andrew Thompson wrote:
On Fri, 2003-08-08 at 15:13, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SigmaTel MSCN 0001 Removable Direct Access SCSI-4 device
da0: 1.000MB/s transfers
da0: 125MB (256001 512
In article [EMAIL PROTECTED] you wrote:
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
Hi Nate,
I have just purchased a usb pendrive/mp3 player and I am having a bit of
trouble.
I built a fresh kernel today as I saw you have been working
Nate,
I have successfully tested and the MuVo needs both DA_Q_NO_SYNC_CACHE
and DA_Q_NO_PREVENT (as per PR/53094) to work.
One question which pops into my mind is why the inability of a device
to do a cache sync should be fatal. I suspect that most flash devices
don't really even have a cache
On Fri, 8 Aug 2003, Andrew Thompson wrote:
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
On Fri, 8 Aug 2003, Andrew Thompson wrote:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
umass0: Get Max Lun not supported (IOERROR)
da0 at umass-sim0 bus 0 target 0 lun 0
On Fri, 8 Aug 2003, Andrew Thompson wrote:
Hi Nate,
I have just purchased a usb pendrive/mp3 player and I am having a bit of
trouble.
I built a fresh kernel today as I saw you have been working with the da
quirks. When I insert the drive I get:
umass0: SigmaTel, Inc. USBMSC Audio Player,
You may have a device (USB camera, pen drive, hard drive, ...) that begins
to get errors like ... Synchronize cache failed, status 0x35.
If the Sync cache fails with a reasonable error code, then the code
that silence these errors should be enhanced rather than have a quirk
entry added.
Just
On Tue, 29 Jul 2003, Justin T. Gibbs wrote:
You may have a device (USB camera, pen drive, hard drive, ...) that begins
to get errors like ... Synchronize cache failed, status 0x35.
If the Sync cache fails with a reasonable error code, then the code
that silence these errors should be
I have committed code to disable the USB and Firewire quirks in da(4).
Since we now have code that should handle the common case of a failure
after receiving 6 byte commands, most of them should no longer be
necessary. However, the only way to tell if a quirk is really needed is
to test the new
Hi,
camcontrol inquiry requires the pass driver, so if it's not already in
your kernel config you might want to add it when/if you add DA_OLD_QUIRKS.
Regards,
Andre Guibert de Bruet | Enterprise Software Consultant
Silicon Landmark, LLC. | http://siliconlandmark.com/
On Mon, 28 Jul
16 matches
Mail list logo
