Re: kern/43345: Support for the SiS 651 ATA controller
Hi, When I attempted to install FreeBSD 5.0-RELEASE on a Shuttle SS51G box, just like some other users, I encountered the ata0: READ command timeout error during boot. I then tried 4.7-RELEASE and saw the same problem. A quick search of the FreeBSD mail archives turned up other users with my same hardware (which uses the SiS 651 ata controller) who had encountered this. Those messages told me that I needed to either disable UDMA in my system's BIOS, or set the sysctl variable hw.ata.ata_dma to zero. I disabled UDMA in my BIOS and was able to complete the install. Then on one of the messages, I noticed a link to Patrick Bihan-Faou's problem report, read it, and tried out his patch under 5.0-CURRENT (having completed my install of 5.0-RELEASE and updated to -CURRENT). Of course the line numbers were a bit different, but a hand patch of the two files was quick and easy. A quick kernel recompile, BIOS re-enable of UDMA, and boot proved the patch worked! Thank you, Patrick, for your patch! Now for a few questions: Is there any way Patrick's solution could be temporarily committed to -CURRENT and/or -STABLE until Soeren's forthcoming real solution is available (the one Soeren mentions in the PR)? Is there some bad side effect to Patrick's two-line temporary fix that I should worry about? If there are no negatives to the patch (other than a better fix is coming in the future), is there some other reason that the patch is not a good temporary solution for users with SiS 651 based systems, so they can install and boot to FreeBSD without the work-arounds (BIOS or sysctl setting change)? Thanks for your good work, Soeren, and thanks again for your patch, Patrick. Aaron out. P.S. Here is Patrick's solution as a diff against a recent 5.0-CURRENT: --- /usr/src/sys/dev/ata/ata-dma.c.orig Fri Feb 7 11:22:38 2003 +++ /usr/src/sys/dev/ata/ata-dma.c Fri Feb 7 11:23:24 2003 @@ -645,6 +645,7 @@ ata_find_dev(parent, 0x06401039, 0) || /* SiS 640 */ ata_find_dev(parent, 0x06451039, 0) || /* SiS 645 */ ata_find_dev(parent, 0x06501039, 0) || /* SiS 650 */ + ata_find_dev(parent, 0x06511039, 0) || /* SiS 651 */ ata_find_dev(parent, 0x07301039, 0) || /* SiS 730 */ ata_find_dev(parent, 0x07331039, 0) || /* SiS 733 */ ata_find_dev(parent, 0x07351039, 0) || /* SiS 735 */ --- /usr/src/sys/dev/ata/ata-pci.c.orig Fri Feb 7 11:22:46 2003 +++ /usr/src/sys/dev/ata/ata-pci.c Fri Feb 7 11:23:40 2003 @@ -189,6 +189,7 @@ ata_find_dev(dev, 0x06401039, 0) || ata_find_dev(dev, 0x06451039, 0) || ata_find_dev(dev, 0x06501039, 0) || + ata_find_dev(dev, 0x06511039, 0) || ata_find_dev(dev, 0x07301039, 0) || ata_find_dev(dev, 0x07331039, 0) || ata_find_dev(dev, 0x07351039, 0) || To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/43345: Support for the SiS 651 ATA controller
Soeren Schmidt [EMAIL PROTECTED] wrote: It seems Aaron D. Gifford wrote: Then on one of the messages, I noticed a link to Patrick Bihan-Faou's problem report, read it, and tried out his patch under 5.0-CURRENT (having completed my install of 5.0-RELEASE and updated to -CURRENT). Of course the line numbers were a bit different, but a hand patch of the two files was quick and easy. A quick kernel recompile, BIOS re-enable of UDMA, and boot proved the patch worked! The patch does *not* work, the reason you have it sortof working is that the driver writes to the wrong regs, and your BIOS set up the mode correctly.. I have a working solution here, and it will get committed to -current as soon as I have it tested some more. This cannot easily be backported to -stable since it is part of a major rewrite of parts of the ATA driver. However when it has proven to be working, I'll try to get the SiS part backported to the older ATA driver in -stable, time permitting... -Søren Thanks for the clarification. I'd better disable UDMA on my system then to avoid any data corruption. Would it be a good idea to annotate the PR with your above comments? My initial reading of the PR made it sound like the patch would work in a kludgy way without problems while your complete update was in the works. From your above comments, this interpretation was wrong. The patch is buggy and dangerous. I'll keep my eyes open for your fix. Thanks again for your work and for taking the time to let me know this. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC3 /etc/rc.d/ipfw natd start-up script bug -- was: 5.0-RC1/etc/rc.d/ipfw script and NAT
Is there any chance of getting the fix suggested in PR-47024 in 5.0 before release? Looks like a similar script bug with natd start-up was fixed in 4.x-STABLE back in Feb. of 2002 -- See the CVS logs for /etc/rc.network, in particular, cjc's log entries for revision 1.124 (MAIN) and revision 1.74.2.31 (RELENG_4) where this very same bug was addressed and fixed in rc.network. Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1 /etc/rc.d/ipfw script and NAT
Hi,
There's trouble in the /etc/rc.d/ipfw script in how it changes things
versus the 4.7 /etc/rc.network script when it comes to NAT in certain
configurations.
For example, on my home gateway box, rc.conf contains:
# Network address translation:
natd_enable=YES
natd_interface=
natd_flags=-f /etc/natd.conf
Notice that I deliberately do NOT list any interfaces because I am using
an explicit configuration file (the -f /etc/natd.conf flags). Under
4.7-STABLE, the natd daemon will be started appropriately even though
the natd_interface variable is empty, so long as natd_enable is YES
and so long as I am smart enough to have some sort of configuration
available to natd.
Under 5.0-RC1, /etc/rc.d/ipfw makes a 2-line change, moving the lines
that actually start the natd daemon up inside of an if statement. This
means folks like myself who use an explicit configuration file (i.e. I
don't run natd on any one specific interface - I run it inbound on one
interface, outbound on another using a custom ipfw ruleset and natd
configuration file) cannot have natd auto-start without changing
/etc/rc.d/ipfw or starting it by hand somewhere else.
May I request that the two lines in /etc/rc.d/ipfw that start natd be
moved down a few lines outside of the enclosing if block so that the
functionality many of us -STABLE users are accustomed to may be
returned? If not, can anyone shed some light on why it's a bad idea and
offer any suggestions to me? (I like to make as few changes to my BSD
box as possible to have it run how I want it to.)
Thanks!
Aaron out.
- NATD section of /etc/rc.d/ipfw as I would like to see it -
# Network Address Translation daemon
#
if checkyesno natd_enable; then
if [ -n ${natd_interface} ]; then
if echo ${natd_interface} | \
grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then
natd_flags=$natd_flags -a ${natd_interface}
else
natd_flags=$natd_flags -n ${natd_interface}
fi
fi
echo -n ' natd'
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HELP: vinum and newfs on 5.0-RC1
I wrote in my previous message: # newfs -O 2 -U /dev/vinum/raid5vol newfs: /dev/vinum/raid5vol: 'e' partition is unavailable ... Here's my vinum setup: ... volume raid5vol Let me correct this to state that the full volume name was raid5volume and I just shortened it to save typing. This turns out to be important. Looking at newfs.c, it looks like the last letter of the special device is used to choose the partition. Thus e was selected during my attempts to do newfs. (Note to self: Do NOT to abbreviate when reporting trouble.) Today I renamed my vinum volume as sp1a, and newfs worked just fine: #newfs -U -O 2 /dev/vinum/sp1a A few attempts to use disklabel on /dev/vinum/sp1a still had some problems (i.e. any changes made during 'disklabel -e /dev/vinum/sp1a' were still ignored as subsequent disklabel sessions would revert to the version I saw before my changes - 'disklabel -e -r /dev/vinum/sp1a' did save my changes to the on-disk--or on vinum volume in this case--label but the in-memory label remaind unchanged), but apparently I didn't really need to use disklabel with this newly named volume. So... Is there some place in the vinum manual that I missed that discusses volume naming requirements that had I read I could have avoided this trouble? Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HELP: vinum and newfs on 5.0-RC1
Craig Boston wrote: On Wed, 2002-12-11 at 13:45, Aaron D. Gifford wrote: Let me correct this to state that the full volume name was raid5volume and I just shortened it to save typing. This turns out to be important. Looking at newfs.c, it looks like the last letter of the special device is used to choose the partition. Thus e was selected during my attempts to do newfs. (Note to self: Do NOT to abbreviate when reporting trouble.) I don't know if this is still the case with Current/GEOM, but isn't this what newfs -v is for...? Craig That's what I tried at first, to discover that 5.0-RC1's newfs no longer had -v support. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HELP: vinum and newfs on 5.0-RC1
Okay, I had a vinum RAID5 set working on 4.7. Since I didn't have any data on it yet and saw today's announcement of 5.0-RC1, I thought I'd give 5.0-RC1 a try on the box in question. Vinum sees the RAID5 set I created just fine, so I decided to use newfs to create a UFS2 filesystem on the volume. Call me an idiot, but I can't seem to figure out how to do this despite searching various FreeBSD mailing lists. It appears 5.0 no longer supports the -v option, so I assume vinum support is now built-in. Here's what I'm trying: # newfs -O 2 -U /dev/vinum/raid5vol newfs: /dev/vinum/raid5vol: 'e' partition is unavailable That's funny. After reading around a bit, I wondered if perhaps some sort of disk label is now required on the vinum volume. However, no matter how I try using disklabel, disklabel complains about my attempts. Here's my vinum setup: drive d0 device /dev/ad0s1f drive d1 device /dev/ad1s1f drive d2 device /dev/ad2s1f drive d3 device /dev/ad3s1f volume raid5vol plex name p5 org raid5 512s vol raid5vol sd name sd0 drive d0 plex p5 len 232798208s driveoffset 265s plexoffset 0s sd name sd1 drive d1 plex p5 len 232798208s driveoffset 265s plexoffset 512s sd name sd2 drive d2 plex p5 len 232798208s driveoffset 265s plexoffset 1024s sd name sd3 drive d3 plex p5 len 232798208s driveoffset 265s plexoffset 1536s DEVFS shows: /dev/vinum: control controld plex: p5 sd: sd0 sd1 sd2 sd3 raid5vol Disklabel /dev/vinum/raid5vol shows me: type: Vinum disk: vinum label: radi flags: bytes/sector: 512 sectors/track: 698394624 tracks/cylinder: 1 sectors/cylinder: 698394624 cylinders: 1 sectors/unit: 689394624 rpm: 14400 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 Partitions: #size offsetfstype [fsize bsize bps/cpg] a: 69839462404.2BSD 1024 8192 0 # (Cyl. 0 - 0) b: 6983946240 swap # (Cyl. 0 - 0) c: 6983946240unused0 0# (Cyl. 0 - 0) I tried editing it, setting a: to unused, size 0, removing b:, and creating e: just like a: as above. Of course disklabel complained about a zero size, so I completely removed a:, then disklabel complained about e: being out of range a-c, so I renamed e: as a: and it seemed happy. At least until I double checked the data and a subsequent disklabel call showed that all my changes had been silently discarded and the above showd up anew. The vinum label command also appears useless, happily executing but changing nothing. Now for the questions: How does one create a new filesystem (UFS2 in particular) on a vinum volume in 5.0? Is some sort of label required? Help! Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Trying to get CURRENT
Hello, For fun, this last weekend I decided to update from 3.4-STABLE to -CURRENT and try out some of the new features. I grabbed the sources (cvsup) and following the directions in UPDATING managed to build everything and install everything. Whew! I then compiled a new GENERIC kernel and rebooted. Eeek! Failure! The -CURRENT GENERIC kernel choked when it tried to access my SCSI drives. Here's the details: Machine: PII-350 2/64MB RAM Number9 Motion 771 PCI video card Tekram 390U2W PCI SCSI3 controller card 1 Seagate Cheetah 4 GB drive 1 IBM UltraStore 36GB 10KRPM drive PS/2 mouse keyboard Kingston EtheRx KNE100TX PCI 10/100 NIC While 3.4-STABLE worked well with the Tekram SCSI card (during boot I seem to recall seeing a few errors that did not stop booting and no errors seemed to occur later at all even under heavy disk usage), when I attempted to boot the -CURRENT kernel, here's what I saw: sym0: 895 port 0xc800-0xc8ff mem 0xe7001000-0xe70010ff,0xe700-0xe7ff irq 9 at device 15.0 on pci 0 sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking ... Then the following two errors would repeat endlessly, scrolling forever shortly after the "Waiting 15 seconds for SCSI devices to settle" message: sym0: SCSI parity error detected: SCR=1 DBC=7258 SBCL=af (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. Since my userland was now -CURRENT, I was unable to reboot using my old 3.X kernel since even /bin/sh from 4.X would core dump (signal changes, I expect). So I then endeavord to find a 4.X kernel I could use to boot. I grabbed the floppies from the January 25th -CURRENT snapshot from current.freebsd.org and booted. The -CURRENT kernel on the floppy was happy to boot my Tekram SCSI system just fine with no errors. So I mounted my disks, rearranged things, unmounted the fixit floppy once I could use the tools on my drives, mounted the snapshot kernel floppy and copied the kernel from it. Now I can boot my system okay using that kernel. So now for my SCSI question(s) since I'm a -CURRENT newbie: what might the problem be, and where would I look to discover what changes between 25 Jan. and Feb. 3 and 5 may have occured that would result in the problems I describe above? Now for another unrelated question: My Kingston EtheRX KNE100TX 100/10 PCI net card works perfectly when I boot to Win98. I use it with a crossover cable to talk to another Win98 workstation. But every time I boot to FreeBSD, both 3.4-STABLE and -CURRENT equally detect the Intel DEC-clone 21143 chipset, detect the ethernet address, detect the 100baseTX connection and enable the port. I ifconfig the de0/dc0 card and it happily accepts things. But from there on out, it does not work. It refuses to send or receive traffic. I know the card works (that other "evil" OS is happy with it) and the cabling is fine. I've also heard others mention using similar cards using the Intel 21143 chips just fine. I'm stumped why this isn't working under FreeBSD. Any and all pointers/tips/answers/help appreciated! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world dying
I'm still trying to upgrade from 3.0-RELEASE to 3.0-CURRENT unsuccessfully. It used to die in perl, then that was fixed, but for the past 2 days, it has been dying in /usr/src/sys/boot/i386/libi386. Is this a known problem? Yes, I'm a CURRENT newbie, but hopefully only until the split to 3.1 when I can hopefully then play with 3.1-STABLE. Are questions such as the above better addressed to -questions or -current? Thanks. Hoping to catch a cvsup when the source tree will build, Aaron out. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
