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]"

Reply via email to