title: Stick that in your .bashrc and smoke it. date: 2005-10-20 18:11:44
function tv () { i=$(echo ${@} | sed -e's/.*\(...\)$/\1/') ; case $i in bz2) tar tvjf ${@} ;; *gz) tar tvzf ${@} ;; *) tar tvf
${@} ;; esac }
function xv () { i=$(echo ${@} | sed -e's/.*\(...\)$/\1/') ; case $i in bz2) tar xvjf ${@} ;; *gz) tar xvzf ${@} ;; *) tar xvf
${@} ;; esac }
Tags:
So I came to the the realization that I've been including the driver for the wrong damn flash chip. This came straight from Codeman's tree, which in turn is based on (I think) the HRI tree. Codeman's .config file for uClinux included drivers for the SST39V flash chip, which just plain isn't right for this router. It's possible that he had a different revision of the board or some such, but I suspect that since he wrote to the flash using the JTAG interface, the issue just never came up.
I grabbed the datasheet for the Hynix chip, and it's not that different from what's in the SST driver...but it's just different enough that it's causes problems. First of all, you've got to give the secret knock before writing a byte to flash -- apparently to keep electrical noise (or some such) from accidentally erasing important data. In the SST driver, it looks like this:
map->write8(map, 0xaa, 0x5555)
map->write8(map, 0x55, 0x2aaa);
map->write8(map, 0xa0, 0x5555);
But according to the Hynix datasheet, it should look like this:
map->write8(map, 0xaa, 0xaaa);
map->write8(map, 0x55, 0x555);
map->write8(map, 0xa0, 0xaaa);
Okay, easy enough to change. Still didn't work, though, when I tried
to copy the jffs2 image to /dev/mtd1; the writes just keep on
failing. But then I remembered that only an erase can turn on a
particular bit -- ordinary writes can only flip 'em off.
Just for fun, I tried copying an image where, compared to what was in flash already, bits would only have to be turned off -- and sure enough, that worked. Didn't survive a reboot, though...weird.
On, then, to the bit of the datasheet that deals with erasing. There's the secret knock for erasing, but that was easy enough to fix. The last part of the secret knock tells the chip which 0x1000-byte sector to erase. With the SST driver, it looks like you just use the beginning of the 0x1000 byte sector you want to erase, making sure that it's on an erase boundary (ie, some multiple of 0x1000).
The Hynix, though...I'm having trouble figuring it out. The sector I'm trying to erase starts at 0xf0000, so I'll use that as an example. The datasheet has a table listing what address to write the final command, and it says that the addres should be binary 01111??? -- the last three bits don't matter. But this table also seems to say these should be bits 19 through 12 (counting from zero). If that's the case, then we're just shifting the address over by one, which means writing the final command to 0x78000. But that doesn't seem to work.
In another part of the datasheet, it seems to imply that the sector address is just 8 bits long -- in which case, we're shifting the address right by 13 bits. That seems like a very strange number. It works out to a write to 0x78, and that doesn't work, either. The only thing that I can think of is that flash memory is supposed to be mapped to 0x20000000, so maybe it's 0x2f000000 that should be shifted as necessary. But that doesn't make any sense to me.
And the fact that the bits I managed to flip don't survive a reboot makes me suspicious -- am I trying to write to RAM or some such rather than flash? If anyone out there knows this sort of thing, I'd be grateful if you could take a look at the datasheet and see if you can figure out what I'm doing wrong.
Tags: nwr04b
title: Holy crap. date: 2005-10-11 18:35:40
From the ever-excellent Secrecy News comes this. I am agog.
Tags:
title: SparcStaionLX: NetBSD a go! date: 2005-10-10 10:21:33
Picked up a 25-to-9 pin adapter yesterday, and in combination with a
9-pin null modem cable I finally managed to get at the Sun firmware
prompt, and thus to install NetBSD over the network. Very nice, very
simple install; the only problem I had was this one: the option
root-path "/home/aardvark/netbsd-sparc/nfsroot" was too long, and the
DHCP server just did not hand out that option -- no complaints or
anything. Not good. Just starting up SSH for the first time right now,
and holy crap it's taking a while to generate the host keys. --Only
24MB of RAM...huh, thought for some reason these things came with
96MB. Should probably just give up and generate host keys for the
thing.
Tags:
Okay, so if you look at the goddamned chip on the NWR04B, you see it's a Hynix HY29LV160-BT, which is not nearly the same as an SST39VF08. I've got the datasheet, at least, so I can look and see if there's maybe some simple change to the driver I'm using to make it work.
That's ugly, though (but no uglier than my debugging code...ugh), and I need to make that better. The MTD folks are no longer supporting the 2.4 kernel; however, looks like the uClinux folks have backported the MTD stuff. Which means I might try upgrading to the latest uClinux version and see if I can port my changes over...although frankly, I'm scared that I'll just be back at square one with this project and trying to figure out why the hell I can't print to the screen.
Yeah, it's an irrational fear, but if I can just break this out into a separate driver I'll be happy. Anyhow, it doesn't look like this particular chip is supported yet by the MTD people, so that's less of an incentive to move up. Or more of an incentive...maybe the closest I'll come to getting a patch into the Linux kernel tree. :-)
Tags: nwr04b
cfengine is great, it really is. But there are some things that tripped me up. Often you want to set up a daemon to run The Right Way, which involves changing its config file. After that, of course, you want to restart it. What to do? The naive way (ie, the first way I tried) of doing things is:
control::
sequence ( editfiles shellcommands )
editfiles::
debian:
{ /etc/foo.conf
BeginGroupIfNoLineMatching "bar"
AddLine "bar"
Define restart_foo
EndGroup
}
freebsd:
{ /usr/local/etc/foo.conf
BeginGroupIfNoLineMatching "bar"
AddLine "bar"
Define restart_foo
EndGroup
}
shellcommands::
debian.restart_foo:
"/etc/init.d/foo restart"
freebsd.restart_foo:
"/usr/local/etc/rc.d/foo restart"
However, the correct way of doing this is:
control::
sequence = ( editfiles shellcommands )
AddInstallable = ( restart_foo )
editfiles::
debian:
{ /etc/foo.conf
BeginGroupIfNoLineMatching "bar"
AddLine "bar"
DefineInGroup "restart_foo"
EndGroup
}
freebsd:
{ /usr/local/etc/foo.conf
BeginGroupIfNoLineMatching "bar"
AddLine "bar"
DefineInGroup "restart_foo"
EndGroup
}
shellcommands::
debian.restart_foo:
"/etc/init.d/foo restart"
freebsd.restart_foo:
"/usr/local/etc/rc.d/foo restart"
Without both the enumeration of all your made-up classes in AddInstallable and the enclosing of that class in quotes, cfengine will fail to do what you want -- and will do so quietly and with no clue about why. God, that took me a long time to find.
Tags: cfengine
Got my first SuSE machine at work (well, not mine, but I'm setting it up), and I'm running into a weird problem with ypbind. If I call ypbind on its own -- no arguments -- it'll work. man page sez it's parsing /etc/yp.conf, which has the line "domain foo broadcast", and sure enough it broadcasts on a nice privileged port and binds to the server for domain foo. If I call ypbind with the -d argument, it stays in foreground, prints debuggin messages and fails like so:
do_broadcast() for domain 'foo' is called
broadcast: RPC: Can't encode arguments.
leave do_broadcast() for domain 'foo'
Signal (2) for quitting program arrived.
Well, crap. That's weird. After some searching, found [Debian bug
(tentatively, but) on libc. And but so there's these other bugs from, you know, Novell/SuSE, which also sound similar. And holy crap, where the hell have I been that I haven't heard of:
echo 65535 > /proc/sys/sunrpc/rpc_debug
echo 65535 > /proc/sys/sunrpc/nfs_debug
And other interesting behaviour from that second bug:
The problem in that bug was that immediately following a reboot, the NFS client will end up opening the same TCP port it used before, so it tries to establish a TCP connection from client:1234 -> server:2049. The server still has a TCP control block for this, and replies with a single ACK containing what it thinks are the right sequence numbers. That ACK is eaten by the conntrack module because the connection isn't yet in state ESTABLISHED.
Okay but back to our original bug: which appears to have been fixed
now by adding one line to /etc/yp.conf:
broadcast
domain foo broadcast
Why the fuck that should work is beyond me...
Tags: suse!
From the ever-excellent GrigorPDX:
The images are originally from this site, an online collection/store of Soviet and Communist propaganda posters. The original images are hypnotizing, especially when (like me) you're fascinated by right-wing politics (and its fixation on left-wing/Communist conspiracies), melodrama and the paranoid style; never let it be said that the only place to find the three together is at Alex Jones' website or Sisters of Mercy lyrics.
These images are not profound observations on Bush2's presidency. It's not fair to compare Bush2 to, say, Stalin. But that doesn't stop them from being very, very powerful.
Tags: politics
I must really be missing something here, because I am unable to get this thing to write to flash at all. Here's what's going on in the kernel:
(All this is in cx84200-flash.c, BTW.) I can think of two things...wait, three things...that might be happening:
Any other ideas, please let me know.
Tags: nwr04b
Debian. I love the Debian. But the logs in Debian annoy me.
kernel.log, messages.log and syslog.kernel.log and syslog? Between daemon.log and debug.log? Why is exim4/mainlog not symlinked to mail.log?kernel: IN=eth2 SRC=24.82.14.99 LEN=64 TOS=0x00 PREC=0x00 TTL=45 ID=40654 DF PROTO=TCP SPT=2678 DPT=445 WINDOW=53760 RES=0x00 SYN URGP=0. Fuck that noise!FreeBSD, by contrast, has it fucking down. There's messages.log
for everything you're likely to need as a normal user -- except mail
messages, which are conveniently located at mail.log. For the
sysadmin, you've got security.log (firewall stuff), auth.log
(login stuff) and all.log (everything). It's simple, easy to
understand and you can bloody well ready what you need to without
becoming root. Sigh.
In other news, thanks to Mr. Dickens I came across Belanix today, a live OpenSolaris CD. I'm currently scrounging around for a spare machine to boot from, as QEMU seems to confuse it.
Tags: rant
Currently writing this entry in emacs. Once upon a time, I stopped using emacs for fear of what loading a 20MB editor would do to the mail server I was working on, and learned to love vi. Prompted by ESR's Art of Unix Programming, I've decided to try pick up emacs again. It's interesting....Anyhow: Right now I'm trying to figure out why the hell writing to flash on the NWR04B is not working. First off, I've edited the map file for the flash devices (drivers/mtd/maps/cx84200-flash.c for those of you playing the home game) so that I've got two partitions declared:
static struct mtd_partition cx84200_partitions[] = {
{
name: "bootloader",
size: 0x00020000,
offset: 0x00000000,
mask_flags: MTD_WRITEABLE, /* force read-only */
}, {
name: "root_fs",
// Codeman's original:
// size: 0x000fa000,
// My efforts at making a root partition:
size: 0x00040000,
offset: 0x000f0000,
}
The first I'm not really doing anything with, but it could (as the title suggests) be turned into a bootloader partition someday. The second is where I'm concentrating my efforts. The read-only flag that was originally in there was removed once I figured out it might help matters. :-) Okay, so now what? Well, got a jffs2 image that I created, so let's try the obvious:
# cat test.jffs2 > /dev/mtd1
...and it just hangs. (I still haven't bothered to figure out how to
make CTRL-C interrupt a process yet...something to do with the
terminal, I think.) Up the debugging output and you see MTD_open,
and then nothing. I had a look at the part of the driver
(drivers/mtd/chips/sst39vf080.c) to see what's going on here, and I
managed to figure it out a bit. The write operation tries to write one
byte at a time, then reads it back to make sure it got read. If so,
move on to the next byte; if not, try 256 more times (I guess waiting
to see if it just needs a moment) and see if that works. If yes, next
byte; if not, give up on the write entirely. I threw in some messages
to track that, and one that shows what value it's reading back from
flash after the write. After throwing in ridiculous amounts of
debugging info to track this, it seems that the write of the first
byte is simply not working. The write fails, and cat just keeps on
trying (or something). A bunch of looking around finally turned up
the MTD-JFFS-HOWTO from (I think) the guy who wrote the MTD
driver. 'S full of all sorts of helpful hints, like:
cp test.jffs2 /dev/mtd1 to copy stuff to flash (but I got the same result as with cat),mount /dev/mtdblock1 /mnt && cp foo /mnt), andWell, fuck. So I follow the directions for the 2.4 kernel
support, and figure out how to compile the flash_eraseall
utility. Wonderful! Ready to go! Just gotta erase this here partition,
and... Only no, that doesn't work: I get the same error re: the byte
not being written as before. I'm currently throwing in even more
unholy amounts of debugging than before, and teaching myself the
simplest bits of binary arithmetic you can image, in order to confirm
that, yes, write protection is being turned off...I think. This
little-endian thing still confuses the hell out of me. The datasheet
sez that, at the address the enable_write() operation is accessing,
there are 32 bits set aside for controlling the first bank of flash
(which is what we're after here). The 26th bit is write-protect (1 for
on, 0 for off). enable_write() reads all 32 bits at that address,
&'s it with 0x04000000, and then WP should be off. So the unholy
debugging shows that the long int being read:
Okay, so that works. Maybe I'll give the flashcp utility (part of
the MTD tree) a try and see how that goes.
...and it's another Wine problem. Coworker says he's having trouble, as of a couple days ago, running Wine on machine Foo, a FreeBSD machine that lots of people use. He's running into these errors:
err:ntdll:RtlpWaitForCriticalSection Critical section 0x65430070 wait timed out, retrying (60 sec) fs=008f
err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x280abf94
...which is pretty strange, and doubly so since he's only having this
problem on Foo -- machines Bar and Baz are working just fine. I spent
entirely too much time fucking around with --debugmsg +all,
truss(1) and ktrace before I finally thought to check:
$ ps auxw | grep wine
coworker 81344 2.0 0.0 0 0 p3- Z Tue11PM 0:00.00 (wine)
coworker 81341 0.0 0.2 11120 1452 p3- I Tue11PM 0:00.34 (wine)
coworker 81343 0.0 0.0 3100 324 ?? Is Tue11PM 0:00.12 wineserver
Sigh. Kill off 81341, the rest fell too, and it all worked again.
Tags: wine
title: Sigh II date: 2005-09-20 17:56:40
Seeking individual with access to quality lists of opt-in email addresses to mail to. Offer is to be geared to US addresses, Mortgage Refinance.
Why is it that only spammers advertise on Craigslist?
Tags:
FYT #1: New Firefox 1.5 Beta. It's great: wicked fast, and they've added drag-n-drop tabs. Slashdot comment pages render in a heartbeat. But it's pissing me off right now for two reasons. First, the Profile Manager only seems to come up if no other Firefox window is running. If there is another window running, it comes up with that profile no matter what arguments you pass (-P, -ProfileManager, -P Profile Name, ). (When I was first writing this entry, I tried that last one just to make sure. When the current profile came up yet again I closed it -- but closed the browser window that had this entry, too. I'm writing this in vi in an xterm now.)
This is irritating because I have two profiles: Default and Wide Open. Default is where I spend nearly all my time; Java, JavaScript, pop-up windows and flash are turned off; AdBlock shoots to kill; animations go once and then stop; I'm asked about cookies. I hate dancing baloney. Wide Open is where I go if I need to visit my bank's website (it's not that wide open, of course), or if there's something that won't work in my Default profile that I'm convinced is worth the effort (which doesn't happen often). Keeping two profiles is much easier than toggling all that nonsense each time.
Second, a lot of the extensions I love aren't yet ready for 1.5 (or at least, don't say they're ready...I seem to remember when the upgrade to 1.0 happened that you could edit some of the extensions directly and just lie about what version was required). Adblock is running -- if it wasn't for that, I don't think I'd be using the new version at all. But Session Saver, Sage and Mozex aren't, and I've come to rely on them. We'll have to see.
FYT #2: I went into work this morning to reboot a couple of servers. I'd let everyone know about it, and got up with my wife at 4.45am. But when I got to the building, the card that let me in the front door would not make the elevators go -- they just sat in the lobby waiting for, I don't know, drugs or Jesus. (Double punishment!) I'd used the card before to make the elevators go, so WTF? (Stairwells are not an option; you can't get into your floor [or any other] using your key or any access card.)
After failing to find a security guard anywhere, I called tenant services for the building. They said that the elevators might be turned off, but they couldn't be sure; I could get a better answer calling back during the week. (Fair enough, since our building's managed by a company that owns buildings all across Canada.) Oh, and security starts at 8am. Fuck. I'll have to reschedule for during the week, but after making sure that I can get in at 6am. Double fuck!
FYT #3: Why am I rebooting servers? Good question: they're running FreeBSD, after all, so it's not like it should need to happen all that often. The answer is: because amd sucks ass through straws. Not only does amd:
create a mess of symlinks (people who complain about SysV init
symlinks messes need to look at amd: /home/foo symlinked to
/net/machine/home/foo symlinked to /.amd/_mnt/machine/host/home/foo,
the only place the directory is actually mounted) (interesting: quick
Google for sysv init symlink turns up this post by my
namesake)
interact badly with FreeBSD symlink caching (okay, FreeBSD's fault maybe)
but it will also get wedged sometimes, requiring a reboot -- and
don't talk to me about the -r option for amd, because that simply
doesn't work.
F'r instance: a while back one guy at worked moved from FreeBSD to Linux. I took the opportunity to give him a bigger hard drive; he'd had a second one, mounted at /home/foo/scratch, because he'd run out of room on the first. Unfortunately, one of the servers in question had /home/foo/scratch mounted at the time through amd -- and when his machine came back online w/no scratch directory, amd/NFS refused to umount it and refused to mount his home directory, because the bogus /home/foo/scratch was blocking it. That's what this morning's reboot was meant to get around. Okay, again, not all amd's fault -- NFS and me, not in that order -- but still.
I mentioned two servers, though, so what about the second? Aha, that's the symlink caching thing. We get around this by running a newer version of amd than is supplied w/FreeBSD; it doesn't have quite so many problems. But I'd missed the second server, and it didn't have the pointer to the newer version of amd. Again, my fault -- I should've caught this a long time ago -- but dangit, it shouldn't be necessary to do this just to restart amd. (I'm setting up cfengine to catch this sort of thing. cfengine rox.)
Minor update re: earlier problems with Vinum and a Maxtor IDE card: I picked up a new RocketRaid 454 that was reputed to work much better, plus had four controllers rather than two. Cheap, too -- $135. Long story short is that it still caused problems, I think; the machine seized up again in the middle of backups, apropos of nothing and with no message or panic. (Took a while for this to happen, though, so it was an improvement. I think I should've taken to heart the warning I got a while back that Vinum was not the most stable of code.
title: New machine, or, How does one crack Solaris 2.8 again? date: 2005-09-10 17:20:43
I went out to the swap meet today, but I couldn't get excited about anything there. I'd gone out hoping to find a Sun workstation or some such, and nothing. Closest I got to interesting was the guy offering a stripped bare P2 laptop -- no battery, no hard drive, no CD, no floppy, and a busted screen -- for $100. Oh wait, not interesting -- crack-induced. That's what I meant. (Yeah yeah yeah parts nothing.)
So I took off to go see Cal, since I was (sort of) in the neighbourhood. I was a lot happier when I found the upstairs where they'd hid the good stuff -- including a SparcStation LX and a Sun External Hard Drive, model 411 (4.5GB Seagate Barracuda, baby!). Even managed to find a keyboard and a cable and a 25-to-9-pin serial adapter. I was briefly tempted to buy an SGI keyboard, which looked like it'd been made to beat Communists to death, but resisted. Stuffed it in my backpack and brought it home...man, those things are pigs.
I hooked up a serial port, tried the magic keycodes, and nothing. After wiggling the keyboard cable a bit I could get the keyboard to beep at power-on (speaker in a keyboard? no wonder Sun's got such a good rep...:-), but nothing else -- not even the caps lock light. Well, what about networking? Yep, it's working, and appears to be convinced that it's kootenay.cs.ubc.ca judging by the ypbind requests.
A quick nmap and rpcinfo -p confirmed that all it had open was
portmapper and ypbind. Allegedly, the POST has failed if the
caps lock key doesn't flash -- but surely it wouldn't be running RPC
services if that were true. ..which is going to make cracking it over
the crossover cable a little difficult. It's not exporting any
directories. I figure I can spoof the domain, but then what?
In other news: Firefox moved the tab select key from Ctrl to Alt (ie, Alt-3 selects the 3rd tab). I thought this feature was completely gone a few versions back, and was quite sad. Finally figuring it out makes me happy.
Tags:
Things are coming along on this router, and I've managed to make some progress on a couple of fronts.
First off, I've managed to get access to the flash memory on this thing. It's a little embarrassing, because I went through a lot of code in the mtd section of the kernel before realizing that I had simply not included the driver in the configuration file. Managed to learn a bit about how it fits together, though, so it wasn't wasted effort.
I've been able to get the contents of the flash out -- at least, the bit that's covered by the memory map that Codeman put together in his driver, which is about 1MB of the 2MB on board. Still, that appears to include the bootloader menu on this thing, which is good; with luck I'll be able to figure out the checksum for that, and maybe upload armboot or something. Of course, I could always just overwrite the flash directly...but I'm a little scared of that. We'll see.
The other thing that this'll lead to, of course, is including a filesystem in the flash memory itself. Right now I'm mounting everything by NFS, which is very flexible but not terribly self-contained. With something like JFFS2 and a separate partition for the kernel, I should be able to have something pretty skookum.
I ran into some weirdness with Minicom and the serial port: at random times, for reasons I couldn't figure out, the display from the router would get all scrambled. Letters and newlines would be dropped, or transposed, or just garbled out of recognition entirely. I tried everything I could think of: power-cycling the router, letting it cool (it doesn't take long for it to heat up, and things tend to go south pretty quickly when it does...must do something about that), swapping cables, swapping serial ports, exiting minicom, trying other serial port terminal programs (and let me tell you, there aren't many for Linux). Eventually I gave up and ran:
cat /dev/ttyS0 & cat > /dev/ttyS0
which worked perfectly: I could watch it boot, run commands, all
that stuff. I could even see that the shell was using colours for
ls, which made me wonder if maybe that was a problem.
Finally, though, it came time to try uploading another kernel image. I
tried fooling around with sb, but while I could get it to upload to
the router w/o problems, it was difficult to get the timing right when
it ended, and the image didn't seem to load properly. All right, I
thought, I'll use Minicom just for uploading. But check it out: when I
ran Minicom again, it was perfect -- no display problems at all. Still
don't know what changed, but I'm glad it's working again.
This led me to try getting the telnet daemon from BusyBox working...if
I can't use a serial port, why not just use the network? But getting
it going is going to take some work. With uClibc, there is neither a
fork() nor a daemon() routine, both of which are used by
telnetd. Instead, you get vfork, which lets a child run but blocks
the parent until the child calls either exit() or exec. So, as
uCdot points out, the trick is to do exec() the same program,
but with a command-line option that tells the application that it's a
child, and should be treated accordingly. Good trick.
By the time I realized that, though, it was midnight, and I figured I'd be too tired to do it coherently. And then I got the flash memory working, so I was distracted. Coming soon, though...
On another note: on Friday my wife and I went with the famous Victor Scott to see Ted Leo and the Pharmacists. Holy fuck can that man play. And his drummer! His drummer has the beard I want plus all the drumming chops in the entire world. The last drummer I saw who was anywhere close to him played for Wilco; before that, Lotion. Absolutely fucking amazing, and a must-see if you ever get the chance.
Hon. mention to opening band The Parallels, for whom I can't find a website. Great 60s-mod outfits and music, and a fun show.
Tags: nwr04b
...but when you use the word "solution", do you mean:
I'd include links, but I think it would kill me.
Tags: rant
From Ant's Eye View:
You should assume that systems on the public network will be abused. This is a lesson as old as the Internet, but every programmer seems to have to learn it for him/herself: if you make a system available to the public, people will abuse it.
Worth reading.
Tags: toptip
title: Hah date: 2005-09-01 20:03:00
From the OpenSSH FAQ:
_Why should it be used?_ [snip] _No need to retrain normal users._
So I've got a low humour threshold. Sue me.
Tags:
title: APIC error on CPU0: 40(40) date: 2005-09-01 19:19:22
Getting tons of error messages on a machine here at work like this:
APIC error on CPU0: 40(40)
A quick Google turns up this message suggesting a problem with SiS chipsets and APIC. Sure enough, this machine does use the SiS chipset...I've come to be very suspicious of SiS chipsets: lots of trouble, and not worth the money saved compared to (say) a mobo with an Intel chipset.
Tags: