g-vfs-done():ada2p2[READ...error=5

[spoom]

I'm having some problems updating programs and am getting these error messages:

g-vfs-done():ada2p2[READ ....  ERROR=5

when trying to install or update graphics/png (for example) and on # shutdown -h now

Repeated messages (ad nauseam):

xhci=do_command: Command timeout

I have run fsck -y in single user mode but that did not fix this problem. I would think there is a problem with the disk, it is a 60GB SSD with only FreeBSD 9 on it. I did find a reference to an "infamous error 5 problem" but couldn't find anything about it either on google or in the forums. If it's so infamous, where is its fame? Is there a remedy for this or how can I troubleshoot it?

 

[cwhipp]

I know this doesn't help address your question, but I recently experienced the same error message and thought I'd include my experience in case anybody else comes looking for the same.

I've had the same or similar error message recently, with the same search results. It started about 3 months after I started using the drive. I my case, the drive was a 2TB external USB drive (specifically, a USB3.0 drive on a USB2.0 host). Any process that was attempting to read or write from the drive hung. The errors were more likely to occur when the drive was in heavy use. It occurred whether the drive was mounted read-only or read/write, formatted ufs or zfs, with or without SU+J, running the GENERIC kernel or custom, with or without device xhci in the custom kernels' config, and in any of the hosts's USB ports. My other external hard drive, which is a USB2.0 device, did not exhibit the issue

The drive also stopped responding to the following commands (which were successful when I first installed the drive):
# camcontrol identify /dev/da0 (returned a blank response)
# smartctrl -d sat -a /dev/da0 (returned an error message)

The errors started while running FreeBSD 9.0, but not immediately after upgrading from 8.2. I booted to the 8.2 memstick image and the above camcontrol command.

I finally took the drive to a windows box and ran the manufacturer's diagnostic utility. On the third try, despite two previous successes, it came back as a failed drive. The drive is currently out for rma.

A excerpt of the logged error messages is below:

gpt/dprivate[READ(offset=695233562624, length=2048)]error = 5                                                         
gpt/darchive[READ(offset=81002496, length=2048)]error = 5                                                             
gpt/dprivate[READ(offset=176506191872, length=16384)]error = 5                                                        
gpt/dprivate[READ(offset=754582863872, length=16384)]error = 5                                                        
gpt/dprivate[READ(offset=6242304, length=2048)]error = 5                                                              
gpt/dprivate[READ(offset=356095248384, length=2048)]error = 5                                                         
gpt/dprivate[READ(offset=356095250432, length=2048)]error = 5                                                         
gpt/dprivate[READ(offset=696005935104, length=16384)]error = 5

If my math is correct, the offset for that last entry is beyond the end of the drive's space.

 

[Persephone]

I was just about to start my own thread with a similar problem I am having with an external 2GB USB drive. Drive had no problems with Windows 7. Checked multiple times with no errors ever reported. Never had any errors reading or writing to it.

The endless g-vfs-done() started showing up after upgrading to 9.0 stable shortly after any writes to the drive. Only using the drive to read from works perfectly. It is only after the first attempt at writing to the drive that the endless stream of g-vfs-done() errors show up in /var/log/messages.

The g-vfs-done() messages repeat until the system is hard reset.

Just did some short smartctl tests on the drive with no errors reported so far. I am currently running a long (4 hour) test to see if that finds any errors.

Current system:

FreeBSD  9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Mar 29 21:44:54 PDT 2012     
user@:/usr/obj/usr/src/sys/GENERIC  amd64

 

[fegu]

I have fought with this for one full day and given up so I thought I would post my experience here in case someone can use my story to spot a pattern and eventually fix this.

FreeBSD 9.0 booting from internal IDE CD-ROM, external hard disk, external USB CD-ROM and USB key (yes, I tried them all - in fact 2 different USB keys) for installing on to two different hard disks. Why two disks? I tried one at a time just in case an actual hardware fault on the drive was the problem (which some has suggested). I don't think this is the case.

My drives were a 40GB IDE Samsung MP0402H 2.5" and a 60GB IDE Toshiba HDD2D17 2.5". Both are old, but rarely used and taken from full working and running Windows XP installations.

My board was an old Mini ITX VIA EPIA. I installed only base and kernel, no ports, no games, no docs.

On every attempt the errors would appear at the end of writing base or during writing kernel. The system would go on for a bit, sometimes the offset of the error changing, and then giving up.

In the end I installed the same system from the same CD using the same hardware on to a Compact Flash 4GB card in an IDE adapter - with no problems.

From forum posts and google fu, and my experience, this problem is:
- intermittent. Seems to happen on heavy I/O.
- not tied only to mainboard, but to a combination of mainboard and drives - or just drives.
- occurs even on healthy disks.
- occurs even on 9.0


In my case:
- Always on ufs partition (p2), never on boot partition
- Never right away, always after a lot of copying is already done
- Sometimes just a few lines before panic, sometimes screenfulls

See attachment for screenshot of one case.

 

[jb_fvwm2]

I am ever-hesitant to use a flash-based and/or USB based device without preplanning (as follows), I figure that modern CPU-bus transfers to/from the device are too quick for the USB-driver--flash-based-device half of the transfer.

# copying from / to a thumbdrive, large files
for f in $(gnuls *.tbz -1); do (gcp -Rvu "$f" /mnt/thumbdrive-dir && [B]sleep 1[/B]); done
....
# copying from / to a thumbdrive, large directories
# usr/obj## rsync -vaH --delete-delay --partial --stats --numeric-ids --inplace --archive --compress
 --file-flags --hard-links --one-file-system [B]--bwlimit=500 .[/B] /mnt/usr/obj

No experience yet with SSD, but I've lots of experience that WITHOUT either of those two methods or the equivalent, the flash-based device may need a near-certain

fsck_ffs -y /dev/da0

... the exception (maybe), if the machine is slow enough (pentium 2... maybe) for the file transfer(s) that occur.

 

[fegu]

Relevant information - probably solved

This is regarding my earlier post on this topic (two posts up). I now tried one of the same hard disks on a different Via EPIA board, installing from IDE CD-ROM. First try with the same cable, then second try swapping the cables so that the disk got the CD-ROMs cable and vice versa. This actually worked perfectly.

The cable seems faulty at high speeds, and the CD-ROM too slow to trigger it. Could this be because the cables are slightly different (see picture)? I assume the finer-threaded cable is made for higher speeds?

I must add that this cable worked perfectly in an earlier Win XP install on the same board with the same disk. Perhaps Win XP detects the cable type?

 

[marcelbonnet]

Workaround for g_vfs_done() error=5 problem to me, ocurred in FreeBSD 9 only

Sorry to ressurect this thread, but I think is important to say that I got into the same problem with umass device using UFS2, with or without soft update.
I had no problems running FreeBSD 8.2-RELEASE
The problem occurred running FreeBSD 9-STABLE only (different machines, different src checkout date)
My workaround for BSD 9 was setting a sysctl:

# sysctl -d hw.usb.ehci.no_hs
hw.usb.ehci.no_hs: Disable High Speed USB


So I changed the custom value:

# sysctl hw.usb.ehci.no_hs=1
hw.usb.ehci.no_hs: 0 -> 1


Now it's working perfectly well.

Cheers.

 

[giorgiob]

I also had this error on a raspberry-pi B+ running FreeBSD 11.1-RELEASE-p6 a few hours ago.

I wanted to download a few iso images to an external USB disk so I opened two screen sessions, started the download via lftp, detached the session and logged out.

Today I wanted to check how the download was going and noticed that I could not ssh to the rpi any more (write: broken pipe). So I turned on the console screen and saw this error 5 was being printed over and over again. I attached a keyboard to try and reboot but the system was still not responding so I had to pull the power supply cable.

I wanted to try the hw.usb.ehci.no_hs option but this does not seem to be available:

$ sudo sysctl -d hw.usb.ehci.no_hs
sysctl: unknown oid 'hw.usb.ehci.no_hs'


 

[ShelLuser]

First, the usual disclaimer, keep in mind that this thread is over 6 years old. So many things have probably changed between then and now.

I wanted to try the hw.usb.ehci.no_hs option but this does not seem to be available:

$ sudo sysctl -d hw.usb.ehci.no_hs
sysctl: unknown oid 'hw.usb.ehci.no_hs'


ehci is an USB type, but there are more available such as uhci, ohci and xhci. Now, I'm not familiar with the hardware of a Rasberry Pi but my assumption is that it doesn't use the ehci chipset which is why you don't have this setting available.

You can find out by checking /var/run/dmesg.boot or merely using dmesg | less shortly after booting. That should show you exactly what kind of USB support is being used.

Can't comment on the error messages though.

 

[PMc]

What has not changed over some ten years is the ehci failures.

I am not sure if the ehci is broken or if the respective chip is broken, but as soon as there is some severe load on a mass storage device connected via ehci (i.e. USB 2.0), it does fail.
The respective chip is the VIA VT6212L (which is what you find on any two-dollar-usb-card) and while the chip states that it is ehci compliant, I did not find any statement that FreeBSD would "officially" support it, so after a bunch of tests with different cards where I was not able to pinpoint the issue (within reasonable effort), I decided to ignore the matter.