Solved dd: Input/output error

Fabien

Member

Reaction score: 4
Messages: 28

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:
OP
OP
Fabien

Fabien

Member

Reaction score: 4
Messages: 28

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
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,181
Messages: 29,471

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.
 

CyberCr33p

Active Member

Reaction score: 14
Messages: 172

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
 
OP
OP
Fabien

Fabien

Member

Reaction score: 4
Messages: 28

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!!
 

balanga

Son of Beastie

Reaction score: 109
Messages: 2,660

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?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,181
Messages: 29,471

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.
 
Top