Re: SiI3112 SATA controller problems - status

[Derek Ragona]

I tried the 11/29 snapshot, it is indeed worse.  I got a failure during the 
install's fsck.

The errors I got were:
ad4: Warning - WRITE_DMA recovered from missing interrupt
ad4: Failure - WRITE_DMA status=ff
followed by lots of:
ad4: timeout sending command=ca
ad4: error issuing DMA command
All along I have experienced "missing interrupt" errors, along with DMA 
write errors.

-Derek

At 02:01 PM 11/30/2003, Scott Long wrote:
Robert Watson wrote:
On Sun, 30 Nov 2003, Joe Marcus Clarke wrote:

On Fri, 2004-01-30 at 09:43, HaggeL wrote:

Hi Guys :)

Sorry if i waste your time. I®m a freeBSD noob and need some help.
I want to install freeBSD in januar and have some problems. I want to
buy me a new harddrive, a serial ATA one, because i got the "Silicon
ImageR Sil 3112A-Controller" onboard (Asus A7N8X Motherboard). I
didn®t find a driver in the Hardware Notes of FreeBSD 5.1, and on the
Producer homepage are only ready Linuxkernels avaible
(http://12.24.47.40/display/2n/searchDirect/?searchString=Sil+3112A&searchType=allwords&searchby=keywords&r=0.8157617).
So can anyone tell me if i can get a SATA disk run? I don®t want to
boot from it, just read and write. Buying a new disk only for windows
use is wasted money
We're having a pretty lengthy discussion about these controllers on this
list right now.  I suggest you read the archives.  Bottom line, the
controller is supported, but it's problematic.  The ATA maintainer has
working controllers, but there are those of us that experience data
corruption, and at least one user that can't use his drive at all when
connected to said controller.
I believe a workaround was recently committed to improve behavior on older
cards using that chipset.  Specifically the following change to
ata-chipset.c:
revision 1.48
date: 2003/11/28 19:01:28;  author: sos;  state: Exp;  lines: +6 -2
Workaround for errata on early versions of the sii3112.
Approved by: re@
Does this make any difference in your configuration?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research
This commit only fixes a silent data corruption issue.  I believe that
the issue at hand involves DMA not working at all.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Western Digital WD360GD SATA disk on -CURRENT

[Derek Ragona]

I have a server that uses the same chipset with a maxtor drive, no RAID 
just a single drive.  My hardware exact hardware is:
Adaptec SATA 1210SA (SiI 3112 SATA150 controller in non RAID mode with a 
single drive) and a Maxtor 6Y120M0 120 GB drive

It is probed correctly with the ISO mini 5.2 beta, but it was still having 
data problems with larger IO in multiuser.  The error I get is:

ad4: timeout sending command=ca
ad4: error issuing DMA command
I will try the 11/29 snapshot and see if that is any better.

-Derek

At 10:56 PM 11/29/2003, Will Andrews wrote:
Hi,

Ever since I found the set of commits which broke probing this
disk on/about September 1, I have attempted to boot a JPSNAP
about once a week.  Up to this day, on which I tried 5.2-BETA
(official ISO), it has never again probed this drive correctly.
I'm using it with a:

[EMAIL PROTECTED]:6:0:   class=0x018000 card=0x31121095 chip=0x31121095 
rev=0x02 hdr=0x00
vendor   = 'Silicon Image Inc (Was: CMD Technology Inc)'
device   = 'SiI 3112 SATARaid Controller'
class= mass storage

(note, no RAID has been configured, only one disk is attached)

Has anyone had better luck?  Thanks.

Regards,
--
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Update to 5.2 beta from 5.1-current didn't work right

[Derek Ragona]

After doing:
make buildworld
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot
mergemaster -p
make installworld
mergemaster
reboot
The system booted multiuser correctly and appears to be operating correctly.

-Derek

At 07:05 AM 11/27/2003, Derek Ragona wrote:
An update to my previous note:

At the tail end of the cvsup, src had already been completed, the system 
had a drive problem.   It kept cycling through these messages on the console:
ad4: timeout sending command=ca
ad4: error issuing DMA command
initiate_write_filepage: already started

In this state I couldn't get the system to respond, and had to reboot it.

Also when the drive system was tied up, it somehow effects the ethernet, 
as it brings down the LAN the server is on.

Upon reboot, I did:
make kernel
rebooted, but even with the new kernel the system won't boot into 
multiuser, behaving the same as it did on the originally installed 5.2 
beta kernel.

I am in the process of doing:
make buildworld
if this build succeeds, hopefully the installation of this will correct 
the multiuser boot problem.

-Derek

At 08:47 PM 11/26/2003, Derek Ragona wrote:
I did a binary update from 5.1-current, created with a mid October 
snapshot, to 5.2 beta.  The installer had trouble, at one point reporting 
negative disk space available when of course there is plenty of 
space.  This server has a single SATA drive with three slices for 
FreeBSD, a 5 GB /, and 42 GB /usr, along with swap.  I had to do a binary 
update as this is a system that has been problematic with the ATA 
subsystem due to the combination of the Adaptec SATA 1210SA (in non RAID 
mode with a single drive) and a Maxtor 6Y120M0 120 GB drive.

The system acts as if some of the older pre 64 bit filesystem code in 
still present the beta boot/kernel.  I did boot from the mini-iso CD-ROM.

Once the installer finished, I rebooted.  The server claims to be a 5.2 
beta kernel, but perhaps as a side effect of the new dynamic linking must 
have some old pre-64-bit filesystem code it is still using.

===
$ uname -a
FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue 
Nov 25 08:24:08 GMT 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
===

As a result, on reboot, df core dumped as did fsck and mount.  The static 
mount in /rescue did work though.

As these problems look like what is in UPDATING:
===
20031112:
The statfs structure has been updated with 64-bit fields to
allow accurate reporting of multi-terabyte filesystem
sizes. You should build world, then build and boot the new kernel
BEFORE doing a `installworld' as the new kernel will know about
binaries using the old statfs structure, but an old kernel will
not know about the new system calls that support the new statfs
structure.
Note that the backwards compatibility is only present when the
kernel is configured with the COMPAT_FREEBSD4 option. Since
even /bin/sh will not run with a new kernel without said option
you're pretty much dead in the water without it. Make sure you
have COMPAT_FREEBSD4!
Running an old kernel after a `make world' will cause programs
such as `df' that do a statfs system call to fail with a bad
system call. Marco Wertejuk <[EMAIL PROTECTED]> also reports
that cfsd (ports/security/cfs) needs to be recompiled after
these changes are installed.
===
I will cvsup to current then build and install a new kernel, then build 
and install world per UPDATING.

If anyone wants more information, let me know.  Below is the verbose dmesg.

-Derek

verbose dmesg:

Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel
Nov 26 19:02:28 barney kernel: 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10B   0x6a  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10C   0x6b  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10D   0x68  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11A   0x6a  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11B   0x69  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11C   0x68  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11D   0x6b  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12A   0x62  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12B   0x63  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12C   0x61  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12D   0x60  3 4 5 6 7 
9 10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  1

Re: Update to 5.2 beta from 5.1-current didn't work right

[Derek Ragona]

An update to my previous note:

At the tail end of the cvsup, src had already been completed, the system 
had a drive problem.   It kept cycling through these messages on the console:
ad4: timeout sending command=ca
ad4: error issuing DMA command
initiate_write_filepage: already started

In this state I couldn't get the system to respond, and had to reboot it.

Also when the drive system was tied up, it somehow effects the ethernet, as 
it brings down the LAN the server is on.

Upon reboot, I did:
make kernel
rebooted, but even with the new kernel the system won't boot into 
multiuser, behaving the same as it did on the originally installed 5.2 beta 
kernel.

I am in the process of doing:
make buildworld
if this build succeeds, hopefully the installation of this will correct the 
multiuser boot problem.

-Derek

At 08:47 PM 11/26/2003, Derek Ragona wrote:
I did a binary update from 5.1-current, created with a mid October 
snapshot, to 5.2 beta.  The installer had trouble, at one point reporting 
negative disk space available when of course there is plenty of 
space.  This server has a single SATA drive with three slices for FreeBSD, 
a 5 GB /, and 42 GB /usr, along with swap.  I had to do a binary update as 
this is a system that has been problematic with the ATA subsystem due to 
the combination of the Adaptec SATA 1210SA (in non RAID mode with a single 
drive) and a Maxtor 6Y120M0 120 GB drive.

The system acts as if some of the older pre 64 bit filesystem code in 
still present the beta boot/kernel.  I did boot from the mini-iso CD-ROM.

Once the installer finished, I rebooted.  The server claims to be a 5.2 
beta kernel, but perhaps as a side effect of the new dynamic linking must 
have some old pre-64-bit filesystem code it is still using.

===
$ uname -a
FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue 
Nov 25 08:24:08 GMT 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
===

As a result, on reboot, df core dumped as did fsck and mount.  The static 
mount in /rescue did work though.

As these problems look like what is in UPDATING:
===
20031112:
The statfs structure has been updated with 64-bit fields to
allow accurate reporting of multi-terabyte filesystem
sizes. You should build world, then build and boot the new kernel
BEFORE doing a `installworld' as the new kernel will know about
binaries using the old statfs structure, but an old kernel will
not know about the new system calls that support the new statfs
structure.
Note that the backwards compatibility is only present when the
kernel is configured with the COMPAT_FREEBSD4 option. Since
even /bin/sh will not run with a new kernel without said option
you're pretty much dead in the water without it. Make sure you
have COMPAT_FREEBSD4!
Running an old kernel after a `make world' will cause programs
such as `df' that do a statfs system call to fail with a bad
system call. Marco Wertejuk <[EMAIL PROTECTED]> also reports
that cfsd (ports/security/cfs) needs to be recompiled after
these changes are installed.
===
I will cvsup to current then build and install a new kernel, then build 
and install world per UPDATING.

If anyone wants more information, let me know.  Below is the verbose dmesg.

-Derek

verbose dmesg:

Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel
Nov 26 19:02:28 barney kernel: 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10B   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10C   0x6b  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10D   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11A   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11B   0x69  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11C   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11D   0x6b  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12A   0x62  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12B   0x63  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12C   0x61  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12D   0x60  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13A   0x63  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13B   0x62  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13C   0x69  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13D   0x6a  3 4 5 6

Update to 5.2 beta from 5.1-current didn't work right

[Derek Ragona]

I did a binary update from 5.1-current, created with a mid October 
snapshot, to 5.2 beta.  The installer had trouble, at one point reporting 
negative disk space available when of course there is plenty of 
space.  This server has a single SATA drive with three slices for FreeBSD, 
a 5 GB /, and 42 GB /usr, along with swap.  I had to do a binary update as 
this is a system that has been problematic with the ATA subsystem due to 
the combination of the Adaptec SATA 1210SA (in non RAID mode with a single 
drive) and a Maxtor 6Y120M0 120 GB drive.

The system acts as if some of the older pre 64 bit filesystem code in still 
present the beta boot/kernel.  I did boot from the mini-iso CD-ROM.

Once the installer finished, I rebooted.  The server claims to be a 5.2 
beta kernel, but perhaps as a side effect of the new dynamic linking must 
have some old pre-64-bit filesystem code it is still using.

===
$ uname -a
FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue 
Nov 25 08:24:08 GMT 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
===

As a result, on reboot, df core dumped as did fsck and mount.  The static 
mount in /rescue did work though.

As these problems look like what is in UPDATING:
===
20031112:
The statfs structure has been updated with 64-bit fields to
allow accurate reporting of multi-terabyte filesystem
sizes. You should build world, then build and boot the new kernel
BEFORE doing a `installworld' as the new kernel will know about
binaries using the old statfs structure, but an old kernel will
not know about the new system calls that support the new statfs
structure.
Note that the backwards compatibility is only present when the
kernel is configured with the COMPAT_FREEBSD4 option. Since
even /bin/sh will not run with a new kernel without said option
you're pretty much dead in the water without it. Make sure you
have COMPAT_FREEBSD4!
Running an old kernel after a `make world' will cause programs
such as `df' that do a statfs system call to fail with a bad
system call. Marco Wertejuk <[EMAIL PROTECTED]> also reports
that cfsd (ports/security/cfs) needs to be recompiled after
these changes are installed.
===
I will cvsup to current then build and install a new kernel, then build and 
install world per UPDATING.

If anyone wants more information, let me know.  Below is the verbose dmesg.

	-Derek

verbose dmesg:

Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel
Nov 26 19:02:28 barney kernel: 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10B   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10C   0x6b  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 1  10D   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11A   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11B   0x69  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11C   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 2  11D   0x6b  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12A   0x62  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12B   0x63  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12C   0x61  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 3  12D   0x60  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13A   0x63  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13B   0x62  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13C   0x69  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 4  13D   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 5  14A   0x61  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 5  14B   0x6b  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 5  14C   0x60  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 5  14D   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 6  15A   0x62  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 6  15B   0x68  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 6  15C   0x6a  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: slot 6  15D   0x69  3 4 5 6 7 9 
10 11 12 14 15
Nov 26 19:02:28 barney kernel: AcpiOsDerivePciId: bus 0 dev 31 func 0
Nov 26 19:02:28 barney kernel: acpi0: Power Button (fixed)
Nov 26 19:02:28 barney kernel: ACPI timer loo

Re: SiI3112 SATA controller problems - status

[Derek Ragona]

Søren,

The SATA seems better, but is still not working.  I tried the Oct 5 
snapshot, doing a clean install.  I CVSup'd and did
make buildworld
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot to single user
mount -a
swapon -a
mergemaster -p
make installworld

System has the same DMA write problems.  In this recent case it was 
installing termcap.  I tried the Oct 1 snapshot and it was the same, it 
errored in installworld installing tar.

The SATA is stabler as I can buildworld, but not stable enough to handle 
the installworld copies.

Here is what I copied from the console after it went into the debugger:
spec_getpages I/O Read failure(error=5)
vm_fault: pager read error
panic: initiate_write_inodeblock_ufs2: already started
Let me know if you want more information.  I will have to reinstall to get 
a dmesg, if you want a new one.

-Derek

At 04:09 PM 9/30/2003 -0500, Derek Ragona wrote:
Great news to hear Søren.

Do you know when a snapshot with the fix will be available?  Since I 
cannot complete a buildworld using the SATA drive without the fix.

Thanks for the fix.

-Derek

At 10:06 PM 9/30/2003 +0200, Soren Schmidt wrote:

I have now found a way to reproduce the DMA problems some setups seems
to be having with the SiI3112A SATA chip.
Now, if I use real SATA drives, (and I mean real SATA drives, the
WD Raptor fx is not a real SATA device but just a PATA device
with a build in PATA->SATA converter chip) it works just fine
no matter what I try.
If however I use an older PATA drive and a certain PATA->SATA "dongle"
(in this case 1 out of 4 samples) I can reproduce the problem pretty
easily.
This suggests to me that we are looking at a timing problem of sorts
the question is where.
I'll work on the problem as time permits...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ad0: WARNING - WRITE_DMA recovered from missing interrupt

[Derek Ragona]

What type of drive is in your dell?  I get this same error with an SATA 
drive and adapter.

-Derek

At 07:22 PM 10/11/2003 +0200, C. Kukulies wrote:
ad0: WARNING - WRITE_DMA recovered from missing interrupt
Got this on my Dell Inspiron 8000 while dhclient was running
interactively and wi0: busy bit won't clear was happening.
At the moment with a recently cvsuped -current wi0 on my
gateway (PCI-PCMCIA adapter card) seems to be broken as well as this
everlasting wi0: busy bit won't clear thing which breaks
WLAN on my Dell Inspiron for weeks now.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cannot create partition entries for /dev/ad3

[Derek Ragona]

If you read the early adopters doc at:

http://www.freebsd.org/releases/5.1R/early-adopter.html

You will se it clearly says:
"MAKEDEV is no longer available, nor is it required. FreeBSD 5.X uses a 
device filesystem, which automatically creates device nodes on demand. For 
more information, please see 
devfs(5)."

Any new version of an OS, particularly a free one, as FreeBSD is, will have 
issues.  Particularly with the recent rapidity of new hardware, SATA 
drives, SATA card, RAID cards, etc.

There are places to "purchase" copies of FreeBSD other than CompUSA where 
you can get 4.X or 5.X versions.  Or you can download and burn your own 
CD's.  You sound upset that you bought FreeBSD, if you are be upset perhaps 
you should be with CompUSA who made the money off the sale.

-Derek

At 04:05 AM 10/8/2003 -0700, ecsd wrote:
Given that FreeBSD 5.1 is on the shelf in a box at CompUSA for sale to the
general public, I think the proper thing to do is address the matter of
documenting the revised operation of the devices in 5.X, rather than tell
people to downgrade if they don't understand the behavior of their system,
besides which FreeBSD 4.8 or 4.9 are not for sale at CompUSA as a consolation.
I did ask to know what documentation there is for the new behavior, but I have
not heard any replies. If there isn't any documentation, that's an answer too.
-ecsd

Poul-Henning Kamp writes:
In message <[EMAIL PROTECTED]>, ecsd writes:
MAKEDEV was the cheese since year zero. [...]
I suggest you stick with 4-stable until you have caught up with
the changes and the documentation.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SiI3112 SATA controller problems - status

[Derek Ragona]

Søren,

The SATA seems better, but is still not working.  I tried the Oct 5 
snapshot, doing a clean install.  I CVSup'd and did
make buildworld
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot to single user
mount -a
swapon -a
mergemaster -p
make installworld

System has the same DMA write problems.  In this recent case it was 
installing termcap.  I tried the Oct 1 snapshot and it was the same, it 
errored in installworld installing tar.

The SATA is stabler as I can buildworld, but not stable enough to handle 
the installworld copies.

Here is what I copied from the console after it went into the debugger:
spec_getpages I/O Read failure(error=5)
vm_fault: pager read error
panic: initiate_write_inodeblock_ufs2: already started
Let me know if you want more information.  I will have to reinstall to get 
a dmesg, if you want a new one.

-Derek

At 04:09 PM 9/30/2003 -0500, Derek Ragona wrote:
Great news to hear Søren.

Do you know when a snapshot with the fix will be available?  Since I 
cannot complete a buildworld using the SATA drive without the fix.

Thanks for the fix.

-Derek

At 10:06 PM 9/30/2003 +0200, Soren Schmidt wrote:

I have now found a way to reproduce the DMA problems some setups seems
to be having with the SiI3112A SATA chip.
Now, if I use real SATA drives, (and I mean real SATA drives, the
WD Raptor fx is not a real SATA device but just a PATA device
with a build in PATA->SATA converter chip) it works just fine
no matter what I try.
If however I use an older PATA drive and a certain PATA->SATA "dongle"
(in this case 1 out of 4 samples) I can reproduce the problem pretty
easily.
This suggests to me that we are looking at a timing problem of sorts
the question is where.
I'll work on the problem as time permits...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SiI3112 SATA controller problems - status

[Derek Ragona]

Great news to hear Søren.

Do you know when a snapshot with the fix will be available?  Since I cannot 
complete a buildworld using the SATA drive without the fix.

Thanks for the fix.

-Derek

At 10:06 PM 9/30/2003 +0200, Soren Schmidt wrote:

I have now found a way to reproduce the DMA problems some setups seems
to be having with the SiI3112A SATA chip.
Now, if I use real SATA drives, (and I mean real SATA drives, the
WD Raptor fx is not a real SATA device but just a PATA device
with a build in PATA->SATA converter chip) it works just fine
no matter what I try.
If however I use an older PATA drive and a certain PATA->SATA "dongle"
(in this case 1 out of 4 samples) I can reproduce the problem pretty
easily.
This suggests to me that we are looking at a timing problem of sorts
the question is where.
I'll work on the problem as time permits...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SiL3112 SATA (RAID) Controller drives aren't working at all.

[Derek Ragona]

My troublesome system uses an Adaptec Serial ATA RAID 1210SA which has the 
SiI3112 RAID chip.  I have only one drive connected, so no RAID functionality.

Here is my verbose dmesg using the 9/28/03 snapshot:
http://www.computinginnovations.com/dmesg.html
-Derek



At 12:38 PM 9/29/2003 -0700, Will Andrews wrote:
On Mon, Sep 29, 2003 at 09:13:48PM +0200, Soren Schmidt wrote:
> First off, there is ONLY support for Promise and HPT "soft RAID"
> in the ATA driver, other vendors products are *not* supported (yet).
>
> Second, there seem to be a problem with some sil3112 setups where
> timeouts and what not ruins the lunch, but so far I've not been
> able to reproduce..
I am still unable to use my SATA drive, it's probed incorrectly
as I posted earlier.  Reverting to the August 10th 00:00 UTC
kernel fixes this problem, so I concluded that ATAng broke this.
If it makes any difference, my model is a SiI3112 RAID
controller, but I only have one drive and it probes as ad4... the
situation doesn't improve any if I add "ataraid".  But maybe
ATAng doesn't take into account the difference between a "normal"
and a "RAID" SiI 3112, if any?
Here are my dmesg's again (Sep 18th, Aug 10th kernels):
http://csociety.org/~will/dmesg.badATAng
http://csociety.org/~will/dmesg.Aug10.preATAng
The problem shown in the first dmesg still showed itself when I
tried a new kernel on Sep 25th.
Regards,
--
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Something is wrong with the fxp network driver

[Derek Ragona]

Revised output from pciconf -v -l

[EMAIL PROTECTED]:8:0:  class=0x02 card=0x34278086 chip=0x10508086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82562EZ Pro 10/100 Mb/s VE Fast Ethernet MAC & PHY'
class= network
subclass = ethernet

-Derek

At 10:40 PM 9/27/2003 -0500, Derek Ragona wrote:
pciconf -v -l output is:

# pciconf -v -l
[EMAIL PROTECTED]:0:0:  class=0x06 card=0x25788086 chip=0x25788086 rev=0x02 
hdr=0x00
vendor   = 'Intel Corporation'
class= bridge
subclass = HOST-PCI
[EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x25798086 rev=0x02 
hdr=0x01
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:3:0: class=0x060400 card=0x chip=0x257b8086 rev=0x02 
hdr=0x01
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x34278086 chip=0x24d28086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x34278086 chip=0x24d48086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x34278086 chip=0x24d78086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:3:class=0x0c0300 card=0x34278086 chip=0x24de8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x34278086 chip=0x24dd8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 
rev=0xc2 hdr=0x01
vendor   = 'Intel Corporation'
device   = '82801BA/CA/DB (ICH2/3/4) Hub Interface to PCI Bridge (244E)'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24d08086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-ISA
[EMAIL PROTECTED]:31:1:  class=0x01018a card=0x34278086 chip=0x24db8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:31:2:  class=0x01018f card=0x34278086 chip=0x24d18086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:31:3:class=0x0c0500 card=0x34278086 chip=0x24d38086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = SMBus
[EMAIL PROTECTED]:1:0:   class=0x02 card=0x34278086 chip=0x10198086 rev=0x00 
hdr=0x00
vendor   = 'Intel Corporation'
class= network
subclass = ethernet
[EMAIL PROTECTED]:6:0: class=0x03 card=0x34278086 chip=0x47521002 rev=0x27 
hdr=0x00
vendor   = 'ATI Technologies'
device   = 'Rage XL PCI'
class= display
subclass = VGA
[EMAIL PROTECTED]:7:0:   class=0x010400 card=0x34278086 chip=0x3319105a 
rev=0x02 hdr=0x00
vendor   = 'Promise Technology Inc'
device   = 'PDC20319? FastTrak SATA150 TX4 Controller'
class= mass storage
subclass = RAID
[EMAIL PROTECTED]:8:0:  class=0x02 card=0x34278086 chip=0x10508086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
class= network
subclass = ethernet

ifconfig fxp0 is:

fxp0: flags=8843 mtu 1500
inet6 fe80::207:e9ff:fe39:d437%fxp0 prefixlen 64 scopeid 0x2
ether 00:07:e9:39:d4:37
media: Ethernet autoselect (100baseTX )
status: active
-Derek

At 04:17 PM 9/27/2003 -0500, Glenn Johnson wrote:
On Sat, Sep 27, 2003 at 12:12:40AM -0400, Mike Tancsa wrote:

> At 11:32 PM 26/09/2003, Glenn Johnson wrote:
>
> >On Fri, Sep 26, 2003 at 08:07:38PM -0400, Mike Tancsa wrote:
> >
> >> Are they Tyan motherboards by chance ? There was a thread in stable
> >> about this a few weeks ago.  The problems seem specific to those
> >> motherboards.  Someone posted a potential workaround as well.
> >
> >No, five of them are MSI dual Athlon-MP boards (can not remember the
>
>
> what does pciconf -v -l show for the cards ?
I will not be able to answer that until Monday.

> Are all on the same
> switch ?
Yes, they are all on the same switch. Other machines with an xl
interface are fine though.
> Is it a flow control issue perhaps ?

I am not sure what you mean?

--
Glenn Johnson
___
[EMAIL PROTECTED] mailing list

Re: Something is wrong with the fxp network driver

[Derek Ragona]

pciconf -v -l output is:

# pciconf -v -l
[EMAIL PROTECTED]:0:0:  class=0x06 card=0x25788086 chip=0x25788086 rev=0x02 
hdr=0x00
vendor   = 'Intel Corporation'
class= bridge
subclass = HOST-PCI
[EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x25798086 rev=0x02 
hdr=0x01
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:3:0: class=0x060400 card=0x chip=0x257b8086 rev=0x02 
hdr=0x01
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x34278086 chip=0x24d28086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x34278086 chip=0x24d48086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x34278086 chip=0x24d78086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:3:class=0x0c0300 card=0x34278086 chip=0x24de8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x34278086 chip=0x24dd8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 
rev=0xc2 hdr=0x01
vendor   = 'Intel Corporation'
device   = '82801BA/CA/DB (ICH2/3/4) Hub Interface to PCI Bridge (244E)'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24d08086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= bridge
subclass = PCI-ISA
[EMAIL PROTECTED]:31:1:  class=0x01018a card=0x34278086 chip=0x24db8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:31:2:  class=0x01018f card=0x34278086 chip=0x24d18086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:31:3:class=0x0c0500 card=0x34278086 chip=0x24d38086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
class= serial bus
subclass = SMBus
[EMAIL PROTECTED]:1:0:   class=0x02 card=0x34278086 chip=0x10198086 rev=0x00 
hdr=0x00
vendor   = 'Intel Corporation'
class= network
subclass = ethernet
[EMAIL PROTECTED]:6:0: class=0x03 card=0x34278086 chip=0x47521002 rev=0x27 
hdr=0x00
vendor   = 'ATI Technologies'
device   = 'Rage XL PCI'
class= display
subclass = VGA
[EMAIL PROTECTED]:7:0:   class=0x010400 card=0x34278086 chip=0x3319105a 
rev=0x02 hdr=0x00
vendor   = 'Promise Technology Inc'
device   = 'PDC20319? FastTrak SATA150 TX4 Controller'
class= mass storage
subclass = RAID
[EMAIL PROTECTED]:8:0:  class=0x02 card=0x34278086 chip=0x10508086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
class= network
subclass = ethernet

ifconfig fxp0 is:

fxp0: flags=8843 mtu 1500
inet6 fe80::207:e9ff:fe39:d437%fxp0 prefixlen 64 scopeid 0x2
ether 00:07:e9:39:d4:37
media: Ethernet autoselect (100baseTX )
status: active
-Derek

At 04:17 PM 9/27/2003 -0500, Glenn Johnson wrote:
On Sat, Sep 27, 2003 at 12:12:40AM -0400, Mike Tancsa wrote:

> At 11:32 PM 26/09/2003, Glenn Johnson wrote:
>
> >On Fri, Sep 26, 2003 at 08:07:38PM -0400, Mike Tancsa wrote:
> >
> >> Are they Tyan motherboards by chance ? There was a thread in stable
> >> about this a few weeks ago.  The problems seem specific to those
> >> motherboards.  Someone posted a potential workaround as well.
> >
> >No, five of them are MSI dual Athlon-MP boards (can not remember the
>
>
> what does pciconf -v -l show for the cards ?
I will not be able to answer that until Monday.

> Are all on the same
> switch ?
Yes, they are all on the same switch. Other machines with an xl
interface are fine though.
> Is it a flow control issue perhaps ?

I am not sure what you mean?

--
Glenn Johnson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Sil680 RAID Support while installing 5.1-Release

[Derek Ragona]

Gabriel,

I experienced the same problem using 5.1 release with an Adaptec SATA Raid 
card that uses the SATA Sil3112A chip.

With 5.1-CURRENT I can get FreeBSD to install, but the server locks-up 
because the disk subsystem gets a DMA write error that it either never 
recovers from or falls into the debugger (most times it does NOT go to the 
debugger.)

There are a few of us using SATA Sil3112A chips and experiencing these 
problems.

-Derek

At 06:13 PM 9/27/2003 +0200, Gabriel Ambuehl wrote:
Hi Travis Troyer,
you wrote.
TT> I just purchased a Sil680 IDE RAID controller, and have setup
TT> a striped RAID array.  When I boot from the 5.1 installation
TT> CD-ROM, FreeBSD does not recognize them as one disk.  I
TT> checked the hardware notes, and "Sil680 UDMA6" is listed.
TT> Seeing Sil680 listed, I assumed that the RAID capabilities
TT> would also be supported.  I read something posted awhile back
TT> referring to the Sil680 controller, saying it was supported,
TT> but dangerous unless using 5.1-Current.  Does anybody know
TT> anything about the current status of this?  Is there anyway to
TT> get the FreeBSD installation to recognize my RAID array, or
TT> should I just buy another controller?
I was wondering about the online Sil 3112 SATA RAID controller on my
Gigabyte 7VAXP board. The 5.1 RELEASE boot CD crashes saying it
couldn't write to root (which is weird, considering it usually should
be able to write to memfs??).


Regards,
Gabriel
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Something is wrong with the fxp network driver

[Derek Ragona]

This worked until I went beyond p4 on 5.1 release

I found a PR that suggested adding:
 { 0x1050,  "Intel 82801EB (ICH5) Pro/100 Ethernet" },
line to the if_fxp.c file, in the struct:
/*
 * Claim various Intel PCI device identifiers for this driver.  The
 * sub-vendor and sub-device field are extensively used to identify
 * particular variants, but we don't currently differentiate between
 * them.
 */
 static struct fxp_ident fxp_ident_table[] = {
{ 0x1029,   "Intel 82559 PCI/CardBus Pro/100" },
{ 0x1030,   "Intel 82559 Pro/100 Ethernet" },
{ 0x1031,   "Intel 82801CAM (ICH3) Pro/100 VE Ethernet" },
{ 0x1032,   "Intel 82801CAM (ICH3) Pro/100 VE Ethernet" },
{ 0x1033,   "Intel 82801CAM (ICH3) Pro/100 VM Ethernet" },
{ 0x1034,   "Intel 82801CAM (ICH3) Pro/100 VM Ethernet" },
{ 0x1035,   "Intel 82801CAM (ICH3) Pro/100 Ethernet" },
{ 0x1036,   "Intel 82801CAM (ICH3) Pro/100 Ethernet" },
{ 0x1037,   "Intel 82801CAM (ICH3) Pro/100 Ethernet" },
{ 0x1038,   "Intel 82801CAM (ICH3) Pro/100 VM Ethernet" },
{ 0x1039,   "Intel 82801DB (ICH4) Pro/100 VE Ethernet" },
{ 0x103A,   "Intel 82801DB (ICH4) Pro/100 Ethernet" },
{ 0x103B,   "Intel 82801DB (ICH4) Pro/100 VM Ethernet" },
{ 0x103C,   "Intel 82801DB (ICH4) Pro/100 Ethernet" },
{ 0x103D,   "Intel 82801DB (ICH4) Pro/100 VE Ethernet" },
{ 0x103E,   "Intel 82801DB (ICH4) Pro/100 VM Ethernet" },
{ 0x1050,  "Intel 82801EB (ICH5) Pro/100 Ethernet" },
{ 0x1059,   "Intel 82551QM Pro/100 M Mobile Connection" },
{ 0x1209,   "Intel 82559ER Embedded 10/100 Ethernet" },
{ 0x1229,   "Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet" },
{ 0x2449,   "Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet" },
{ 0,NULL },
 };
-Derek

At 07:15 PM 9/26/2003 -0500, Derek Ragona wrote:
Mine is an Intel® Server Board S875WP1-E, I was using a patch but it quite 
working on the fxp0 interface.

-Derek

At 08:07 PM 9/26/2003 -0400, Mike Tancsa wrote:

Are they Tyan motherboards by chance ? There was a thread in stable
about this a few weeks ago.  The problems seem specific to those
motherboards.  Someone posted a potential workaround as well.
---Mike

On Fri, 26 Sep 2003 11:40:08 -0500, in sentex.lists.freebsd.current
you wrote:
>I am having a problem with recent builds of -current with the fxp
>driver.  A couple of days ago, the 6 machines in my cluster with fxp
>interfaces all died at about the same time with fxp timeout errors.  The
>machines with 3Com xl interfaces kept on going. Today, I am observing
>that the throughput is about half of what I am seeing on my machines
>with a 3Com xl interface.  Is anybody else observing this?  What other
>information do I need to provide?
>
>Thanks.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Something is wrong with the fxp network driver

[Derek Ragona]

Mine is an Intel® Server Board S875WP1-E, I was using a patch but it quite 
working on the fxp0 interface.

-Derek

At 08:07 PM 9/26/2003 -0400, Mike Tancsa wrote:

Are they Tyan motherboards by chance ? There was a thread in stable
about this a few weeks ago.  The problems seem specific to those
motherboards.  Someone posted a potential workaround as well.
---Mike

On Fri, 26 Sep 2003 11:40:08 -0500, in sentex.lists.freebsd.current
you wrote:
>I am having a problem with recent builds of -current with the fxp
>driver.  A couple of days ago, the 6 machines in my cluster with fxp
>interfaces all died at about the same time with fxp timeout errors.  The
>machines with 3Com xl interfaces kept on going. Today, I am observing
>that the throughput is about half of what I am seeing on my machines
>with a 3Com xl interface.  Is anybody else observing this?  What other
>information do I need to provide?
>
>Thanks.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.1 p7 to 5.1 p8 compile problems

[Derek Ragona]

I am trying to update a server from RELENG_5_1 p7 to RELENG_5_1 p8 for the 
last security advisory.  I had no problem building the p7.

I cvsup'd but the compile breaks.  I tried other mirrors, and even 
completely repopulated /usr/src.  But it still breaks.  The latest 
breakdown is:



building static objc library
ranlib libobjc.a
===> gnu/lib/libg2c
cc -O -pipe -march=pentiumpro -DHAVE_CONFIG_H=1 -DSTDC_HEADERS=1 
-DHAVE_TEMPNAM=1 -DNO_EOF_CHAR_CHECK=1 -DRETSIGTYPE=void 
-DSkip_f2c_Undefs=1 -DIEEE_drem=1 -DAllow_TYQUAD -DPedantic 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libF77 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libI77 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libU77 
-I/usr/src/gnu/lib/libg2c  -c -DLabort -o abort.o 
/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/f2cext.c
cc -O -pipe -march=pentiumpro -DHAVE_CONFIG_H=1 -DSTDC_HEADERS=1 
-DHAVE_TEMPNAM=1 -DNO_EOF_CHAR_CHECK=1 -DRETSIGTYPE=void 
-DSkip_f2c_Undefs=1 -DIEEE_drem=1 -DAllow_TYQUAD -DPedantic 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libF77 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libI77 
-I/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/libU77 
-I/usr/src/gnu/lib/libg2c  -c -DLaccess -o access.o 
/usr/src/gnu/lib/libg2c/../../../contrib/libf2c/f2cext.c
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/src/gnu/lib.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in 
/usr/src.===
Any ideas on how to fix this?



-Derek
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

Søren,

My setup is as follows:
Maxtor 6Y120MO 120GB SATA drive
Adaptec Serial ATA RAID 1210SA
Intel® Desktop Board D845GEBV2
1GB RAM
1.7 GHz Celeron CPU
The motherboard has the latest P17 BIOS.

The system has a teac 52x CD-ROM as the Master ATA device on the 
motherboards primary IDE controller.  The secondary IDE controller is 
disabled (I disabled this to reduce conflicts.)

The Maxtor drive is on the only drive connected to the adaptec SATA card.

There is a standard floppy disk installed as well.

I loaded the 9/22 snapshot, and after a couple drives was able to cvsup and 
rebuild to current.  I am running the GENERIC kernel.

If there is some way to get more debugging information, please let me 
know.  If you want the ATA subsystem rebuilt differently for more 
debugging, I'm happy to do that as well.  If you want access to the box, I 
will give you that too.

-Derek

At 05:51 PM 9/23/2003 +0200, Soren Schmidt wrote:
It seems Putinas wrote:
> Hi all,
> Inspired with all the FreeBSD is free software , windows and buggy hardware
> and blabla I realize what maybe I could do more to help solve this problem.
> I made small research on my computer and I find out what till the cvsup 
date
> 2003.08.24.00.00.00 till ATAng commitment to the source my SATA Sil3112A
> working fine.
> After this date I always get WRITE_DMA recovered from missing interrupt
> error
> after more or less intensive input output with harddisk subsystem , and
> after I/O error and so on ...
> My bet is what in this case buggy is not hardware .. at least this bug
> didn't
> show up until 25 August

Well, it works here with pure SATA drives at least, do you use real
SATA disks on PATA ones with SATA dongles ?
So long that I cant reproduce the problem its hard to fix...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

I don't want to get into some flame war here.  I am trying to provide what 
information I can.  If Soren, or anyone else wants more debugging 
information I will be happy to do what I can to provide that 
information.  I simply need them to tell me what and how to capture the 
information.  As the system locks up, there is little ability at present to 
get any information beyond what is on the console.

I offered some additional information as Soren had suggested I was having a 
hardware problem, which I am not.  Again this is all new hardware, all 
shows no issues with  diagnostic tests.

As the Adaptec board I am using is based on Sil3112A controller, and I have 
heard from another user experiencing the same issue, I am simply trying to 
keep the information on this issue up to date.

A couple weeks ago the OS wouldn't even load, a week later it does 
load.  So while not all "fixes" are well publicized, I know there are 
ongoing code changes that do effect the disk subsystems.

Yes FreeBSD is free.  I'm not whining that it doesn't work on this drive 
and controller.  Rather I am trying to report an issue, and follow-up on 
that issue, as this is new hardware.

I have been using FreeBSD since 2.X.  In my experience over the years and 
releases, problems do not get fixed if no one knows they exist.  With 4.9 
and 5.2 on the horizon, and more SATA drives and cards getting used it is 
reasonable to expect more users having problems with a Sil3112A based 
controller.

-Derek



At 07:35 AM 9/22/2003 -0700, Scott Likens wrote:
On Mon, 2003-09-22 at 06:54, Derek Ragona wrote:
> I couldn't make a kernel with 9/19 cvsuped.  I downloaded and installed 
the
> 9/20 snapshot.  That also wouldn't complete a buildworld without breaking
> with the hard drive error.
>
> I booted windows and stress tested the drive with all kinds of I/O.  Not a
> hiccup.
>
> It isn't the hardware, it has to be the driver code under 5.1-current.
>
>  -Derek

Okay, this is off the subject here on this.

But I wanted to comment,

Just because something 'works' in another "OS" doesn't mean it's working
right.
Just because my VIA KT133A chipset doesn't hiccup in Windows, doesn't
mean it's not broken.  Just because I get Data corruption in FreeBSD due
to my KT133A chipset, doesn't mean it's FreeBSD's fault.
Infact, you'll find FreeBSD and other accompany'ing OS's that are
GNU/GPL/BSD licenesed to have a more strict driver set.  They can show
you things you wouldn't normally see in other "OS's" so to speak.
As i said this is off topic, but saying

"But it works in Windows", is like saying But i'm a complete idiot who
doesn't have a friggen clue how to help.
Don't take this at all personally, it's just that i've hung out in the
usenet groups, and irc channels long enuf to see the same thing over and
over again.
So I wanted to stop this trend before it started.

>From my personal experience, if you want something fixed with any "Free"
"OS" you need to give the person who's fixing the problem as much
information as possible.
In otherwords, turning on all the debugging features, including DDB and
trying to help them delve into it and find out what the exact problem
really is.
It maybe a problem with the controller, maybe the drive, maybe your
system.  At any rate, you're other "OS" *cough* does work properly.
That doesn't mean that the driver in that other "OS" isn't correcting a
hardware issue on the controller that was seen after manufactering.
Infact it's quite common to see "Defects" after manufactering that the
driver does correct.
So please bear in mind a few things,

One, everyone here does this for the Love of FreeBSD,

Two, it's free.

So in essence you get what you pay for, We do what we can to bring you
the best damned "Free" "OS" possible.  But we don't always have the
resources to get all the information possible to create the drivers.
Some Hardware Manufacter'ers are more then willing to give us specs and
hardware to test their hardware and help us write drivers.  Others are
flat out do it yourself.  Then you have even to the more extreme where
they don't want us to write drivers.
So, if you could please get as much information possible as to why?  It
may mean your system working properly and not.
Sincerely,

Scott M. Likens

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

I couldn't make a kernel with 9/19 cvsuped.  I downloaded and installed the 
9/20 snapshot.  That also wouldn't complete a buildworld without breaking 
with the hard drive error.

I booted windows and stress tested the drive with all kinds of I/O.  Not a 
hiccup.

It isn't the hardware, it has to be the driver code under 5.1-current.

-Derek

At 02:53 PM 9/20/2003 -0500, Derek Ragona wrote:
The 9/19 snapshot has the same issues.

I will try to cvsup it and build a new kernel, if I can.

-Derek

At 05:36 AM 9/20/2003 -0500, Derek Ragona wrote:
This was using the 9/18 snapshot, I tried to cvsup it to the most 
current, but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error 
still exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable 
nature (not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network problems

[Derek Ragona]

try to get a diagnostic program from dell or the card maker.  If the 
diagnostics are fine, it may be power management, you will need to check 
and reset to off any power management that effects the NIC.

-Derek

At 11:18 PM 9/20/2003 +0100, you wrote:
I have a strange problem with my Dell Inspiron Laptop.  The network card
will stop responding to all network traffic.  This happens very
regulally, though without any obvious pattern.  Sometimes it only
appears as slight packet lose though normally the network connection
goes completly.  But then at other times the connection stays up for a
resonable time.  I have tried different cables, hubs, etc but to no
avail.
Link status doesn't seem to get dropped, only IP.

When the connection gets dropped doing an ifconfig down/up on the
interface does ?
Unplugging and then inserting the network cable will restore the
connection for at least a few seconds.
I am running a recent current:
FreeBSD opal.macaroon.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19
21:59: 12 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPAL
i386
The network card is an integrated intel card, (fxp0):

fxp0: flags=8843 mtu 1500
options=3
inet 10.1.10.200 netmask 0xff00 broadcast 10.1.10.255
ether 00:20:e0:69:50:3c
media: Ethernet autoselect (100baseTX )
status: active
Unfortunatly I can't remember when it started happening.  I have been
tracking current weekly for the past few months.  It certainly seems to
be getting worse though.
Any help would be much appriciated.

Cameron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

The system died in buildworld, this time it fell into the debugger.

spec_getpages(ad4s1d) I/O read failure (error=5)

-Derek

At 02:53 PM 9/20/2003 -0500, Derek Ragona wrote:
The 9/19 snapshot has the same issues.

I will try to cvsup it and build a new kernel, if I can.

-Derek

At 05:36 AM 9/20/2003 -0500, Derek Ragona wrote:
This was using the 9/18 snapshot, I tried to cvsup it to the most 
current, but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error 
still exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable 
nature (not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

The 9/19 snapshot has the same issues.

I will try to cvsup it and build a new kernel, if I can.

-Derek

At 05:36 AM 9/20/2003 -0500, Derek Ragona wrote:
This was using the 9/18 snapshot, I tried to cvsup it to the most current, 
but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error still 
exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable nature 
(not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA drive lock-up

[Derek Ragona]

This was using the 9/18 snapshot, I tried to cvsup it to the most current, 
but the drive errors prevent the update.

I just reloaded with the 9/19 snapshot, and will report if the error still 
exists.

As for the hardware, it is all brand new hardware, and the system dual 
boots, the other OS has no issues.

-Derek

At 10:07 AM 9/20/2003 +0200, Soren Schmidt wrote:
It seems Derek Ragona wrote:
> I have a single SATA drive on an Adaptec 1210SA card.
>
> The drive will give a write error warning a few times, then will 
repeatedly
> give:
> ad4: timeout sending command=ca
>
> The only recovery is the reset switch, reboot single-user fsck, and then
> come back up in multiuser.
>
> These errors occur with disk access, but not with a predictable nature 
(not
> on large files, or small files, etc.)

And you are on an uptodate -current ?

If so I'd suspect HW ...

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

SATA drive lock-up

[Derek Ragona]

I have a single SATA drive on an Adaptec 1210SA card.

The drive will give a write error warning a few times, then will repeatedly 
give:
ad4: timeout sending command=ca

The only recovery is the reset switch, reboot single-user fsck, and then 
come back up in multiuser.

These errors occur with disk access, but not with a predictable nature (not 
on large files, or small files, etc.)

If more information is needed, let me know.



-Derek
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ad4 device

[Derek Ragona]

I tried to install the 9/15 snapshot which looks like it now supports 
Adaptec SATA and Adaptec 1200A Raid controllers.  Unfortuneatly on two 
systems I tried to install this on, both failed with the error /dev/ad4s1a 
no device present.

Since devices are automatically created in 5.X is there any work around to 
this?



-Derek
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"