The_resemblance_is_uncanny
08 May 2005title: The resemblance is UNCANNY date: 2005-05-08 09:16:38
From here, via As Days Pass By.
Tags:
title: The resemblance is UNCANNY date: 2005-05-08 09:16:38
From here, via As Days Pass By.
Tags:
I followed Cyberdyne's suggestion and looked at the link options for the kernel I'm making for the NWR04B. So far, it looks promising, though I'm not that much better off. The problem was that the argument for puts, which should've been the address of some text to print to the screen, was 'way off and as a result I was seeing garbage. A closer look (with some paying attention this time) showed that, instead of being passed the address 0x28a0 (where you'd see EXMIF -- FIXME backwards), it was being passed the argument 0x428a0. And sure enough, in arch/armnommu/boot/Makefile, whaddawe see but this:
ifeq ($(CONFIG_CX84200_SMC),y)
#ZRELADDR = 0x00040000
#ZTEXTADDR = 0x00000000
ZRELADDR =0x00008000
ZTEXTADDR =0x00040000
INITRD_PHYS =0x00700000
endif
This page told me that ZTEXTADDR is, basically, the address in memory where the kernel should expect to start -- or in this case, where the decompressor (I'm doing make zImage here) should expect to start. That sounds like something that would affect where things get put, all right, so I tried changing ZTEXTADDR to just 0x0 -- and sure enough, the argument passed to puts has the right address this time. But still no joy: when I load the image, I still don't see that EXMIF, but just a single character (which is better than the 416 characters of crap I was seeing previously) of uncertain ancestry (because for some reason the capture of serial port output to a file upon which I could run hexdump was not working). And furtherly furthermorish, that 416 characters of crap I was talking about were found in the original image starting at 0x418a0 -- an offset of 0x3F000, or off by a thousand from what I would have expected. So, like, what, memory is starting at -0x1000? Arghhh.
Tags: nwr04b
title: Turning an IBM USB Webcam into an IR Webcam date: 2005-05-07 14:23:38
Following the instructions here, I was able to get my $14-at-Walmart-in-Oregon-four-years-ago IBM USB webcam seeing infrared without too much difficulty. Since getting the IR filter out proved to be a bit tricky, and since the note on this camera on Geoff's pages just said "Tricky to find", I thought I'd put up some pix and instructions on how to do this. I'll be curious to see how well it works tonight...I live above a busy street, and I'm hoping I'll be able to get some neat pix.
Tags:
title: Nice! date: 2005-05-07 14:39:59
Just came across the Open Source Labs' photo album. There are some pretty funky pictures in there. Oh, and what look like some servers labelled in Braille. Man, I gotta work at a university.
Tags:
title: If there's one thing I can't stand... date: 2005-05-07 20:13:21
...it's long-haired, shouty, short pregnant people in the streets. I'm totally voting for Lorne.
Tags:
title: Wireless link fast date: 2005-05-04 05:52:20
It was a duplexing problem, though not like I thought. The radio link in a Tsunami is duplex, and the ethernet interfaces also do duplex, but they don't do auto-negotiation. Setting the interfaces on the computers at each end to 100Mb/s full-duplex worked a treat, and now I'm getting something between 20 and 40 Mb/s -- completely respectable.
Tags:
title: Wireless link up date: 2005-05-03 06:26:30
Welp, the wireless link got set up yesterday. We've now got two Tsunami 100s (unfortunate name, that) installed and pointing at each other from our office windows. Rough guess is that it's something like 150 metres between the two units. OpenVPN worked right away, which makes me happy. Ping times were good between the two units -- 4 or 5 ms.
I tested it by copying the same big-ass file from one end to the other that, over a crossover cable, took less than 2 minutes to copy -- and was shocked to find the ETA listed as 16 hours and climbing. What the...but then I visited the other side and found that the ethernet cable had been connected to the 10Mb/s jack, not the 100Mb/s jack. This made things better, but still crappy: 30 or 40 minutes was the ETA.
Near as I can figure, we're getting about 1.5Mb/s on this thing, which isn't much different from ADSL. The units are half-duplex, and I suppose that could be affecting things somehow (besides the obvious, I mean), but that still seems terribly low to me. I spent most of yesterday getting other things in the new digs working, so I didn't have a chance to call the company who set it up; that'll be today's job.
Another gotcha from the move: turns out that our voicemail system (Norstar something or other) actually requires a phone to be physically present in order to send a call to voicemail after n rings. That was a bit of a surprise. We're currently scrambling to get some extra phones to leave hooked up. (Don't even ask why voicemail or their direct lines doesn't work at the new office.)
Tags:
title: Some notes on OpenVPN, bridging and FreeBSD date: 2005-05-01 10:55:18
device tap0 directive in your config file, then set these sysctl variables:
net.link.ether.bridge_cfg: dc2,tap0 -> dc2,tap0
net.link.ether.bridge: 0 -> 1
This assumes, of course, that dc2 is the inside interface you want bridged over the VPN.
* If OpenVPN exits for some reason, you need to turn bridging off by setting the net.link.ether.bridge sysctl to 0 before starting OpenVPN again. Near as I can figure, this is because the new tap0 interface is different from the old one, even though it has the same name, because it was created by a different PID.
* No problems getting OpenVPN to run under djb's daemontools so far, as long as I toggle bridging as part of the startup script.
* On one machine, the inside interface being bridged was sis0, an onboard ethernet interface. This led to worlds of hurt: if OpenVPN went down then started again, everything would look good but the bridge wouldn't work -- I could no longer ping that interface from the other side of the bridge. Furthermore, trying to ping from that machine to the other side of the bridge got me this error: ping: sendto: no buffer space available Googling for this turned up many, many references to this problem. It seems to be a long-standing bug in FreeBSD, present to this day (!) and with no fix (!!), that may or may not have something to do with particular ethernet drivers. I thought I would have to install Linux and rebuild it -- this was on Friday afternoon, and the VPN is meant to be set up this Monday -- but I took a chance and bought some different ethernet cards (Linksys LNE100TX-CA ver 5.1, which in FreeBSD show up as dc(4) devices; thank you, London Drugs) and so far I haven't seen the problem again.
* The machine with the problematic sis0 interface is a 2GHz P4; the other side is a 3GHz P4. Both have 512MB of RAM. If I restart OpenVPN on the slower machine, pings take about 30-40 seconds to start working again; if I restart the faster side, it's almost instantaneous. (Both sides know the address of the other side, and both are set to re-initiate the connection if it goes down.)
* For testing, the setup is something like this:
Client A -- Slow machine -- (OpenVPN here) -- Fast machine -- Client B
Copying a big-ass file from Client B to Fast Machine takes 1 minute; if Client A copies the same file to itself, it takes about 1 minute 20 seconds; if Slow Machine copies the same file to itself, it takes 1 minute 40 seconds; and finally, if Client B copies that same file from Slow Machine to itself, it takes 1 minute 10 seconds. (Copying is done by scp in all cases; Client A and Slow Machine are connected by a crossover cable, as is Slow Machine and Fast Machine; Fast Machine and Client B are connected through by a switch or two.)
Tags:
title: Holy crap, IT'S ME date: 2005-05-01 12:56:31
A friend of mine sent me this link, and Jesus Christ it looks like me. Family Guy on tonight. Woohoo!
Tags:
I got the iBook, I got the Slashdot t-shirt, I got the beard...but do you think I can get a wireless signal? Oh no. Thanks, Broadcom. But hey, enough complaining. Time for an update.
The wireless ISP is gonna do a point-to-point link between windows of our old and new temporary offices. Should give us 100Mb/s access or so. Which is good, because for a while I thought I'd have to walk down to London Drugs, grab some Linksys routers, and install my own firmware to do it. Which would have been a lot of fun...but would have been a fuck of a lot to get ready in, like, three days. Now I just have to get OpenVPN talking at either end, get Shaw installed, and set up a firewall. Oboy.
And then there's the troubles I've been having with our backup server. A while back I decided to start racking all the boxes we've been using as servers -- transfer the hard drives to proper servers, then use the old shell as a desktop for a new hire. Welp, the backup server was the first to go, and man it's been a headache.
First off, I didn't take care of cooling properly, and the tape drive (HP Ultrium 215, for those paying attention) suffered a nice little nervous breakdown and kept spitting out the tape. I tried downloading the HP diagnostic tool, but it only runs on Linux and the server runs FreeBSD -- neither Linux compatibility mode (not surprising) nor a Knoppix disk (kept hanging) allowed it to work. So I had no real idea what was going on other than the drive was too hot for my liking.
But HP, bless their souls, came to the rescue. Once I made it through their speech recognition voicemail tree hell, they just sent out another one -- they didn't even bitch about not being able to run the diagnostic tool. Not only that, it came the next day, and we don't even have any special contract with them -- that's just warranty. Thumbs up for them.
But now I've got different problems: the damn machine keeps seizing up
on me. See, I've got this 500GB concatenated Vinum array of three
disks that I use as a copy of yesterday's home directory for people,
and I'm trying to move it to a four-disk RAID5 drive on the Promise
array. I tried using rsync, and it just froze...but eventually. I
thought maybe rsync was spending too much CPU time figuring out what
to transfer, so today I tried using dump | restore -- and sure
enough, it froze again.
I plugged in a monitor, hoping for a panic or something, but nope -- just unresponsive. I've found some mention in the FreeBSD mailing lists about possible problems with write caching and the Adaptec 3960D SCSI controller (which I thought was a 39160 SCSI controller, but I guess not). I'll have to see if that does the trick or not -- but in the meantime I'm wondering how I'm gonna get yesterday on the Promise. Of course, figuring out why it's crashing in the first place would be even better...
But it's not all bad news: earlier this week, the support manager at Promise that I've been dealing with called to tell me that the word had come down from on high. Yep...Promise is going to follow the GPL and properly release the Linux and Busybox source code for the firmware that goes into the VTrak 15100. Hurray! I'll have to watch, of course, and make sure it shows up...but it sounds good. "Let's put it this way," said the manager. "It's on my desk for me to do. And I don't want it there for long." To the home front, now.
As if I didn't have enough on the go, I've blown my tax return on the makings of a MythTV backend: 2.4GHz P4, umpty-GB hard drive, the PCHDTV-300 (get it while you can!), generic 128MB Nvidia (no onboard video on this mobo, or I would've stuck with that), a Hauppauge PVR-500MCE, and a nice Asus mobo in an Antec case to tie it all together. Random notes:
And now for something completely different: new mottoes for Harley Davidson:
"Harley-Davidson: Because social contracts are for weak pussy-ass losers with small dicks."
"Harley-Davidson: Because those other people aren't really human. Not like you and me."
"Harley-Davidson: You deserve it. So do they."
"Harley-Davidson: Because if you pissed in their faces, you'd be arrested."
"Harley-Davidson: Because 'Fuck you!' is just too damned hard to remember."
"Harley-Davidson: Because 'Fuck you!' is just too damned eloquent."
title: Screen & date: 2005-04-29 19:36:28
Problem: Screen, installed from ports on a 4-series FreeBSD box, start taking 99% of the CPU (!). Solution: Build from ports. Don't know why I didn't try that sooner. Also: an ampersand ends a command in Bash the same way a semi-colon does. Thus, this is wrong in a Makefile:
all:
foo & ; \
bar
And this is right:
all:
foo &\
bar
Whee!
Tags:
At last, Promise sends over the MIBs for the VTrak 15100. I've put 'em up with the kernel and busybox sources. Still waiting to hear when they're going to comply with the GPL re: offering source.
Tags: gpl
Still trying to figure out what the hell is going on here, and why it
won't print the messages I expect it to (while still printing the
FIXME I stuck in at the end of the puts routine w/o any
problems). I've been looking at the disassembled zImage, and I'm
scratching my head. Here's the deal: shortly after power-on, the
decompress_kernel routine is run:
000074 EB000915 BL &000024D0
In C, decompress_kernel looks like this:
ulg
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
int arch_id)
{
output_data = (uch *)output_start; /* Points to kernel start */
free_mem_ptr = free_mem_ptr_p;
free_mem_ptr_end = free_mem_ptr_end_p;
__machine_arch_type = arch_id;
puts("EMXIF");
proc_decomp_setup();
arch_decomp_setup();
makecrc();
puts("Uncompressing Linux...");
gunzip();
puts(" done, booting the kernel.\n");
return output_ptr;
}
At 0x24D0, we've got some initilization, some register saving, and then the puts routine is called:
0024FC E59F0034 LDR r0, &00002538
002500 EBFFF769 BL &000002AC
This is the first call to puts: puts("EXMIF"); (which is FIXME backwards; I had it frontwards at first, and wanted to see if the output was any different if I changed the string; it's not). puts looks like this in C:
static void cx84200_puts(const char *s)
{
while(*s != '\0')
cx84200_putc(*s++);
cx84200_putc('F');
cx84200_putc('I');
cx84200_putc('X');
cx84200_putc('M');
cx84200_putc('E');
}
(more checking to see what works) and like this in ARM assembly:
0002AC E1A0C00D MOV ip, sp
0002B0 E92DD810 STMFD sp!, {r4,r11,ip,lr,pc}
Save the registers for later...
0002B4 E1A04000 MOV r4, r0
0002B8 E5D43000 LDRB r3, [r4, #0]
0002BC E24CB004 SUB r11, ip, #4
0002C0 E3530000 CMP r3, #0
0002C4 0A000004 BEQ &000002DC
r0 held the argument, and it's moved to r4. Check the first byte to see if it's zero (ie, if we're printing a null string), and jump ahead if it is. Not sure what we're doing with r11 here.
0002C8 E5D40000 LDRB r0, [r4, #0]
0002CC EBFFFFEB BL &00000280
0002D0 E5F43001 LDRB r3, [r4, #1]!
0002D4 E3530000 CMP r3, #0
0002D8 1AFFFFFA BNE &000002C8
Load the first byte again into r0, then go to 0x280 (putc) with it. Increment r4 and see if it now points to a zero. If not, go through the routine again.
0002DC E3A00046 MOV r0, #70
0002E0 EBFFFFE6 BL &00000280
0002E4 E3A00049 MOV r0, #73
0002E8 EBFFFFE4 BL &00000280
0002EC E3A00058 MOV r0, #88
0002F0 EBFFFFE2 BL &00000280
0002F4 E3A0004D MOV r0, #77
0002F8 EBFFFFE0 BL &00000280
0002FC E3A00045 MOV r0, #69
000300 EBFFFFDE BL &00000280
This is the printing of FIXME at the end of puts.
000304 E59F0008 LDR r0, &00000314
000308 E20000FF AND r0, r0, #&FF
00030C EBFFFFDB BL &00000280
Put 0x314 into r0, AND with 0xFF, then call putc again.
000310 E91BA810 LDMDB r11, {r4,r11,sp,pc}
000314 00042548 ANDEQ r2, r4, r8, ASR #10
And I think this is where we fall off the end of puts. Finally, a quick look at putc, first in C:
static int cx84200_putc(char c) {
int i;
int j = 10;
CSR_WRITE(UART0_BASE, c);
for (i= 0; i < 60000; i++)
;
}
(j left over from another bit of debugging) and assembly:
000280 E1A0C00D MOV ip, sp
000284 E92DD800 STMFD sp!, {r11,ip,lr,pc}
000288 E24CB004 SUB r11, ip, #4
00028C E3A02CEA MOV r2, #&EA00
000290 E2822060 ADD r2, r2, #96
000294 E20000FF AND r0, r0, #&FF
000298 E3A03209 MOV r3, #&90000000
00029C E5830000 STR r0, [r3, #0]
0002A0 E2522001 SUBS r2, r2, #1
0002A4 1AFFFFFD BNE &000002A0
0002A8 E91BA800 LDMDB r11, {r11,sp,pc}
So here are my many bits of confusion:
puts should have r0 pointing to EXMIF, right? Only it doesn't: 0x28A0 is where you can find this string, and r0 points to 0x2538. There's no ASCII there, and certainly no copy of the string I want. If I change the instruction so that r0 points to 0x28A0, the thing crashes badly -- just spews out hexdumps of something (presumably memory).putc from puts, where r0 points to 0x314. WTF? It explains why I'm seeing H% at the end of the strings, but as far as I can tell it certainly shouldn't be doing that. Again, there's nothing around 0x314 that would explain why we're trying to print it.putc, what is with AND r0, r0, #&FF? As far as I can tell, this has absolutely no effect on r0: it's a NOP.I can only think of three things:
If anyone has any insight to share, please let me know. This is really bugging me.
Tags: nwr04b
Less and less impressed with Promise. Here's what I had done: while doing some copying onto a logical drive, I yanked one out. I wanted to see what would happen, what would need to be done, and so on -- I don't want to be figuring this out for the first time when it happens. Well, it started beeping, and the event log said that the logical drive was critical. Start rebuilding, right? Wrong: policy for that drive was set to non-auto-rebuilding. Try turning that on, and it doesn't work: keeps saying it's non-auto-rebuilding. Manual for the VTrak:
if your fault-tolerant logical drive goes offline, go to the Promise website (www.promise.com) and download a document calledArray Recovery Procedure.
Damn good thing I'm not doing this for real. Go to www.promise.com and type "array recovery procedure" into the search bar. The result:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot use a CONTAINS or FREETEXT predicate on table 'product' because it is not full-text indexed. /search_insert_eng.asp, line 34
Fuck me. Use Google to find the document, which has instructions for the UltraTrak, the predecessor to the one I've got. Hope it still applies and read on. It sez to reboot the array (!) in order to trigger the rebuild (!!). Sure enough, it works. Oh, and have I mentioned they still haven't sent me the SNMP OIDs/MIBs after six weeks of calling their technical support manager? FUCK ME.
Tags: hardware
I'm starting to make a bit of progress on the NWR04B -- almost to the point where I could comfortably say it's crashing. Yay! The problem so far has been that I wasn't getting any output on the serial port when (presumably) Linux was booting. Some judicious insertion of ARM assembly code into the kernel image showed me that it was at least running, but I had no clue what I was doing after that. I managed to follow the path of the assembly code through head.S, which is the very, very first bit of anything that gets run when you've got a compressed kernel. This is so early that it takes a while even to get around to decompressing the kernel. After that, I was able to follow it through to misc.c, where decompress_kernel gets run. There's some puts statements in there (like puts ("Uncompressing Linux...");), so how come I wasn't seeing anything? Well, because puts wasn't defined as anything. puts is defined in head.S as some assembly code to write a string to the serial port, but that wasn't referenced by misc.c; attempts to #include it failed horribly. There's an #ifdef STANDALONE_DEBUG that defines puts as printf, but attempts to build a kernel using that didn't work either. But follow the bouncing ball:
arch/armnommu/boot/compressed/misc.c #includes asm/arch/uncompress.hinclude/asm/arch/uncompress.hinclude/asm-armnommu/arch-cx84200/uncompress.hputs as cx84200_putsuncompress.c defines that as being an empty functionarch-samsung defines it as a bunch of calls to putc``CSR_WRITE(DEBUG_TX_BUFF_BASE, c)CSR_WRITE(UART0_BASE, c)UART0_BASE is defined in hardware.h as 0x90000000UART0, aka serial port 1.Whew! So I tried that, and hey -- I got garbage on the screen! But not very much: I was expecting something like "Uncompressing Linux..." and instead got maybe 20 characters of garbage. I took another look at the assembly version of puts, and one of the things it does is waits for 20,000 clock cycles -- which at 60MHz is a third of a second. Try adding a loop to count down 60,000 cycles (what the hell), and hey! more garbage -- though still a finite amount, and it stopped after maybe 5 seconds or so, and still nothing intelligible. What the hell's going on? I tried this:
static void cx84200_puts(const char *s)
{
while(*s != '\0')
cx84200_putc(*s++);
cx84200_putc('F');
cx84200_putc('I');
cx84200_putc('X');
cx84200_putc('M');
cx84200_putc('E');
cx84200_putc("\n");
}
and now I started to get garbage that had FIXME tossed in for good measure. A quick cat /dev/ttyS0 > logfile (have I mentioned that I love Unix?), and whaddaya know: I'm getting precisely four FIXMEs. If I threw an extra puts ("FIXME"); into misc.c, I got five, not six -- the string going to puts doesn't come out, but the extra putcs I put in do work. For the moment, this is where I'm stuck. The garbage/extra characters I'm seeing don't seem to have any relation to messages I might expect ("FOO", "Uncompressing Linux...", etc. There's places for the kernel to crap out after that, but I don't think there's any before. And why the hell am I seeing all the garbage, then a perfectly intelligible "FIXME" after that? What is happening to the strings to get them all fucked up?
Tags: nwr04b
Holy crap, I'm busy these days. First off, it's MS patch week. That
means I'm in here on a Saturday afternoon patching by hand. Yes,
you're right, it's very ugly; this is why I'm trying out a couple of
things that I hope will make it easier. The first is Daisy, a
program (and by the way, the next time someone says "solution" when
they mean "program" ah munna punchem inna cock) from the
University of Virginia Virginia Tech (thanks, Joe)
that
It has a couple problems that seem mostly due to the program they use to scan for missing patches -- always seems to say that the same three patches are needed, whether or not they've been applied -- but overall I'm quite happy with it.
The next thing I'm trying is running Daisy
remotely, by installing Cygwin and SSH on each of the
machines. Unfortunately, this isn't working so well; the same
command-line options that work from a local shell (whether Cygwin or
cmd) just don't when I'm logged in by SSH: it says that it can't see
that any patches have been applied, tries to download 'em all from
the local repository I've set up, and is very unhappy when they're not
there.
Next thought is to try installing crontab and shutdown with Cygwin and use crontab to run Daisy (or other patches) locally. That has problems too: Cygwin looooooves updating everything, and if you've (say) installed Cygwin a year ago and haven't bothered updating it since, it runs around trying to download newer versions of everything. What's more, there's no way to turn off that behaviour in the installer...very annoying. I think I'll try installing crontab and shutdown individually (managed to find a script a while back to do that properly), and see how it goes. Of course, since I've just applied all the patches for this month, it's gonna have to wait.
Which is fine, because second, I found out on Thursday that a dozen people are moving to a temporary office for two months, they'll be there May 2nd, and I have to make sure they can still work while they do that. A bunch of them are doing nightly regression tests; this means their files will need to be here, but a 1Mb/s cable link and X forwarding is gonna be mighty painful. (Or so I'm told...why they can't just use SSH and vi for everything is beyond me...grumble...)
I called around to see if anyone could set up a temporary LAN extension over fiber or some such, for two months, with two weeks' notice. HA! Not a chance: a six-month contract and a six-week lead time was the best anyone was willing to offer. But hey, not a problem -- the new place is maybe 150 metres away as the crow flies, and we've got line of sight in between here and there -- hell, I can see the corner office from here.
So I called up Telus and asked them if they could do this. "Sure can!" said the bright young man I was dealing with, and you could hear the wind from his enthusiastic nodding. "We'll do 802.11g between here and there. It's perfect! And it only takes 8 weeks to do a site survey!" I reminded him of my two week deadline. "Not a problem! We'll just convert it after the move to wireless Internet access over your entire office! The boardroom, the desktop, the kitchen...and we remotely monitor it to prevent intrusion! We'll use whatever authentication standard you're using! We try to stay away from WAP, but we can use WEP if you like!" Sigh...okay, how much? "Forty-five thousand dollars. How soon do you think you'll be able to take advantage of this opportunity?"
Fortunately, I found another ISP that's interested in mounting an antenna on the roof just to be able to offer their service to other tenants. Looking good so far. And since they offer gigabit Internet access for $500/month, I'm thinking the price can't be that bad. (Yeah, gigabit 'til the first router that isn't theirs. But still.)
Third, I'm still trying to get the Promise VTrak up and running here. Still running out of space, still haven't had much time to play around with it. Well, except for today. Starting to find a couple things that are annoying (besides the GPL violations, I mean). First off, it looks like changing the cache policy on a logical drive (ie, from write-through to write-back) requires a reboot of the array itself (!) to take effect. Second, even without changing the write-back policy, it looks like a reboot of the array makes a newly-created logical drive orders of magnitude faster -- ie, bringing it up to an acceptable speed. (I'm not certain of that, though, so grain of salt etc.) Third, no MIBs/OIDs -- whatever the proper term is -- for SNMP are shipped with the documentation...still trying to get this out of Promise.
Tags: windows
but I was finally able to track down the original for this picture. It's absolutely amazing...just like this and this. Strange how you change. I used to read and re-read Huckleberry Finn 'til I wore out my copy, wishing I could've lived in 19th century America. Now I'm afraid I (or my species) won't live long enough to get into space, and wish I could be part of some grand colonizing effort.
Tags: space
title: More work on the Promise Vtrak 15100 date: 2005-04-17 07:46:59
I don't know what I did right, but I've had a lot more luck with the Promise VTrak 15100 this time. I got a chance to work with it more on Monday, and this time it just worked.
For the record, what I'm using for testing is a P4 running FreeBSD
4.10, an Adaptec 39160 card, and the VTrak with 4 disks. I had set
them up in one RAID 5 array on Saturday, and was unable to see the
disks at all. This time, I deleted that array, created a new RAID 0
array of one disk, rebooted FreeBSD, and bam -- da0 was right there
in dmesg.
I set up another RAID 5 array of three disks, ran camcontrol rescan
all, and there was da1. Very strange.
Strangeness continued: the two disks were sloooooow when I first
used them. The first array was about 250GB, and the second was 450GB;
running newfs took 7 and 14 minutes__, respectively. To make
sure it wasn't something specific to formatting, I ran dd
if=/dev/zero of=/mnt/test bs=100m count=100, and the times were
similarly ridiculous: between two and three minutes, compared to 2-3
seconds on a local, IDE-based drive. WTF?
I decided to reboot the VTrak, and the problem went away: the dd
test took about 3-4 seconds...slower than a local IDE drive, but
acceptable. Still no idea what might've been going on.
Tags:
title: amd and aliases date: 2005-04-12 06:19:05
Weird problem yesterday when moving a server: for some reason, amd
would not start up properly when it rebooted in its new location. Same
network setttings, same chunk of network, so wtf?
ps showed that its terminal was con -- console, I presume -- which
was doubly weird. I logged into another machine to make sure that was
abnormal, and yes it was. amq -f gave the error program not
registered, and sure enough rpcinfo -p showed the usual suspects
sans amd.
Well, the only thing different about this machine is that it's got
some jails running (which don't need to be running anymore, but I
hadn't had a chance to shut them down). That meant some additional
aliases for its outside interface in /etc/rc.conf on the subnet I
set aside for this sort of thing. I commented them out, rebooted, and
presto -- no more problems. Maybe something to do with picking which
interface to listen on?
Tags: