Re: am2 MBs - 4g + SCSI wipes out root partition
Gary Jennejohn writes: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. Is this specific to the Adaptec driver or all of them are affected by the bug? I am considering upgrading to such a config, but with a tekram controller (sym). Jean-Marc -- Jean-Marc Zucconi -- PGP Key: KeyID: 400B38E9 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: details on sata issues and mountroot prompt
On Fri, Oct 10, 2008 at 10:24:02PM -0700, Brian wrote: Brian wrote: I have previously written about a mountroot prompt, here are some details. I have a system with an asus m3a78-emh hdmi board, a 74 gig raptor drive, and a dual core amd am2 cpu. I have had this result with both the amd64 and i386 systems. My steps were all conducted today as follows. install 7.0 release run freebsd-update get src tree build world build and install kernel reboot and be greeted by a mountroot prompt. It appears the drive numbering changed. /etc/fstab has the drive partitions with the number 5, the subsequent reboot got me a number 8. This is a test system not doing anything, so I can kick it any which way to test stuff. Brian Whalen I see that I could probably address it with something like this. ed /etc/fstab 1,$s/ad5/ad8/ w q I see. So the problem really isn't that your machine locks up or crashes at the mountroot prompt, it's that the SATA drive IDs changed between 7.0-RELEASE and 7.1-PRERELEASE. This is probably because support for some piece of your system was added to FreeBSD, and now the SATA interface refers to the drives in a different order. Possibly your board has support for AHCI which did not work with older FreeBSD 7.0 but now does with 7.1. I see it when doing things like enabling Compatible mode in the BIOS for SATA chips, or when toggling between AHCI and SATA Enhanced mode. I've also seen it when adding an ATA/SATA controller to the system (I just dealt with this on my home FreeBSD box not more than 2 weeks ago). You just type in the new root slice **once**, mount all the filesystems by hand (/usr, /var, etc.) so that you can get vi working (or use ed(1) as you stated), make the changes to /etc/fstab, and reboot. I forget how exactly FreeBSD determines what the root disk/slice is, so whenever I deal with this, I run bsdlabel -B on the disk slice, e.g. bsdlabel -B ad8s1. Do NOT run it on the disk (ad8) unless you are using dangerously dedicated mode (please don't). -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-p5 watchdog timer not being disabled
Le Fri, 10 Oct 2008 09:08:47 -0400, Stephen Clark [EMAIL PROTECTED] a écrit : On both of the above platforms this does not work and the platforms reboot when watchdogd is killed with a kill pid, after the timeout value (-t) that had been specified to watchdogd when starting it has elapsed. t Am I misunderstanding how this is suppose to work? No, i have tested on my net5501 on freebsd-current. It works. Can you try with watchdog -d -t time followed by a watchdog -t 0 to disable the watchdog ? There is a problem on the net5501 when you disable and then re-enable the watchdog after the timer has elapsed: the box reboots immediatly. But you can disable the timer. Regards. You are correct if I kill watchdogd then run watchdog -t 0 the box does not reboot. The problem is the with the watchdogd program if it is killed with a sigtint or sigterm it is suppose to disable the watchdog timer and exit. It is not appear to be disabling the timer, because my box is rebooting. It works fine for me on Current, I don't know why this don't work on RELENG_6. The code of watchdogd looks to be the same. Sorry, i can't help more. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cvsup 7.0 STABLE checkout failure
I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: No such filer or directory SUPFILE - default stable-cvsup from /usr/share/examples/cvsup -- pls, indicate what i am doing wrong here? - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sat, Oct 11, 2008 at 11:33:08PM +0530, Shakul M Hameed wrote: Forwarding original msg to freebsd-questions mailing list. On Sat, Oct 11, 2008 at 11:06:13PM +0530, Shakul M Hameed wrote: I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: No such filer or directory SUPFILE - default stable-cvsup from /usr/share/examples/cvsup -- pls, indicate what i am doing wrong here? 1) Your setup looks very custom. I see SMB/CIFS in use, and you're using a non-standard directory for the cvsup CVS data (the default is /usr/sup). You're either starting cvsup with some custom arguments or your supfile *is* in fact modified. 2) Check permissions and ownership of all directories leading up to /usr/home/moin/smbmount/code/SUPDB/sup/src-all. Yes, check every single one. 3) Ensure your umask is 022 before starting cvsup. This could be a side result of item #2. 4) I'm not sure why you're using cvsup on a 7.x box when csup comes with the base system. I would also try doing this as a last resort: rm -fr /usr/home/moin/smbmount/code/SUPDB/sup/src-all rm -fr /usr/src/* csup -h cvsupserver -L 2 /usr/share/examples/cvsup/stable-supfile However, with regards to use of /usr/share/examples/cvsup/stable-supfile see my above comment; yours may be modified. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
Forwarding original msg to freebsd-questions mailing list. On Sat, Oct 11, 2008 at 11:06:13PM +0530, Shakul M Hameed wrote: I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: No such filer or directory SUPFILE - default stable-cvsup from /usr/share/examples/cvsup -- pls, indicate what i am doing wrong here? - Moin -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On 12/10/2008, at 5:03 AM, Shakul M Hameed wrote: Forwarding original msg to freebsd-questions mailing list. On Sat, Oct 11, 2008 at 11:06:13PM +0530, Shakul M Hameed wrote: I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/ checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/ checkouts.cvs:RELENG_7: No such filer or directory If that's onto an SMB share, as it appears to be, it's probably never going to work properly. SMB shares are case insensitive and the FreeBSD src tree is definitely using mixed case, eg. 1:06 Sun 12-Oct [EMAIL PROTECTED]:0 [/usr/src/share/doc/psd/15.yacc] ll total 134 -rw-r--r-- 1 root wheel411 Oct 25 2004 Makefile -rw-r--r-- 1 root wheel 1299 Oct 24 2002 ref.bib -rw-r--r-- 1 root wheel 4008 Oct 31 2002 ss.. -rw-r--r-- 1 root wheel 8445 May 19 2002 ss0 -rw-r--r-- 1 root wheel 6261 May 19 2002 ss1 -rw-r--r-- 1 root wheel 6330 May 19 2002 ss2 -rw-r--r-- 1 root wheel 5364 May 19 2002 ss3 -rw-r--r-- 1 root wheel 11168 May 19 2002 ss4 -rw-r--r-- 1 root wheel 10653 May 19 2002 ss5 -rw-r--r-- 1 root wheel 7397 May 19 2002 ss6 -rw-r--r-- 1 root wheel 6939 May 19 2002 ss7 -rw-r--r-- 1 root wheel 4582 May 19 2002 ss8 -rw-r--r-- 1 root wheel 6864 May 19 2002 ss9 -rw-r--r-- 1 root wheel 7232 May 19 2002 ssA -rw-r--r-- 1 root wheel 2812 May 19 2002 ssB -rw-r--r-- 1 root wheel 4775 May 19 2002 ssa -rw-r--r-- 1 root wheel 4574 May 19 2002 ssb -rw-r--r-- 1 root wheel 10467 May 19 2002 ssc -rw-r--r-- 1 root wheel 3319 May 19 2002 ssd overlap in ssA and ssa, ssB and ssb There's probably many more examples buried in unexpected places. SUPFILE - default stable-cvsup from /usr/share/examples/cvsup -- pls, indicate what i am doing wrong here? - Moin -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sat, Oct 11, 2008 at 05:38:26AM -0700, Jeremy Chadwick wrote:
On Sat, Oct 11, 2008 at 11:33:08PM +0530, Shakul M Hameed wrote:
Forwarding original msg to freebsd-questions mailing list.
On Sat, Oct 11, 2008 at 11:06:13PM +0530, Shakul M Hameed wrote:
I am trying to download 7.0 stable release through cvsup, but it fails. I
tried changing the server, but still get those errors.
- ERROR ---
Checkout src/share/doc/psd/15.yacc/ss..
Updater failed: Error in
/usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7:
Cannot rename
/usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to
/usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7:
No such filer or directory
SUPFILE -
default stable-cvsup from /usr/share/examples/cvsup
--
pls, indicate what i am doing wrong here?
1) Your setup looks very custom. I see SMB/CIFS in use, and you're
using a non-standard directory for the cvsup CVS data (the default is
Yes, I am using mount_smbfs to mount a network harddrive to store all my
devel code.
I don't want to overcrowd the the root disk
/usr/sup). You're either starting cvsup with some custom arguments or
your supfile *is* in fact modified.
I am using X11 cvsup stable-supfile. This is the snapshot of my modified
cvsup file
# Defaults that apply to all the collections
#
# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=cvsup3.de.FreeBSD.org
*default base=/usr/home/moin/smbmount/code/SUPDB/
*default prefix=/usr/home/moin/smbmount/code/src/
# The following line is for 7-stable. If you want 6-stable, 5-stable,
# 4-stable, 3-stable, or 2.2-stable, change to RELENG_6, RELENG_5,
# RELENG_4, RELENG_3, or RELENG_2_2 respectively.
*default release=cvs tag=RELENG_7
*default delete use-rel-suffix
# If you seem to be limited by CPU rather than network or disk bandwidth, try
# commenting out the following line. (Normally, today's CPUs are fast enough
# that you want to run compression.)
*default compress
## Main Source Tree.
#
# The easiest way to get the main source tree is to use the src-all
# mega-collection. It includes all of the individual src-* collections.
# Please note: If you want to track -STABLE, leave this uncommented.
src-all
2) Check permissions and ownership of all directories leading up to
/usr/home/moin/smbmount/code/SUPDB/sup/src-all. Yes, check every single
one.
3) Ensure your umask is 022 before starting cvsup. This could be a side
result of item #2.
umask is 0022
4) I'm not sure why you're using cvsup on a 7.x box when csup comes with
the base system.
I don't know why ? :-) . But I did as it was listed in the FreeBSD handbook.
I would also try doing this as a last resort:
rm -fr /usr/home/moin/smbmount/code/SUPDB/sup/src-all
rm -fr /usr/src/*
csup -h cvsupserver -L 2 /usr/share/examples/cvsup/stable-supfile
As a lost resort, I did a cvsup -g -L2 stable-supfile, with just changing the
HOST part without changing other entries in stable-supfile, and I was
successful to download the code.
Currently, I am trying out to figure why the customised way is failing.
- Moin
However, with regards to use of /usr/share/examples/cvsup/stable-supfile
see my above comment; yours may be modified.
--
| Jeremy Chadwickjdc 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sun, Oct 12, 2008 at 01:09:53AM +1100, Sean wrote: On 12/10/2008, at 5:03 AM, Shakul M Hameed wrote: Forwarding original msg to freebsd-questions mailing list. On Sat, Oct 11, 2008 at 11:06:13PM +0530, Shakul M Hameed wrote: I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/ checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/ checkouts.cvs:RELENG_7: No such filer or directory If that's onto an SMB share, as it appears to be, it's probably never going to work properly. SMB shares are case insensitive and the FreeBSD src tree is definitely using mixed case, eg. 1:06 Sun 12-Oct [EMAIL PROTECTED]:0 [/usr/src/share/doc/psd/15.yacc] ll total 134 -rw-r--r-- 1 root wheel411 Oct 25 2004 Makefile -rw-r--r-- 1 root wheel 1299 Oct 24 2002 ref.bib -rw-r--r-- 1 root wheel 4008 Oct 31 2002 ss.. -rw-r--r-- 1 root wheel 8445 May 19 2002 ss0 -rw-r--r-- 1 root wheel 6261 May 19 2002 ss1 -rw-r--r-- 1 root wheel 6330 May 19 2002 ss2 -rw-r--r-- 1 root wheel 5364 May 19 2002 ss3 -rw-r--r-- 1 root wheel 11168 May 19 2002 ss4 -rw-r--r-- 1 root wheel 10653 May 19 2002 ss5 -rw-r--r-- 1 root wheel 7397 May 19 2002 ss6 -rw-r--r-- 1 root wheel 6939 May 19 2002 ss7 -rw-r--r-- 1 root wheel 4582 May 19 2002 ss8 -rw-r--r-- 1 root wheel 6864 May 19 2002 ss9 -rw-r--r-- 1 root wheel 7232 May 19 2002 ssA -rw-r--r-- 1 root wheel 2812 May 19 2002 ssB -rw-r--r-- 1 root wheel 4775 May 19 2002 ssa -rw-r--r-- 1 root wheel 4574 May 19 2002 ssb -rw-r--r-- 1 root wheel 10467 May 19 2002 ssc -rw-r--r-- 1 root wheel 3319 May 19 2002 ssd overlap in ssA and ssa, ssB and ssb There's probably many more examples buried in unexpected places. Yes, you are right. The code downloads fine on to /usr. SUPFILE - default stable-cvsup from /usr/share/examples/cvsup -- pls, indicate what i am doing wrong here? - Moin -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. See the freebsd-scsi thread with Subject data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation? from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. See the freebsd-scsi thread with Subject data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation? from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. Thank you -- this is the exact information I was looking for. I will update my Wiki page to reflect this quite major problem. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, 11 Oct 2008 12:08:00 +0200 (CEST) Jean-Marc Zucconi [EMAIL PROTECTED] wrote: Gary Jennejohn writes: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. Is this specific to the Adaptec driver or all of them are affected by the bug? I am considering upgrading to such a config, but with a tekram controller (sym). I observed the same problem with ahc. Can't say whether the sym driver has the problem because I don't have such a controller. I've now taken my SCSI drives out of service and am using SATA only. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
In message [EMAIL PROTECTED], Shakul M Hameed ([EMAIL PROTECTED]) wrote: I am trying to download 7.0 stable release through cvsup, but it fails. I tried changing the server, but still get those errors. - ERROR --- Checkout src/share/doc/psd/15.yacc/ss.. Updater failed: Error in /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: Cannot rename /usr/home/moin/smbmount/code/SUPDB/sup/src-all/#cvs.cvsup-7219.0 to /usr/home/moin/smbmount/code/SUPDB/sup/src-all/checkouts.cvs:RELENG_7: No such filer or directory Does the file system that you are using support colons (:) in file names? If it is FAT, HPFS or NTFS, or a derivative of one of those, it probably doesn't and I suspect that is your problem. Of course I could be very wrong. ;-) Cheers, Nick. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sun, Oct 12, 2008 at 01:21:31AM +0530, Shakul M Hameed wrote: 1) Your setup looks very custom. I see SMB/CIFS in use, and you're using a non-standard directory for the cvsup CVS data (the default is Yes, I am using mount_smbfs to mount a network harddrive to store all my devel code. I don't want to overcrowd the the root disk I'm left wondering if there are some permissions or ownership issues as a result of this. I am using X11 cvsup stable-supfile. This is the snapshot of my modified cvsup file # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=cvsup3.de.FreeBSD.org *default base=/usr/home/moin/smbmount/code/SUPDB/ *default prefix=/usr/home/moin/smbmount/code/src/ # The following line is for 7-stable. If you want 6-stable, 5-stable, # 4-stable, 3-stable, or 2.2-stable, change to RELENG_6, RELENG_5, # RELENG_4, RELENG_3, or RELENG_2_2 respectively. *default release=cvs tag=RELENG_7 *default delete use-rel-suffix # If you seem to be limited by CPU rather than network or disk bandwidth, try # commenting out the following line. (Normally, today's CPUs are fast enough # that you want to run compression.) *default compress ## Main Source Tree. # # The easiest way to get the main source tree is to use the src-all # mega-collection. It includes all of the individual src-* collections. # Please note: If you want to track -STABLE, leave this uncommented. src-all I have no idea what an X11 cvsup stable-supfile is, so I assume you mean you've used /usr/share/examples/cvsup/stable-supfile as a template supfile, but have your own somewhere else. The reason I was confused: you first stated you're using the ones in /usr/share/examples/cvsup, and I assumed that mean you were using it directly. You shouldn't modify any files in /usr/share/examples, as they will be replaced/overwritten during installworld. Your pasted supfile looks fine, however. 2) Check permissions and ownership of all directories leading up to /usr/home/moin/smbmount/code/SUPDB/sup/src-all. Yes, check every single one. Please do this. 3) Ensure your umask is 022 before starting cvsup. This could be a side result of item #2. umask is 0022 4) I'm not sure why you're using cvsup on a 7.x box when csup comes with the base system. I don't know why ? :-) . But I did as it was listed in the FreeBSD handbook. Are you sure? http://www.freebsd.org/doc/en/books/handbook/cvsup.html -- see the first Note: paragraph. I would also try doing this as a last resort: rm -fr /usr/home/moin/smbmount/code/SUPDB/sup/src-all rm -fr /usr/src/* csup -h cvsupserver -L 2 /usr/share/examples/cvsup/stable-supfile As a lost resort, I did a cvsup -g -L2 stable-supfile, with just changing the HOST part without changing other entries in stable-supfile, and I was successful to download the code. I don't see how that would fix or change anything. In fact, I'm fairly certain it doesn't. The error you are receiving from cvsup is telling you I tried to rename a file, but couldn't. This often implies a permissions or ownership thing. Since the directory you're storing stuff in is on an SMB/CIFS share, I cannot help but wonder if that's the cause of the problem (somehow). Currently, I am trying out to figure why the customised way is failing. I see nothing wrong with your supfile. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sun, Oct 12, 2008 at 02:20:52AM +0530, Shakul M Hameed wrote: On Sat, Oct 11, 2008 at 07:47:11AM -0700, Jeremy Chadwick wrote: Are you sure? http://www.freebsd.org/doc/en/books/handbook/cvsup.html -- see the first Note: paragraph. As a newbie to FreeBSD, I would rather like to have a single Code Versioning system. Several methods put newbies in dilemma to decide upon the best suitable procedure. I feel there should be one unique source code management system. csup and cvsup function the same, and they both rely on the same source versioning system. However, cvsup requires Modula3/ezm3 (an external dependency), while csup was written entirely in C and comes with the FreeBSD base system. Does this explain the difference? Thus: pkg_delete cvsup and ezm3 (if installed) from your system, and start using csup. :-) I don't see how that would fix or change anything. In fact, I'm fairly certain it doesn't. The error you are receiving from cvsup is telling you I tried to rename a file, but couldn't. This often implies a permissions or ownership thing. Since the directory you're storing stuff in is on an SMB/CIFS share, I cannot help but wonder if that's the cause of the problem (somehow). Jeremy, as pointed by N.J. Mann recently in a reply in this thread, there is a semicolon in the filename You mean colon, but I understand what you meant. where the rename faliure happened. Because the file checkouts.cvs:RELENG_7 had : in it, which was not created subsequently due to SMB limitation for :-based filenames. Because this the cvsup checked-out halted at this point. Morever, as indicated by Sean [EMAIL PROTECTED] the case-insensitiveness would lead to missing files. I think, I should format my Network drive to NFS to make it really UNIX friendly. NFS is a transport protocol, not a filesystem type. You don't format a disk to be NFS-friendly. You can use NFS with any type of filesystem; UFS/FFS, ZFS, ext2fs, ext3fs, NTFS, MS-DOS, etc... The problem is that you're using an NTFS across smbmount(8). NTFS does not support some characters in filenames, and also is case-insensitive. You are being limited by NTFS, and also possibly by smbmount(8). What you need is to install another disk in your FreeBSD box, or allocate space somewhere on the existing filesystem(s) for your development stuff. If you really want Windows and FreeBSD to play well together, your best option is to run Samba on the FreeBSD box and use UFS2 filesystems, then make the Windows machine mount shares from the FreeBSD machine. The other way around (FreeBSD--Windows) creates problems like the ones you've experienced. Hope this helps. Cheers! -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sat, Oct 11, 2008 at 07:47:11AM -0700, Jeremy Chadwick wrote: On Sun, Oct 12, 2008 at 01:21:31AM +0530, Shakul M Hameed wrote: 1) Your setup looks very custom. I see SMB/CIFS in use, and you're using a non-standard directory for the cvsup CVS data (the default is Yes, I am using mount_smbfs to mount a network harddrive to store all my devel code. I don't want to overcrowd the the root disk I'm left wondering if there are some permissions or ownership issues as a result of this. I am using X11 cvsup stable-supfile. This is the snapshot of my modified cvsup file # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=cvsup3.de.FreeBSD.org *default base=/usr/home/moin/smbmount/code/SUPDB/ *default prefix=/usr/home/moin/smbmount/code/src/ # The following line is for 7-stable. If you want 6-stable, 5-stable, # 4-stable, 3-stable, or 2.2-stable, change to RELENG_6, RELENG_5, # RELENG_4, RELENG_3, or RELENG_2_2 respectively. *default release=cvs tag=RELENG_7 *default delete use-rel-suffix # If you seem to be limited by CPU rather than network or disk bandwidth, try # commenting out the following line. (Normally, today's CPUs are fast enough # that you want to run compression.) *default compress ## Main Source Tree. # # The easiest way to get the main source tree is to use the src-all # mega-collection. It includes all of the individual src-* collections. # Please note: If you want to track -STABLE, leave this uncommented. src-all I have no idea what an X11 cvsup stable-supfile is, so I assume you mean you've used /usr/share/examples/cvsup/stable-supfile as a template supfile, but have your own somewhere else. The reason I was confused: you first stated you're using the ones in /usr/share/examples/cvsup, and I assumed that mean you were using it directly. You shouldn't modify any files in /usr/share/examples, as they will be replaced/overwritten during installworld. Your pasted supfile looks fine, however. 2) Check permissions and ownership of all directories leading up to /usr/home/moin/smbmount/code/SUPDB/sup/src-all. Yes, check every single one. Please do this. 3) Ensure your umask is 022 before starting cvsup. This could be a side result of item #2. umask is 0022 4) I'm not sure why you're using cvsup on a 7.x box when csup comes with the base system. I don't know why ? :-) . But I did as it was listed in the FreeBSD handbook. Are you sure? http://www.freebsd.org/doc/en/books/handbook/cvsup.html -- see the first Note: paragraph. As a newbie to FreeBSD, I would rather like to have a single Code Versioning system. Several methods put newbies in dilemma to decide upon the best suitable procedure. I feel there should be one unique source code management system. I would also try doing this as a last resort: rm -fr /usr/home/moin/smbmount/code/SUPDB/sup/src-all rm -fr /usr/src/* csup -h cvsupserver -L 2 /usr/share/examples/cvsup/stable-supfile As a lost resort, I did a cvsup -g -L2 stable-supfile, with just changing the HOST part without changing other entries in stable-supfile, and I was successful to download the code. I don't see how that would fix or change anything. In fact, I'm fairly certain it doesn't. The error you are receiving from cvsup is telling you I tried to rename a file, but couldn't. This often implies a permissions or ownership thing. Since the directory you're storing stuff in is on an SMB/CIFS share, I cannot help but wonder if that's the cause of the problem (somehow). Jeremy, as pointed by N.J. Mann recently in a reply in this thread, there is a semicolon in the filename where the rename faliure happened. Because the file checkouts.cvs:RELENG_7 had : in it, which was not created subsequently due to SMB limitation for :-based filenames. Because this the cvsup checked-out halted at this point. Morever, as indicated by Sean [EMAIL PROTECTED] the case-insensitiveness would lead to missing files. I think, I should format my Network drive to NFS to make it really UNIX friendly. N.J. Mann [EMAIL PROTECTED] quoted Does the file system that you are using support colons (:) in file names? If it is FAT, HPFS or NTFS, or a derivative of one of those, it probably doesn't and I suspect that is your problem. Of course I could be very wrong. ;-) - Moin Currently, I am trying out to figure why the customised way is failing. I see nothing wrong with your supfile. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | |
Re: cvsup 7.0 STABLE checkout failure
On Sat, Oct 11, 2008 at 08:24:51AM -0700, Jeremy Chadwick wrote: On Sun, Oct 12, 2008 at 02:20:52AM +0530, Shakul M Hameed wrote: On Sat, Oct 11, 2008 at 07:47:11AM -0700, Jeremy Chadwick wrote: Are you sure? http://www.freebsd.org/doc/en/books/handbook/cvsup.html -- see the first Note: paragraph. As a newbie to FreeBSD, I would rather like to have a single Code Versioning system. Several methods put newbies in dilemma to decide upon the best suitable procedure. I feel there should be one unique source code management system. csup and cvsup function the same, and they both rely on the same source versioning system. However, cvsup requires Modula3/ezm3 (an external dependency), while csup was written entirely in C and comes with the FreeBSD base system. Does this explain the difference? Thus: pkg_delete cvsup and ezm3 (if installed) from your system, and start using csup. :-) I don't see how that would fix or change anything. In fact, I'm fairly certain it doesn't. The error you are receiving from cvsup is telling you I tried to rename a file, but couldn't. This often implies a permissions or ownership thing. Since the directory you're storing stuff in is on an SMB/CIFS share, I cannot help but wonder if that's the cause of the problem (somehow). Jeremy, as pointed by N.J. Mann recently in a reply in this thread, there is a semicolon in the filename You mean colon, but I understand what you meant. where the rename faliure happened. Because the file checkouts.cvs:RELENG_7 had : in it, which was not created subsequently due to SMB limitation for :-based filenames. Because this the cvsup checked-out halted at this point. Morever, as indicated by Sean [EMAIL PROTECTED] the case-insensitiveness would lead to missing files. I think, I should format my Network drive to NFS to make it really UNIX friendly. NFS is a transport protocol, not a filesystem type. You don't format a disk to be NFS-friendly. You can use NFS with any type of filesystem; UFS/FFS, ZFS, ext2fs, ext3fs, NTFS, MS-DOS, etc... The problem is that you're using an NTFS across smbmount(8). NTFS does not support some characters in filenames, and also is case-insensitive. You are being limited by NTFS, and also possibly by smbmount(8). What you need is to install another disk in your FreeBSD box, or allocate space somewhere on the existing filesystem(s) for your development stuff. If you really want Windows and FreeBSD to play well together, your best option is to run Samba on the FreeBSD box and use UFS2 filesystems, then make the Windows machine mount shares from the FreeBSD machine. The other way around (FreeBSD--Windows) creates problems like the ones you've experienced. I am never going to do a Windows-FreeBSD mount as it is not required for me. I rather go for extra space on my FreeBSD box. Is there any method to increase the size of my FreeBSD partition?? Thanks, Moin Hope this helps. Cheers! -- | Jeremy Chadwickjdc 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 | -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sun, Oct 12, 2008 at 02:41:34AM +0530, Shakul M Hameed wrote: I am never going to do a Windows-FreeBSD mount as it is not required for me. I rather go for extra space on my FreeBSD box. Is there any method to increase the size of my FreeBSD partition?? Do you mean partition as in I have separate partitions for Windows and FreeBSD, or do you mean partition as in I want to grow /usr to be larger? If the lesser: there are commercial utilities out there (such as Partition Magic) which let you resize partitions. However, I cannot stress this enough: *back up all of your data* before doing this. I have been bit by bugs in PQMAGIC *twice* in my lifetime (the program panic'ing at 99% and causing me to lose all of my data). If the latter: some people will tell you about growfs(8), but I'm not sure how reliable it is. You'll need to become familiar with bsdlabel(8) and fdisk(8) before you can use that. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
In message [EMAIL PROTECTED], Shakul M Hameed ([EMAIL PROTECTED]) wrote: Date: Sun, 12 Oct 2008 02:54:10 +0530 I think you have selected the wrong timezone for your FreeBSD machine. Either that or your clock is about five and a half hours fast. If you really are in Samoa then the offset from UTC is +1100 and not +0530. If you are really new to FreeBSD please do consider having a look at Greg Lehey's excellent book _The Complete FreeBSD_. It is even available on-line these days: http://www.lemis.com/grog/Documentation/CFBSD/ And of course the FreeBSD web site is packed full of useful stuff, e.g. http://www.freebsd.org/projects/newbies.html Cheers, Nick. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On Sun, Oct 12, 2008 at 02:41:34AM +0530, Shakul M Hameed wrote: On Sat, Oct 11, 2008 at 08:24:51AM -0700, Jeremy Chadwick wrote: On Sun, Oct 12, 2008 at 02:20:52AM +0530, Shakul M Hameed wrote: On Sat, Oct 11, 2008 at 07:47:11AM -0700, Jeremy Chadwick wrote: Are you sure? http://www.freebsd.org/doc/en/books/handbook/cvsup.html -- see the first Note: paragraph. As a newbie to FreeBSD, I would rather like to have a single Code Versioning system. Several methods put newbies in dilemma to decide upon the best suitable procedure. I feel there should be one unique source code management system. csup and cvsup function the same, and they both rely on the same source versioning system. However, cvsup requires Modula3/ezm3 (an external dependency), while csup was written entirely in C and comes with the FreeBSD base system. Does this explain the difference? Thus: pkg_delete cvsup and ezm3 (if installed) from your system, and start using csup. :-) I don't see how that would fix or change anything. In fact, I'm fairly certain it doesn't. The error you are receiving from cvsup is telling you I tried to rename a file, but couldn't. This often implies a permissions or ownership thing. Since the directory you're storing stuff in is on an SMB/CIFS share, I cannot help but wonder if that's the cause of the problem (somehow). Jeremy, as pointed by N.J. Mann recently in a reply in this thread, there is a semicolon in the filename You mean colon, but I understand what you meant. where the rename faliure happened. Because the file checkouts.cvs:RELENG_7 had : in it, which was not created subsequently due to SMB limitation for :-based filenames. Because this the cvsup checked-out halted at this point. Morever, as indicated by Sean [EMAIL PROTECTED] the case-insensitiveness would lead to missing files. I think, I should format my Network drive to NFS to make it really UNIX friendly. NFS is a transport protocol, not a filesystem type. You don't format a disk to be NFS-friendly. You can use NFS with any type of filesystem; UFS/FFS, ZFS, ext2fs, ext3fs, NTFS, MS-DOS, etc... The problem is that you're using an NTFS across smbmount(8). NTFS does not support some characters in filenames, and also is case-insensitive. You are being limited by NTFS, and also possibly by smbmount(8). What you need is to install another disk in your FreeBSD box, or allocate space somewhere on the existing filesystem(s) for your development stuff. If you really want Windows and FreeBSD to play well together, your best option is to run Samba on the FreeBSD box and use UFS2 filesystems, then make the Windows machine mount shares from the FreeBSD machine. The other way around (FreeBSD--Windows) creates problems like the ones you've experienced. I am never going to do a Windows-FreeBSD mount as it is not required for me. I rather go for extra space on my FreeBSD box. Is there any method to increase the size of my FreeBSD partition?? Thanks, Moin Never mind. I have dropped the plan for new disk in my freeBSD box. Instead, My Western Digital Network Harddrive exports both SMB and NFS shares. So now I can mount it as NFS. Internally, this harddrive is ext2 formatted and the NFS and SMB exports are exported. Hope this helps. Cheers! -- | Jeremy Chadwickjdc 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 | -- - Moin -- - Moin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
Jeremy Chadwick wrote: On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. See the freebsd-scsi thread with Subject data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation? from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. Thank you -- this is the exact information I was looking for. I will update my Wiki page to reflect this quite major problem. I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac driver) with a 5th generation RAID card with 8G of ram, both have no such corruption problems. Providing this as a counter-example just to document some evidence of which products seem to work fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: Jeremy Chadwick wrote: On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. See the freebsd-scsi thread with Subject data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation? from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. Thank you -- this is the exact information I was looking for. I will update my Wiki page to reflect this quite major problem. I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac driver) with a 5th generation RAID card with 8G of ram, both have no such corruption problems. Providing this as a counter-example just to document some evidence of which products seem to work fine. Is your LSI SAS controller driven by mpt(4) or mfi(4)? Let's break down what we know for sure at this point: aac(4) - not affected aha(4) - unknown ahb(4) - unknown ahc(4) - affected ahd(4) - unknown; no one answered the OP's question in the thread asr(4) - unknown ips(4) - unknown mpt(4) - not affected mfi(4) - unknown sym(4) - unknown Could the problem be specific to certain firmware revisions on the cards? Also adding Scott Long to the CC list. -- | Jeremy Chadwickjdc 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: am2 MBs - 4g + SCSI wipes out root partition
Jeremy Chadwick wrote: On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: Jeremy Chadwick wrote: On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR [EMAIL PROTECTED] wrote: I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. See the freebsd-scsi thread with Subject data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation? from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. Thank you -- this is the exact information I was looking for. I will update my Wiki page to reflect this quite major problem. I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac driver) with a 5th generation RAID card with 8G of ram, both have no such corruption problems. Providing this as a counter-example just to document some evidence of which products seem to work fine. Is your LSI SAS controller driven by mpt(4) or mfi(4)? Let's break down what we know for sure at this point: aac(4) - not affected aha(4) - unknown ahb(4) - unknown ahc(4) - affected ahd(4) - unknown; no one answered the OP's question in the thread asr(4) - unknown ips(4) - unknown mpt(4) - not affected mfi(4) - unknown sym(4) - unknown Could the problem be specific to certain firmware revisions on the cards? Also adding Scott Long to the CC list. All the LSI I reported is driven by mpt, I have no mfi devices. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
Hi, Colin. Any news/thoughts on where we are with this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 7.0 STABLE checkout failure
On 2008-Oct-11 08:24:51 -0700, Jeremy Chadwick [EMAIL PROTECTED] wrote: csup and cvsup function the same, and they both rely on the same source versioning system. Note that csup only supports a subset of cvsup functionality. The most obvious missing feature is CVS mode. If you really want Windows and FreeBSD to play well together, your best option is to run Samba on the FreeBSD box and use UFS2 filesystems, then make the Windows machine mount shares from the FreeBSD machine. I agree in general but this can also lead to similar gotchas on the Windows side if the Unix side has files differing only in case. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgprbYRrbivYj.pgp Description: PGP signature
Re: am2 MBs - 4g + SCSI wipes out root partition
Hello Jeremy On 11.10.08 18:52, Jeremy Chadwick wrote: Could the problem be specific to certain firmware revisions on the cards? Some other idea, which versions of FreeBSD/amd64 are affected? Only 8-CURRENT, or also 6.x- and/or 7.x-RELEASE? As far as I have seen from the reports, it does only happen with more then 3.5 GB RAM and with SCSI disks. 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. bye Fabian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.4-PRELEASE sporadically panicking with fatal trap 12
Hello,
I'm running 6.4-PRELEASE, last built on 2008-10-05 with /usr/src updated on the
same day.
I had a panic that looks to me very similiar to the one described here (hence
the subject):
http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045405.html
What caught my curiosity is the message:
Unread portion of the kernel message buffer:
acd0: WARNING - TEST_UNIT_READY read data overrun 180
kernel trap 12 with interrupts disabled
I don't have atapicam built in the kernel and it wasn't loaded, and I'm pretty
sure no media was inserted in my dvdrw unit since the last boot.
The other report has a similar message too (acd1: WARNING - READ_TOC read data
overrun 1812)
Here's the backtrace:
# kgdb kernel.debug /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Unread portion of the kernel message buffer:
acd0: WARNING - TEST_UNIT_READY read data overrun 180
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x104
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05419e5
stack pointer = 0x28:0xe5928c00
frame pointer = 0x28:0xe5928c18
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 17 (swi6: task queue)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 22h2m3s
Physical memory: 2031 MB
Dumping 287 MB: 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
Reading symbols from /boot/kernel/smbfs.ko...done.
Loaded symbols for /boot/kernel/smbfs.ko
Reading symbols from /boot/kernel/libiconv.ko...done.
Loaded symbols for /boot/kernel/libiconv.ko
Reading symbols from /boot/kernel/libmchain.ko...done.
Loaded symbols for /boot/kernel/libmchain.ko
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc05419e5
0xc05419e5 is in _mtx_lock_sleep (/usr/src/sys/kern/kern_mutex.c:548).
543 * If the current owner of the lock is executing on
another
544 * CPU, spin instead of blocking.
545 */
546 owner = (struct thread *)(v MTX_FLAGMASK);
547 #ifdef ADAPTIVE_GIANT
548 if (TD_IS_RUNNING(owner)) {
549 #else
550 if (m != Giant TD_IS_RUNNING(owner)) {
551 #endif
552 turnstile_release(m-mtx_object);
(kgdb)
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc054d419 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc054d7e6 in panic (fmt=0xc0736da9 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc6bf0300
bootopt = 260
newpanic = 0
ap = 0xc6bf0300 `øÆàÚÆ
buf = page fault, '\0' repeats 245 times
#3 0xc071822c in trap_fatal (frame=0xe5928bc0, eva=0) at
/usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
0, ssd_p = 1, ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
msg = 0x0
#4 0xc07178e4 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960560384, tf_esi = 4,
tf_ebp = -443380712, tf_isp = -443380756, tf_ebx = -937328156, tf_edx = 6,
tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068230171, tf_cs
= 32, tf_eflags = 65538, tf_esp = -937328156, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:270
td = (struct thread *) 0xc6bf0300
p = (struct proc *) 0xc6bef860
sticks = 4999
type = 12
i = 0
ucode = 0
code = 0
eva = 260
#5 0xc06ffaaa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
No locals.
#6 0xc05419e5 in _mtx_lock_sleep (m=0xc82181e4, tid=3334406912, opts=0,
file=0x0, line=0) at
Re: 6.4-PRELEASE sporadically panicking with fatal trap 12
barbara wrote:
Hello,
I'm running 6.4-PRELEASE, last built on 2008-10-05 with /usr/src updated on
the same day.
I had a panic that looks to me very similiar to the one described here (hence
the subject):
http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045405.html
What caught my curiosity is the message:
Unread portion of the kernel message buffer:
acd0: WARNING - TEST_UNIT_READY read data overrun 180
kernel trap 12 with interrupts disabled
I don't have atapicam built in the kernel and it wasn't loaded, and I'm
pretty sure no media was inserted in my dvdrw unit since the last boot.
The other report has a similar message too (acd1: WARNING - READ_TOC read
data overrun 1812)
Here's the backtrace:
# kgdb kernel.debug /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Unread portion of the kernel message buffer:
acd0: WARNING - TEST_UNIT_READY read data overrun 180
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x104
fault code= supervisor read, page not present
instruction pointer = 0x20:0xc05419e5
stack pointer = 0x28:0xe5928c00
frame pointer = 0x28:0xe5928c18
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 17 (swi6: task queue)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 22h2m3s
Physical memory: 2031 MB
Dumping 287 MB: 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
Reading symbols from /boot/kernel/smbfs.ko...done.
Loaded symbols for /boot/kernel/smbfs.ko
Reading symbols from /boot/kernel/libiconv.ko...done.
Loaded symbols for /boot/kernel/libiconv.ko
Reading symbols from /boot/kernel/libmchain.ko...done.
Loaded symbols for /boot/kernel/libmchain.ko
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc05419e5
0xc05419e5 is in _mtx_lock_sleep (/usr/src/sys/kern/kern_mutex.c:548).
543* If the current owner of the lock is executing on
another
544* CPU, spin instead of blocking.
545*/
546 owner = (struct thread *)(v MTX_FLAGMASK);
547 #ifdef ADAPTIVE_GIANT
548 if (TD_IS_RUNNING(owner)) {
549 #else
550 if (m != Giant TD_IS_RUNNING(owner)) {
551 #endif
552 turnstile_release(m-mtx_object);
(kgdb)
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc054d419 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc054d7e6 in panic (fmt=0xc0736da9 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc6bf0300
bootopt = 260
newpanic = 0
ap = 0xc6bf0300 `øŸÆàÚŸÆ
buf = page fault, '\0' repeats 245 times
#3 0xc071822c in trap_fatal (frame=0xe5928bc0, eva=0) at
/usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
0, ssd_p = 1, ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
msg = 0x0
#4 0xc07178e4 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960560384, tf_esi = 4,
tf_ebp = -443380712, tf_isp = -443380756, tf_ebx = -937328156, tf_edx = 6,
tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068230171,
tf_cs = 32, tf_eflags = 65538, tf_esp = -937328156, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:270
td = (struct thread *) 0xc6bf0300
p = (struct proc *) 0xc6bef860
sticks = 4999
type = 12
i = 0
ucode = 0
code = 0
eva = 260
#5 0xc06ffaaa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
No locals.
#6 0xc05419e5 in _mtx_lock_sleep (m=0xc82181e4,
Re: 6.4-PRELEASE sporadically panicking with fatal trap 12
barbara wrote: Hello, I'm running 6.4-PRELEASE, last built on 2008-10-05 with /usr/src updated on the same day. I had a panic that looks to me very similiar to the one described here (hence the subject): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045405.html What caught my curiosity is the message: Unread portion of the kernel message buffer: acd0: WARNING - TEST_UNIT_READY read data overrun 180 kernel trap 12 with interrupts disabled I don't have atapicam built in the kernel and it wasn't loaded, and I'm pretty sure no media was inserted in my dvdrw unit since the last boot. The other report has a similar message too (acd1: WARNING - READ_TOC read data overrun 1812) Here's the backtrace: Interesting. I ran 6.3 for a bit before I changed over to 7.0. Neither 6.3 or 7.0 exhibited this problem. I'm at 7.1 prerelease #4 now, and I'm using Fluxbox instead of Gnome. The system has been up six days with no problems. I'll probably try using Gnome again after 7.1 release is out. There's also a patch to ATA that I might try. Or possibly I'll just wait for 7.1. :-) Obviously I was confused when I wrote about atapicam, in fact the message is about acd0. Anyway I'm sure that no media was inserted during the whole uptime. I'm running both 6 and 7 stable and I've never seen this before too. Few minutes ago, while cron was running, the system froze for a couple of minutes and the these lines was added to /var/log/messages: acd0: WARNING - PREVENT_ALLOW taskqueue timeout - completing request directly acd0: WARNING - PREVENT_ALLOW freeing taskqueue zombie request and again, no media was inserted. The only change I did in the last days was enabling powerd, I have no idea if this could be related. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.4-PRELEASE sporadically panicking with fatal trap 12
barbara wrote:
Hello,
I'm running 6.4-PRELEASE, last built on 2008-10-05 with /usr/src updated
on the same day.
I had a panic that looks to me very similiar to the one described here
(hence the subject):
http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045405.html
What caught my curiosity is the message:
Unread portion of the kernel message buffer:
acd0: WARNING - TEST_UNIT_READY read data overrun 180
kernel trap 12 with interrupts disabled
I don't have atapicam built in the kernel and it wasn't loaded, and I'm
pretty sure no media was inserted in my dvdrw unit since the last boot.
The other report has a similar message too (acd1: WARNING - READ_TOC read
data overrun 1812)
Here's the backtrace:
Interesting. I ran 6.3 for a bit before I changed over to 7.0. Neither
6.3 or 7.0 exhibited this problem.
I'm at 7.1 prerelease #4 now, and I'm using Fluxbox instead of Gnome.
The system has been up six days with no problems. I'll probably try
using Gnome again after 7.1 release is out. There's also a patch to ATA
that I might try. Or possibly I'll just wait for 7.1. :-)
Obviously I was confused when I wrote about atapicam, in fact the message is
about acd0.
Anyway I'm sure that no media was inserted during the whole uptime.
I'm running both 6 and 7 stable and I've never seen this before too.
Few minutes ago, while cron was running, the system froze for a couple of
minutes and the these lines was added to /var/log/messages:
acd0: WARNING - PREVENT_ALLOW taskqueue timeout - completing request
directly
acd0: WARNING - PREVENT_ALLOW freeing taskqueue zombie request
and again, no media was inserted.
The only change I did in the last days was enabling powerd, I have no idea if
this could be related.
Here's another one, but it looks different.
Having no clue, I've restored the not enabled state of powerd for the moment.
# kgdb kernel.debug /var/crash/vmcore.3
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xca0a9228
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc055d136
stack pointer = 0x28:0xe58f8c68
frame pointer = 0x28:0xe58f8ca8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 12 (swi4: clock sio)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 5h19m51s
Physical memory: 2031 MB
Dumping 282 MB: 267 (CTRL-C to abort) 251 235 219 203 187 (CTRL-C to abort)
171 155 139 123 107 91 75 59 43 27 11 (CTRL-C to abort)
Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc054d419 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc054d7e6 in panic (fmt=0xc0736da9 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc6bea900
bootopt = 260
newpanic = 0
ap = 0xc6bea900 `\230Æ\200ÝÆ
buf = page fault, '\0' repeats 245 times
#3 0xc071822c in trap_fatal (frame=0xe58f8c28, eva=0) at
/usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
0, ssd_p = 1, ssd_xx = 0, ssd_xx1 = 0,
ssd_def32 = 1, ssd_gran = 1}
msg = 0x0
#4 0xc07178e4 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960218240, tf_esi = 4,
tf_ebp = -443577176, tf_isp = -443577260, tf_ebx = 0, tf_edx = -624430808,
tf_ecx = -905276896, tf_eax = 19190235, tf_trapno = 12, tf_err = 0, tf_eip =
-1068117706, tf_cs = 32, tf_eflags = 65538, tf_esp = 2, tf_ss = -1068092317})
at /usr/src/sys/i386/i386/trap.c:270
td = (struct thread *) 0xc6bea900
p =
FreeBSD 6.4-RC1 available...
As the next step in the release of FreeBSD 6.4 the FreeBSD 6.4-RC1
builds are now available for testing. This is the first of an expected
two Release Candidates. We encourage you to test out the Release
Candidates, reporting any problems by submitting PRs or via email to the
freebsd-stable list.
The ISO images and FTP install trees are available on the FreeBSD Mirror
sites. Using the primary site as an example:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/6.4/
where ${arch} is one of alpha, amd64, i386, pc98, or sparc64. Checksums
for the ISO images are at the bottom of this messate. The amd64 and
i386 sets include a *preliminary* set of packages, not what is expected
to be included with the release itself. Notably missing is KDE due to
some confusion on my part about exactly what to include. The package
sets included with 6.4-RC2 will be closer to what will be included with
the release.
If you would like to do a source-based update to 6.4-RC1 from an already
installed machine you can update your tree to RELENG_6_4 using normal
cvsup/csup methods. Note that as a somewhat inconvenient side-effect of
the primary FreeBSD source repository now being in SVN the creation of
the RELENG_6_4 branch in the CVS repository wound up checking in a new
version of every file, in some cases only changing the FBSDID. That
will probably make mergemaster a bit tedious. Sorry for the
inconvenience.
The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 6.3-RELEASE or
6.4-BETA can upgrade as follows:
# freebsd-update upgrade -r 6.4-RC1
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.
# freebsd-update install
The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now
After rebooting, freebsd-update neews to be run again to install the new
userland components, and the system needs to be rebooted again:
# freebsd-update install
# shutdown -r now
Note that FreeBSD Update stores downloaded upgrades in /var/db/freebsd-update,
so at least 400MB should be free in /var before running freebsd-update; if
the /var partition is too small, the -d option to freebsd-update can be used
to indicate that the upgrades should be stored in a different directory.
MD5 (6.4-RC1-alpha-bootonly.iso) = 970bdfb05e393134ad14729b5322d6b7
MD5 (6.4-RC1-alpha-disc1.iso) = 35ee5cc2bbc41ba93124916b32879272
MD5 (6.4-RC1-alpha-disc2.iso) = d2add7b4a5537448594b6254c79ed8c9
MD5 (6.4-RC1-alpha-disc3.iso) = 9a892e973b93f440c79b4f15c07d31bd
MD5 (6.4-RC1-alpha-docs.iso) = 2d1bb148c13b195da2b3b815fbf204b0
MD5 (6.4-RC1-amd64-bootonly.iso) = 3b03f0bf6c612fd4e534a495b5466b72
MD5 (6.4-RC1-amd64-disc1.iso) = 9a0f05bac6dd5606fee7588db2158c78
MD5 (6.4-RC1-amd64-disc2.iso) = d32f1e817d73e470d440ff126780fba9
MD5 (6.4-RC1-amd64-disc3.iso) = 7f418eabb06409de7e06624f35ee07c2
MD5 (6.4-RC1-amd64-docs.iso) = 68b7a9aff7e4b2aa348a021f858cd4f8
MD5 (6.4-RC1-i386-bootonly.iso) = 1a62f1fc637a8b788350a3b350de375a
MD5 (6.4-RC1-i386-disc1.iso) = 0447ba250d39a98c17d0caad7f6d1a15
MD5 (6.4-RC1-i386-disc2.iso) = 95926928938163d53c1eaabecf6d86d7
MD5 (6.4-RC1-i386-disc3.iso) = bc1d004b8759889470f6feff42dca515
MD5 (6.4-RC1-i386-docs.iso) = 65cfb50af042e4c9b7397df9194f896f
MD5 (6.4-RC1-pc98-bootonly.iso) = 53baa783ae23cee7f47c86edaa451ca8
MD5 (6.4-RC1-pc98-disc1.iso) = 7536e8fa9897acf249e05c629668ac22
MD5 (6.4-RC1-sparc64-bootonly.iso) = 5b564c9873afb77c87f7542a02f0f800
MD5 (6.4-RC1-sparc64-disc1.iso) = 3f623ad26a3f9d31d0c7cbc1eeb8
MD5 (6.4-RC1-sparc64-disc2.iso) = 20c5e22f1b21e46b865dc4c808ef9147
MD5 (6.4-RC1-sparc64-disc3.iso) = eb367d1fc58a036fd26c610845b84975
MD5 (6.4-RC1-sparc64-docs.iso) = d26e37d477be685ea3bfeab6bf0e2d44
SHA256 (6.4-RC1-alpha-bootonly.iso) =
4fe1d7aff6e6e4b2d410efac220d4a0c4ff28d70cfc88b8728b9a5c13514b334
SHA256 (6.4-RC1-alpha-disc1.iso) =
e3516358623298cdabb8f5ed311f7f27a5f59c6a0727eb9cbf45d76ae75f3131
SHA256 (6.4-RC1-alpha-disc2.iso) =
737c20f486b88e9d1df30e2a4da5f621d8c3e09c5d24a5e726c7ae7a5e2e98df
SHA256 (6.4-RC1-alpha-disc3.iso) =
f74ebc5dc90802f6d7204e4665f37b456015727ed86674a2df131b386c777355
SHA256 (6.4-RC1-alpha-docs.iso) =
a1f45e966ee41a1a96163b5bdd36bff0f6683e4d759880139f540f714660edb0
SHA256 (6.4-RC1-amd64-bootonly.iso) =
8764dcdc301acf9f329e3be6e03dd6e0eca8834054df19a7d25db6fa91cf84e0
SHA256 (6.4-RC1-amd64-disc1.iso) =
360edee939b5090155fcfe3c9927a7b1de7fb6abef0a9bbb909d719a00133d4d
SHA256 (6.4-RC1-amd64-disc2.iso) =
e2b3bf6c5f056168390f56888663bf9dcab433c7113e267ccf60b9a9a008c41f
SHA256 (6.4-RC1-amd64-disc3.iso) =
b9911688713a43a78a9695ce8388ae7494487170cdd1d1dd390c5b52ab4f0567
SHA256 (6.4-RC1-amd64-docs.iso) =
f9cef3cc54a082b0fff5efa9bcc94cb4ffc6c0fa5723e83a1e4958a956037851
SHA256 (6.4-RC1-i386-bootonly.iso) =
Re: rsync or even scp questions....
Hi Gary,
Gary Kline wrote:
I have two desktop computers; three, if you count my new
ThinkPad. The TPad needs a new CAT5 cable, so for now I'm only
considereing the two tower computers.
On the Ubuntu computer I am /home/kline; on my main computer,
my home is /usr/home/kline. The following sh script worked
perfected when my home on tao [FBSD] was /home/kline:
~kline is an alias for the home directory for the user kline. You can
use that in your scripts rather than the full path :)
As far as I know it works in all *nix variants.
Cheers
cya
Andrew
P
#!/bin/sh
PWD=`pwd`;
echo This directory is [${PWD}];
scp -qrp ${PWD}/* ethos:/${PWD}
###/usr/bin/scp -rqp -i /home/kline/.ssh/zeropasswd-id ${PWD}/* \ klin
[EMAIL PROTECTED]:/${PWD}
Question #1: is there any /bin/sh method of getting rid of the
/usr? I switch off between my two computers especially when
get mucked up, as with my upgrade to kde4. (Otherwise, I do
backups of ~kline as well as other critical directories.)
Is there a way of automatically using rsync rather that my
kwik-and-dirty /bin/shell script?
thanks, people,
gary
PS: Complete disclosure: it works one way [tao to ethos] because
I have created a /usr/home/kline/* tree on ethos.
PPS: if this seems like a numbskull query, i only caught a few
hours sleep last night!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
