On Mon, Sep 29, 2008 at 12:21:42AM +0100, Pegasus Mc Cleaft wrote: > On Sunday 28 September 2008 23:37:09 Jeremy Chadwick wrote: > > <snip> > > > Yea.. The machine is otherwise running fine, and also loaded the driver > > > for the ata raid controller (I made the machine boot off a raid-1 pack > > > and made slices on the pack for /, /usr, /var . The rest zfs for > > > /usr/home) > > > > I don't know what filesystems you have assigned to what drives, but > > please be aware there are known major problems with Silicon Image > > controllers on FreeBSD, Linux, and Windows. The most common problem is > > silent data corruption. I can refer you to previous discussions of this > > problem if you'd like. If at all possible, disable this controller in > > the BIOS, and do not use it. > > I didnt know that, so thanks for telling me. As luck would have it, I > just > have the DVD-RW drive on the Silicon Image controller. I originally tried to > use the SI controller for the primary boot, but the driver support was not > there for it with the 7.0 boot disks, so I played with the cables and put the > two raid-1 drives on the JMicron controller. It was only after I got a 7.1 > kernel installed that it showed back up and I got use of the DVD-Rom drive.
This often happens when a change is made between two versions of FreeBSD but there's no available ISO which contains the drivers/changes which provide the hardware support you need. You might be interested in the snapshots/ directory on the FTP mirrors: ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/200809/ The allbsd.org site is also quite useful when you need something that's been added in the past few days/weeks, and not within the past month: http://pub.allbsd.org/FreeBSD-snapshots/ > > I see the system has an Intel AHCI-based controller (probably an ICH10 > > chip, since the ICH10 is the first to support 6 SATA channels). I would > > recommend using that for as much as you can (I see you have disks ad14 > > through ad24 off that controller). > > Its actually a ICH9R based motherboard by Gigabyte (GS-X48-DS5). Ahh, right. The ICH9R, ICH9DH, and ICH9DO contain 6 ports, while the ICH9 only provides 4 ports (confirmed in the data sheet). The ICH10 is the first to include 6 ports on the non-RAID version of the chip, that's why I made that assumption. > It seems to be a decent board, with the exception of, what I believe > to be a hardware fault with the watchdog timer. I think they have put > a pull-up resistor on the speaker line on the ICH9 that on release of > reset is hardware disabling the watchdog timer function. I have gone > round and round with them on this, but I can not adequately explain > the problem to there tech-support as there is a language barrier. One has to remember that Gigabyte is predominantly a "consumer" product vendor. Chances of getting through to an engineer are slim; Tier 1 support "shields" customers from engineers -- understandable (you don't want some irate customer wasting engineering's time on something that's simple), but it's also a problem because most T1 folks often lack the ability to make the judgement call as to when they should forward the request. Instead, the (false) conclusion they reach is "This is just some one-off, what a waste of time, /dev/null it". Supermicro is the one company I've had luck with, where their Tier 1 guys understand that certain topics should be forwarded directly to engineers, while other topics remain in T1s hands. > > > Thinking about it, I also added atapicd in the kernel config so I could > > > use things like K3B and xcdroast.. I dont know if maybe that shim might > > > be causing issues. I'll try making another kernel without it and giving > > > that a try. > > > > I highly doubt that's the problem. > > > > Can you please include your kernel configuration file here? > > > > Also, please do not copy/paste the file; I noticed in your dmesg|grep > > ata output, all of the lines had trailing spaces (I've stripped them > > off). > > Sure, I'll attach the config file and also a full dmesg. Forgive the > state of > the config file.. Its basically a copy of the GENERIC with a bunch of stuff > added at the end. > > > > I've CC'd [EMAIL PROTECTED] who maintains ata(4). I see no reason why > > "atacontrol list" would be returning such an error. > > Thank you... > > I'm not sure why I'm having the problem either. I just thought it was > strange > that it worked using the GENERIC kernel from 7.0-REL but once I built the > latest 7.1-PR it stopped working. My machine (feathers) is actually a sister > machine from one I built at work so I could test things out at home and then > make changes to the production machine. The other machine does not have the > SI > controller in it (everything else is the same) and it also will not do the > atacontrol list without erroring in the same way. 7.0-RELEASE to 7.1-PRERELEASE is pretty major in terms of changes; there's been a lot. I'd like to blame ata(4), but I don't know of any changes there (and I follow those closely) which might explain this phenomenon. I'm also CC'ing Andrey Elsukov <[EMAIL PROTECTED]> who has some experience dealing with ata(4) and AHCI. He might know of something that could cause this. I'm especially interested now that Bruce Cran reports the exact same problem on completely different hardware. (I myself can't reproduce it on a Supermicro PDSMi+ board running 7.1-PRERELEASE built September 24th). > I will hold my hands up and say that it could very well be something I > have > done in the config file by adding so much 'Stuff' to it.. There could be a > conflict there I dont know about.. Okay, so after reviewing your config file, the two pieces which could explain it (that differ from mine) are: 1) use of ATA_STATIC_ID, 2) use of atapicam I'm providing a link to your mail so that Andrey and others can read your kernel config and dmesg output if need be; I'm removing it as quoted material to keep the size of the mails down. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026153.html Also, an unrelated tip regarding SMBus, the only devices you'll need are: device smbus device smb device ichsmb The others are superfluous devices (won't apply to your board), unless you really plan on utilising some I2C hardware you have. -- | 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 | _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
