Solved dd: Input/output error

Good morning,

I use dd(1) very often to write ISO on USB drives.

I probably did something wrong on my FreeBSD install, because the command # dd if=whatever.iso of=/dev/da0 bs=1M conv=sync fails a few time and after some attempts it works...

I might need help, please.


Code:
# dd if=whatever.iso of=/dev/da0 bs=1M conv=sync
dd: /dev/da0: Input/output error
10899+0 records in
10898+0 records out
11427381248 bytes transferred in 449.057310 secs (25447490 bytes/sec)


Code:
[~]$ doas dmesg | grep da0
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <SMI USB DISK 1100> Removable Direct Access SPC-4 SCSI device
da0: Serial Number AA00000000000489
da0: 40.000MB/s transfers
da0: 30000MB (61440000 512 byte sectors)
da0: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 54 90 80 00 00 80 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 54 90 80 00 00 80 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 54 90 80 00 00 80 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 54 90 80 00 00 80 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 54 90 80 00 00 80 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): got CAM status 0x44
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <SMI USB DISK 1100>  s/n AA00000000000489 detached
g_access(958): provider da0 has error 6 set
g_access(958): provider da0 has error 6 set
g_access(958): provider da0 has error 6 set
(da0:umass-sim0:0:0:0): Periph destroyed

Bonne journée!!
 
Last edited:
Just beeing curious, In which way can they be broken? I fact, it is true that I use them a lot, I have 4 of them, and I have to admit that their life is only a heck of a bootcamp: data, iso, destroy, newsfs, and on and on....Does it influence?

Do I have to tune my system better? Probably...

[~]$ dmesg
dmesg: sysctl kern.msgbuf: Operation not permitted
 
Flash chips wear out after a number of writes. And these sticks are produced in bulk in the cheapest possible way. So it's not uncommon for them to break after some usage.

Do I have to tune my system better? Probably...
You may have some of the security features enabled that prevents this. Not sure which one though.
 
Do I have to tune my system better? Probably...

[~]$ dmesg
dmesg: sysctl kern.msgbuf: Operation not permitted

sysctl -d security.bsd.unprivileged_read_msgbuf
security.bsd.unprivileged_read_msgbuf: Unprivileged processes may read the kernel message buffer
 
sysctl -d security.bsd.unprivileged_read_msgbuf
security.bsd.unprivileged_read_msgbuf: Unprivileged processes may read the kernel message buffer

Hi,
Thank you, I obviously choosed this security feature when installing the OS, so....
Now I know what is it.



Merci beaucoup guys for helping!!
 
Flash chips wear out after a number of writes.

Is there any way to tell how many writes have been made and is it possible to determine the current state?

I guess it could be working one moment and immediately fail soon afterwards, or is their gradual state of deterioration?
 
Is there any way to tell how many writes have been made and is it possible to determine the current state?
Some sticks might respond to SMART requests.
I guess it could be working one moment and immediately fail soon afterwards, or is their gradual state of deterioration?
I've had them fail in pretty much every possible way.
 
Back
Top