A week’s worth of posts for you


I can’t keep up with all the things to post.  I desperately want to clear my inbox, so here’s a week’s worth of posts all smushed together.  Enjoy!

Phew.

4 Comments on A week’s worth of posts for you

Respond | Trackback

  1. Lazarus says:

    The notes on prepping for Google Summer of Code 2010 work for me (a non-subscriber).

    Aggelos’ libevtr looks like it could become something interesting, not that I will _ever_ know now that you’ve pointed out this web based FreeCiv.

    Bastard :-P

  2. I have been aware of FreeCiv being playable via browser for a while. I even thought I read about it here.

    The only problem is I can’t find many players. Are there any DragonFly users or developers who’d like to play?

  3. Joe "Floid" Kanowitz says:

    Quirks with those LSI chips seem to boil down to:

    1. The 1064[e]/1068[e] are apparently not very powerful for “hardware” RAID;
    2. Nobody has made any guarantee that you can use or manipulate arrays with DragonFly (although mpt does seem to make an effort to detect them);
    3. Choosing the right firmware can be somewhere between a headache and a nightmare (as can be entering the firmware utility, because it will send you rebooting endlessly if it loads before the right POST code is posted);
    4. Locate-by-LED doesn’t for SATA disks doesn’t seem to be supported in any firmwares;
    5. There was an annoyance re: write caches not enabled for SATA disks which may or may not have been patched after 2.4;
    6. There was/is(?) an annoyance or race re: enumerating SATA disks by serial number;
    7. Per-disk LED state with at least certain Fujitsu SATA disks (MHZ2250B) can “get weird.”

    The Linux-oriented writeup re: an onboard 1064e’s failings doesn’t include enough about the methodology to determine what was going on, but Mick Russom’s comment there is spot-on re: firmware headaches and LSI’s talk-to-the-vendor approach to support.

    When playing with firmwares, you have to keep in mind that they are split into multiple components and there’s some sort of ‘NVRAM’-type area which can end up in a nondeterministic state and will require use of undocumented(?) switches to the flash utility to wipe. As I recall, some folks on IRC were familiar with this approach and ‘loved’ it, but inability to solve all the oddities with either the vendor firmware or ‘retail’ firmware on my HP SC40ge/SAS3042E was a joykiller. [At some point the retail SAS3041E firmware even appeared to brick the PHYs on my card, though that may be because they’ve been playing with enabling and disabling 3Gbps SATA support between versions and I only had SATA disks. Rolling back to the years-old HP firmware fixed it.]

    The write caches can be enabled by editing the ‘virtual’ modepages, but these don’t persist; FreeBSD tossed in a sysctl so you can wedge them on at boot via sysctl.conf; I’m not sure if we’ve got that or the equivalent yet.

    When setting things up back in November 2009 (2.4-RELEASE), I ran into what seemed like the card not always ‘picking up’ the serial numbers / mpt not waiting or prodding it if it had not. I haven’t caught it at it since then, though I’ve probably only rebooted the system 3 more times.

    The LED situation shows up with an enclosure that trusts power pin 11 on the drives. Disks that have yet to have filesystems mounted from them will sometimes have their LEDs wedged on, and doing things like multiple short reads with dd (playing with throughput testing when I’d first installed things) would have a tendency to get them to flip state at the end of the activity, sometimes on or sometimes off. I’m starting to think it might be more the particular disks’ fault with the controller than the controller’s fault with the disks, but I couldn’t reproduce the behavior hanging them off the machine’s “normal” SB600 and don’t have any other disks to test in the enclosure. [And if I called those Fujitsu disks Toshibas anywhere, it’s because I couldn’t remember what I’d bought – Toshiba picked up their disk division now anyway.]

    … That got long. Given pricing of the HP cards in surplus/prevalence as onboard controllers, verdict seems to be that they’re still a least-worst way to get a functioning HBA (or additional SATA ports if you aren’t sure about generic SiI cards), but probably aren’t great for RAID [though perhaps that works if you don’t need to poke at it through the OS, have SAS drives so it’ll allow write caching on the array, and trust the firmware].

  4. Joe "Floid" Kanowitz says:

    “4.” should of course read “Locate-by-LED for SATA disks doesn’t seem to be supported in any firmwares.”

    It’s an open question whether the more upmarket LSI parts receive better firmware in this or the other regards, or if it’s basically the same tangle.

Respond

Comments

Comments