am2 MBs - 4g + SCSI wipes out root partition

Jeremy Chadwick koitsu at FreeBSD.org
Mon Oct 13 07:24:51 PDT 2008


On Mon, Oct 13, 2008 at 04:10:31PM +0200, Fabian Wenk wrote:
> Hello João
>
> On 13.10.08 13:43, JoaoBR wrote:
>> On Sunday 12 October 2008 06:57:11 Gary Jennejohn wrote:
>>> On Sat, 11 Oct 2008 23:51:18 +0200
>>>
>>> Fabian Wenk <fabian at wenks.ch> wrote:
>
>>> > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM
>>> > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape
>>> > drive connected. The disks are on an Areca RAID controller. Access
>>> > to the disks and the tape drive does work just fine without any
>>> > crashes.
>>>
>>> This is interesting because the 29160 is exactly the controller with
>>> which I had all my problems, but I was running it with disks only.
>
>> I guess his MB is not an AM2 socket 
>
> Right, my system board is a Tyan Thunder i7520 (S5360) server board (with 
> only one Xeon single core CPU). The Adaptec SCSI is a PCI and the Areca 
> RAID a PCIe controller.
>
> I guess some more facts are needed to track this down. Does it make 
> troubles with more then one CPU core and also more then 3.5 GB RAM 
> running on FreeBSD/amd64?
>
> If yes, then I'm not surprised that only a few people see this behavior.
>
> I think the following informations would be needed to narrow down the 
> affected environment:
>
> - FreeBSD version 6.x, 7.x or 8-CURRENT and i368 or amd64
> - make and model of system board
> - make and model of SCSI controller and which driver
> - on board SCSI controller or PCI / PCI-X / PCIe
> - device types connected to the SCSI, eg. disk, tape
> - number of cpu cores
> - amount of memory

Two items which are missed (sort of implied though): motherboard BIOS
version, and SCSI card BIOS version.

Let's try to make an effort to get some hardware and software stats from
other folks so we can determine what the commonality in all of this is.
I can keep track of this stuff if need be.

We know for sure at this point that some of the reported systems
experiencing this problem work fine on Linux (all memory seen, and no
data corruption), so that "sort of" clears the hardware of being bad or
buggy.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list