NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-alpha/40604: AlphaServer DS20E loses HDs and other Drives when adding 1 GB more RAM

The following reply was made to PR port-alpha/40604; it has been noted by GNATS.

From: Havard Eidnes <>
Subject: Re: port-alpha/40604: AlphaServer DS20E loses HDs and other Drives
 when adding 1 GB more RAM
Date: Wed, 11 Feb 2009 15:45:18 +0100 (CET)

 > Ok, that's one of the weirdest bugs I have ever faced.
 > I recently got a AlphaServer DS20E with 2 833 MHz CPUs, 5 Hard
 > Drives and 3 Power Sources. Nice server.
 > The machine came with 1 GB RAM, 4x256 MB DIMM boards placed in Bank 0=
 > I installed NetBSD 4.0.1 without any issues and immediately got
 > the 5 Hard Drives in a RAID configuration, with root and swap
 > under RAID1 and /usr under a RAID5. All working very nicely.
 > One day I received 8 more of that 256 MB memories, and hurried
 > to upgrade the server. I installed the boards in Banks 1 and 2.
 > What wasn't my surprise in the next boot, when I was faced with a mys=
 > -----
 > probe(esiop0:0:0:0): request sense for a request sense ?
 > probe(esiop0:0:0:0): request sense failed with error 22
 > probe(esiop0:0:0:0): generic HBA error
 > -----
 > and that 3 messages repeat for each of my other 4 Hard Drives.
 > and then everything closes with the misterious:
 > -----
 > WARNING: can't figure out what device matches "SCSI 1 7 0 0 0 0 0"
 > -----
 > That should be my boot and root device, dka0.
 I experienced some similar weirdness on an Alpha DP264 box I
 currently have in operation.  I think my conclusion was that this
 was due to some of the memory being bad.  You could try to see if
 this is the case by trying out the internal memory tester in the
 SRM firmware, or the more brute-force approach of trying to run
 the machine with only the new memory in bank 0, and see if it
 then behaves any better (or worse).
 However, your statement that it works fine with 2 or 3GB total
 memory (presumably the same memory tested above) with no issues
 while running Linux 2.6 makes this maybe implausible as an
 explanation.  Did you try to push the VM system while it ran
 Linux?  You could try pkgsrc/sysutils/memtester to excercise the
 system a bit, even though it's not a "real" memory tester (when
 you run it on a virtual memory system).  You may need to adjust
 the per-process memory limit up, and run sufficiently many
 instances to put strain on larger portions of your memory.
 Myself?  I yanked out 1GB, so my DP264 box now runs with 1GB
 memory.  Admittedly not ideal if this is indeed a bug in NetBSD,
 and not a hardware problem...
 - H=E5vard

Home | Main Index | Thread Index | Old Index