Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
hmm, on Fri, Mar 05, 2010 at 04:46:26PM -0500, nixlists said that On 3/5/10, J.C. Roberts list-...@designtools.org wrote: look for the `-p` flag. Know all about it. The problem is the kernel won't even get to that point - it hangs on syncing disks... stage. this is an issue on my eeepc701 both with it's internal SSD and any usb stick from the beginning (jan 2008). sometimes 1 in to 2 halts never finish. and it is not about the speed. you can leave it up overnight, nothing will happen. the interesting thing is, that i have enabled ctrl+alt+del, and while it is hanging, i press it, i get the rc.shutdown messages again and normally the box shuts down. but the filesystem is still dirty, sometimes... i know, i know, too little details, too many sometimes. but perhaps it's one of these bugs without a real pattern, or i just cant find it. i have asked before on this list how to track this down, with no results so far. -f -- as i said before, i never repeat myself.
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On Fri, Mar 5, 2010 at 7:44 PM, J.C. Roberts list-...@designtools.org wrote: Now getting back to the link/problem posted by Frank which mentions firefox, as well as your complaint about the speed of firefox... Yep, the final stop on the reality tour is most likely the fact that firefox might be *STILL* trying to shut down because the disk write speed sucks so bad. This of course means, sync is waiting on it. If you use a bloated Desktop like kde or gnome, they may also be a contributing factor to your shutdown times and for the same reason. I also experience this issue intermittently on my two 4.6 workstations, both with conventional HDDs. It either syncs instantly, or it never completes at all. I only weigh in because this was never a problem until 4.6 Firefox 3.5, and after jcr's points above I am highly inclined to blame the latter. Thank you for your suggestions. I will configure FF to not use a disc cache and report back after testing. Cheers, Anders
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
FWIW if I connect (boot with) my RAID enclosure to my eSATA card, the problem goes away at shutdown time. Any ideas? On 3/14/10, Anders Langworthy lagrang...@gmail.com wrote: On Fri, Mar 5, 2010 at 7:44 PM, J.C. Roberts list-...@designtools.org wrote: Now getting back to the link/problem posted by Frank which mentions firefox, as well as your complaint about the speed of firefox... Yep, the final stop on the reality tour is most likely the fact that firefox might be *STILL* trying to shut down because the disk write speed sucks so bad. This of course means, sync is waiting on it. If you use a bloated Desktop like kde or gnome, they may also be a contributing factor to your shutdown times and for the same reason. I also experience this issue intermittently on my two 4.6 workstations, both with conventional HDDs. It either syncs instantly, or it never completes at all. I only weigh in because this was never a problem until 4.6 Firefox 3.5, and after jcr's points above I am highly inclined to blame the latter. Thank you for your suggestions. I will configure FF to not use a disc cache and report back after testing. Cheers, Anders
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
2010/3/5 nixlists nixmli...@gmail.com: Also unrelated, but I am using FireFox in this install to write this message and it is painfully slow. This is on an Athlon 64 X2 4200+. I am using .mp kernel. Is it supposed to be this slow? It is using about 16% CPU with only one tab open. Put your gmail account in old style, I had the same problem, it's a gmail issue.
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On 3/5/10, Christiano F. Haesbaert haesba...@haesbaert.org wrote: 2010/3/5 nixlists nixmli...@gmail.com: Also unrelated, but I am using FireFox in this install to write this message and it is painfully slow. This is on an Athlon 64 X2 4200+. I am using .mp kernel. Is it supposed to be this slow? It is using about 16% CPU with only one tab open. Put your gmail account in old style, I had the same problem, it's a gmail issue. Not specific to gmail, I don't think. FF just seems very slow in OpenBSD for some reason.
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On Fri, 5 Mar 2010 11:59:26 -0500 nixlists nixmli...@gmail.com wrote: Hi. I installed a recent -current on an SD MMC card. Boots just fine with an old SanDisk reader, but most times at the time of shutdown (shutdown -h now) the kernel hangs at Syncing disks., and I have to power down manually. When it comes back it has to fsck of course. Shut down works fine on a different computer with this SD card (laptop) with a built-in card reader. What may be a problem? PEBCAK man shutdown(8) look for the `-p` flag.
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On 3/5/10, J.C. Roberts list-...@designtools.org wrote: look for the `-p` flag. Know all about it. The problem is the kernel won't even get to that point - it hangs on syncing disks... stage.
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
nixlists wrote: On 3/5/10, J.C. Roberts list-...@designtools.org wrote: look for the `-p` flag. Know all about it. The problem is the kernel won't even get to that point - it hangs on syncing disks... stage. Seems you might not be alone... http://www.mail-archive.com/misc@openbsd.org/msg72159.html
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On Fri, Mar 05, 2010 at 05:17:47PM -0500, Frank Bax wrote: nixlists wrote: On 3/5/10, J.C. Roberts list-...@designtools.org wrote: look for the `-p` flag. Know all about it. The problem is the kernel won't even get to that point - it hangs on syncing disks... stage. Seems you might not be alone... http://www.mail-archive.com/misc@openbsd.org/msg72159.html But again, he just can't find that thread!
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
On Fri, 5 Mar 2010 16:46:26 -0500 nixlists nixmli...@gmail.com wrote: On 3/5/10, J.C. Roberts list-...@designtools.org wrote: look for the `-p` flag. Know all about it. The problem is the kernel won't even get to that point - it hangs on syncing disks... stage. Though the archive link from Frank Bax is interesting and possibly related (covered below), you gotta understand your hardware. Many types of flash storage are *PAINFULLY* slow when they're brand new, and only continue to get slower over time/use. If you're using an old CF card, you most certainly have a contributing factor to the amount of time it will take to sync the disk on shutdown. Though the typical USB 2.0 marketing claims 480 MiBit/s (a.k.a. high speed), the claims are bullshit. If you do the rough calculation of 480/8, you get 60 MiByte/s, but the thing they never bother to tell you is they are *including* the overhead of the encoding and protocol. USB 2.0 uses 8b/10b encoding, so there's 20% overhead right there. With everything included, you actually lose about 33% or more, so the interface can move about 40 MiByte/s or slower of real data. USB is a long way from fast for a disk interface but the above tells you that USB is *seems* to not be the issue. Also, your dmesg data shows EHCI, so you at least it *seems* you're running at USB 2.0 high speed rather than the much slower Low Speed (1.5 MiBit/s) or Standard Speed (12 Mbit/s), which are denoted by UHCI or OHCI. Yes, the *seems* is important. Some devices can (and sadly will) silently downgrade to lower speeds, so the output of `usbdevs -vvv` can be very handy. Though `usbdevs` should be accurate, cheap USB devices (such as a CF reader) can do very ugly things and `usbdevs` may not catch everything. OK. We've got your storage media, CF Disk, covered. We've got your interface, USB, covered. We even have your card reader, possibly cheap and downgrading, covered. So what's next? The next bus stop is reality. Better known as testing your own hardware to see what it does. The following results are from tests I was doing this morning with brand name (Corsair) but typical USB 2.0 Flash Disk/Stick/Thumb or whatever the hell you want to call it. Though a CF Disk is a different beast, it's still roughly similar tech internally, so the following results are at least somewhat comparable to your situation. *** # dd if=/dev/rsd0c of=corsair.dump count=8011776 8011776+0 records in 8011776+0 records out 4102029312 bytes transferred in 7363.861 secs (557049 bytes/sec) # dd of=/dev/rsd0c if=iodisk.dump 493568+0 records in 493568+0 records out 252706816 bytes transferred in 1575.815 secs (160366 bytes/sec) *** Ya, with USB 2.0, the read speed is roughly 0.5 MiByte/s, and the write speed is roughly 0.125 MiByte/s without ANY file system overhead. If you were actually writing to a file system, it would be even slower. Cheap/typical platter based hard drives write at 40 MiByte/s or *much* better... YES, A CHEAP HARD DISK IS AT LEAST 320 TIMES FASTER! If someone with a cheap hard drive has to wait 10 seconds for a shutdown, by comparison, you would have to wait 53 MINUTES. When you `halt` your system, it preforms a `sync` to make sure all data is written (flushed) to disk. If your write speed is miserable like the above Flash Stick numbers, then you will have to wait some time until the `sync` finally completes. Now getting back to the link/problem posted by Frank which mentions firefox, as well as your complaint about the speed of firefox... Yep, the final stop on the reality tour is most likely the fact that firefox might be *STILL* trying to shut down because the disk write speed sucks so bad. This of course means, sync is waiting on it. If you use a bloated Desktop like kde or gnome, they may also be a contributing factor to your shutdown times and for the same reason. Configure firefox to not use a disk cache at all (e.g. run from RAM only), or better look into the read-only CD-ROM installations since newer firefox crap does a lot of sqlite database crap. Also, running a light desktop like cwm or scrotwm might help. There are lots of different tricks for using CF cards and similar slow media, so if you insist on using them, be prepared to do a whole lot of searching and reading. jon
Re: Shutdown fails intermittently with OpenBSD running off SD MMC card
*** # dd if=/dev/rsd0c of=corsair.dump count=8011776 8011776+0 records in 8011776+0 records out 4102029312 bytes transferred in 7363.861 secs (557049 bytes/sec) # dd of=/dev/rsd0c if=iodisk.dump 493568+0 records in 493568+0 records out 252706816 bytes transferred in 1575.815 secs (160366 bytes/sec) *** A more accurate test would be to use a blocksize on dd that is same as filesystem. eg. # dd if=/dev/rsd0c of=corsair.dump count=8011776 ibs=16384 obs=16384
