Hardware - Julio Merino (jmmv.dev)

The costs of the i386 to x86-64 upgrade

If you read my previous article on DOS memory models, you may have dismissed everything I wrote as “legacy cruft from the 1990s that nobody cares about any longer”. After all, computers have evolved from sporting 8-bit processors to 64-bit processors and, on the way, the amount of memory that these computers can leverage has grown orders of magnitude: the 8086, a 16-bit machine with a 20-bit address space, could only use 1MB of memory while today’s 64-bit machines can theoretically access 16EB. All of this growth has been in service of ever-growing programs. But… even if programs are now more sophisticated than they were before, do they all really require access to a 64-bit address space? Has the growth from 8 to 64 bits been a net positive in performance terms? Let’s try to answer those questions to find some very surprising answers. But first, some theory.

October 7, 2024 · Tags: <a href="/tags/blogsystem5">blogsystem5</a>, <a href="/tags/hardware">hardware</a>, <a href="/tags/unix">unix</a>
Continue reading (about 18 minutes)

Recovering two old Macs

Wow, it has already been three years since a friend an I found a couple of old Macintoshes in a trash container1. Each of us picked one, and maybe a year ago or so I gave mine to him as I had no space at home to keep it. Given that he did not use them and that I enjoy playing with old hardware, I exchanged those two machines by an old Pentium 3 I had laying around :-) The plan is to install NetBSD-current on at least one of them and some other system (or NetBSD version) in the other one to let me ensure ATF is really portable to bizarre hardware (running sane systems, though). The machines are these: A Performa 475: Motorola 68040 LC, 4MB of RAM, 250MB SCSI hard disk, no CD-ROM, Ethernet card. A Performa 630: Motorola 68040 LC, 40MB of RAM, 500-something IDE hard disk (will replace it with something bigger), CD-ROM, Ethernet card.I originally kept the Performa 630 and already played with it when we found the machines. Among other things, I replaced the PRAM battery with a home-grown solution, added support to change the NetBSD's console colors (because the black on white default on NetBSD/mac68k is annoying to say the least) and imported the softfloat support for this platform. Then, the turn for Performa 475 came past week. When I tried to boot it, it failed miserably. I could hear the typical Mac's boot-time chime, but after that the screen was black and the machine was completely unresponsive. After Googling a bit, I found that the black screen could be caused by the dead PRAM battery, but I assumed that the machine could still work; the thing is I could not hear the hard disk at all, and therefore was reluctant to put a new battery in it. Anyway, I finally bought the battery (very expensive, around 7€!), put it in and the machine booted! Once it was up, I noticed that there was a huge amount of software installed: Microsoft Office, LaTeX tools, Internet utilities (including Netscape Navigator), etc. And then, when checking what hardware was on the machine I was really, really surprised. All these programs were working with only 250MB of hard disk space and 4MB of RAM! Software bloat nowadays? Maybe... Well, if I want this second machine to be usable, I'll have to find some more RAM for it. But afterwards I hope it'll be able to run another version of NetBSD or maybe a Linux system. 1 That also reminds me that this blog is three years old too!

July 16, 2007 · Tags: <a href="/tags/atf">atf</a>, <a href="/tags/hardware">hardware</a>, <a href="/tags/mac">mac</a>
Continue reading (about 3 minutes)

Hard disks and S.M.A.R.T.

Old hard disks exposed a lot of their internals to the operating system: in order to request a data block from the drive, the system had to specify the exact cylinder, head and sector (CHS) where it was located (as happens with floppy disks). This structure became unsustainable as drives got larger (due to some limits in the BIOS calls) and more intelligent. Current hard disks are little (and complex) specific-purpose machines that work in LBA mode (not CHS). Oversimplifying, when presented a sector number and an operation, they read or write the corresponding block wherever it physically is — i.e. the operating system needn't care any more about the physical location of that sector in the disk. (They do provide CHS values to the BIOS, but they are fake and do not cover the whole disk size.) This is very interesting because the drive can automatically remap a failing sector to a different position if needed, thus correcting some serious errors in a transparent fashion (more on this below). Furthermore, "new" disks also have a very interesting diagnostic feature known as S.M.A.R.T. This interface keeps track of internal disk status information, which can be queried by the user, and also provides a way to ask the drive to run some self-tests. If you are wondering how I discovered this, it is because I recently had two hard disks fail (one in my desktop PC and the one in the iBook) reporting physical read errors. I thought I had to replace them but using smartmontools and dd(1) I was able to resolve the problems. Just try a smartctl -a /dev/disk0 on your system and be impressed by the amount of detailed information it prints! (This should be harmless but I take no responsibility if it fails for you in some way.) First of all I started by running an exhaustive surface test on the drive by using the smartctl -t long /dev/disk0. It is interesting to note that the test is performed by the drive itself, without interaction with the operating system; if you try it you will see that not even the hard disk led blinks, which means that the test does not "emit" any data through the ATA bus. Anyway. The test ended prematurely due to the read errors and reported the first failing sector; this can be seen by using smartctl -l selftest /dev/disk0. With the failing sector at hand (which was also reported in dmesg when it was first encountered by the operating system), I wrote some data over it with dd(1) hoping that the drive could remap it to a new place. This should have worked according to the instructions at smartmontools' web site, but it didn't. The sector kept failing and the disk kept reporting that it still had some sectors pending to be remapped (the Reallocated_Sector_Ct attribute). (I now think this was because I didn't use a big-enough block size to do the write, so at some point dd(1) tried to read some data and failed.) After a lot of testing, I decided to wipe out the whole disk (also using dd(1)) hoping that at some point the writes could force the disk to remap a sector. And it worked! After a full pass S.M.A.R.T. reported that there were no more sectors to be remapped and that several ones were moved. Let's now hope that no more bad sectors appear... but the desktop disk has been working fine since the "fixes" for over a month and has not developed any more problems. All in all a very handy tool for testing your computer health. It is recommended that you read the full smartctl(1) manual page before trying it; it contains important information, specially if you are new to S.M.A.R.T. as I were.

December 4, 2006 · Tags: <a href="/tags/hardware">hardware</a>, <a href="/tags/smart">smart</a>
Continue reading (about 3 minutes)

Posts: Hardware

The costs of the i386 to x86-64 upgrade

Recovering two old Macs

Hard disks and S.M.A.R.T.

Featured software

Featured posts