Re: Let's back out LOADER_ZFS_SUPPORT from STABLE
I just merged a change from current to libstand which increases the number of open file descriptors. This could be what was causing your problems. Can you test it out with the latest RELENG_7? On Sun, Jun 14, 2009 at 7:08 PM, Dan Allen wrote: > > On 14 Jun 2009, at 5:08 PM, Daniel Eischen wrote: > > On Sun, 14 Jun 2009, Dan Allen wrote: >> >> # /dev/ad0s2: >>> 8 partitions: >>> #size offsetfstype [fsize bsize bps/cpg] >>> a: 43591708 20971524.2BSD0 0 0 >>> b: 20971520 swap >>> c: 456888600unused0 0 # "raw" part, don't >>> edit >>> >> >> Seems weird to see swap at offset 0 and partition a after swap. >> I wonder if that is screwing things up. And shouldn't the offset >> for your first slice start at offset 188747685 (from fdisk)? >> > > Interesting insights. > > I forgot to mention that there may be some discrepancies that are a remnant > of reinstalling the OS many times. (Now I know I could have used the > loader.old trick...) > > Anyway, while doing this a dozen times in a couple of days I learned that I > could speed things by not doing newfs(8) each time, so the fsize and bsize > fields are definitely messed up. Yet things seem to work fine. Weird. > > My next experiment is to redo the disk entirely. > > Dan > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ciss(4) not coping with large arrays?
On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen <[EMAIL PROTECTED]> wrote: > > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), > > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for > > any arrays bigger than 2TB. > > In earlier releases (5 and 6 at least) you couldn't create partitions > larger than 2 TB. I don't know whether work has been to circumvent > this in 7 but tools like fsck has to be changed as well. Have you > tried zfs? zfs has nothing to do with this. The driver is not properly dealing with the large volume. set the kernel tunable in loader.conf kern.cam.da.3.minimum_cmd_size=16 kern.cam.da.4.minimum_cmd_size=16 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ciss(4) not coping with large arrays?
On Fri, May 16, 2008 at 1:03 AM, Paul Saab <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen <[EMAIL PROTECTED]> > wrote: > >> > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), >> > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for >> > any arrays bigger than 2TB. >> >> In earlier releases (5 and 6 at least) you couldn't create partitions >> larger than 2 TB. I don't know whether work has been to circumvent >> this in 7 but tools like fsck has to be changed as well. Have you >> tried zfs? > > > zfs has nothing to do with this. The driver is not properly dealing with > the large volume. > > set the kernel tunable in loader.conf > > kern.cam.da.3.minimum_cmd_size=16 > kern.cam.da.4.minimum_cmd_size=16 > > Actually, this has nothing to do with it either.. Please try the following patch: http://yogurt.org/FreeBSD/ciss_large.diff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
The 5754 is more than likely supported by the bge driver. The PCI id's probably have to be added. Kevin Kramer wrote: Sorry, I thought that you and others were working on numerous Broadcom issues including incorrect recognition of the chipsets for the Poweredge 1950's and Precision 390. You had been responding to most of the threads regarding Broadcom issues. -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/18/06 10:26: Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ 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: PERC trouble?
Marko Lerota wrote: Paul Saab <[EMAIL PROTECTED]> writes: this was fixed after 6.1-RELEASE. You need to grab the driver from -stable. What does it mean? That I could run 6.1-RELEASE but have some drivers from -stable or -current? You can use the -stable driver on 6.1-RELEASE if you don't want to upgrade to -stable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PERC trouble?
this was fixed after 6.1-RELEASE. You need to grab the driver from -stable. Ivan Voras wrote: I had a chance today to play a little with a server that was later passed on for deployment, and one of the thing I tried to do was create something unusual - three disk groups/virtual disks on the PERC5/i RAID controller, with a single drive in each group (entered as RAID0). All went fine until I booted FreeBSD 6.1-release (amd64) and tried to do something with the drives. It turned out that, while there WERE three devices mfid[0,1,2], they all "pointed" to the same hardware - the first drive. I.e. accessing either of these would access the first virtual drive, and this is confirmed by watching drive LEDs blinking. The server went away later so I couldn't dig deeper, but I'm wondering if this is a bug in PERC or the driver? ___ 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: i386/100160: [mfid] Perc5i: additional symptomatic info on virtual disk detection issue
revision 1.11 date: 2006/06/20 22:41:44; author: ps; state: Exp; lines: +77 -202 Instead of using scsi probes to do device discovery, use the firmware commands to grab the device listing. This resolves issues using multiple volumes, where each volume was actually internally pointing to target 0. Bucky Jordan wrote: In the meantime if anybody else is aware of another work around of fix for this, I appreciate hearing about it. I've got almost the same setup- 6.1 amd64 RELEASE, a 2950 with 6 drives attached to the Perc5/I SAS Raid controller. Right now I've got the whole thing configured as a RAID5x6 disks and it seems to be working fine. I was able to also create smaller RAID sets (for example, a 4 disk RAID10) without an issue, and I did not have to remove extra drives. Someone (on -hardware I think) mentioned that the problem recognizing multiple virtual volumes is addressed in 6-stable, but I have not had the chance to try it out. I will post the results if/when I do. - Bucky ___ 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: sio+acpi woes on HP DL145 G2
Mars G. Miro wrote: However, *sometimes* serial consoles work only for input (I can login and check new processes presence on ttyd0, but can not see any messages. Trouble is that this situation is not easy reproducible, and stty state seems to be the same. This is a bug in the HP BMC that HP blames on FreeBSD. The only way to work around it, is to have a custom getty that doesn't reset the port everytime you open it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New 'amr' driver and linux MegaMGR
works fine Cristiano Deana wrote: Hi, according to http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/amr/amr.c?only_with_tag=RELENG_6 it seems MegaMGR for linux now can work. Any experience? -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: ciss(4) driver in FreeBSD 6.x ...
Sascha Holzleiter wrote: do you know of any method to monitor these controllers with FreeBSD, e.g. to detect drive failures? No, but the code is in the driver and can be easily adapted to a userland program to probe the controller through the ioctl interface, but the easiest way is to just have something monitor syslog. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ciss(4) driver in FreeBSD 6.x ...
Marc G. Fournier wrote: Hi .. Having read the man page, there is alot in there that makes me wonder whether going with a HP Smart Array P600 is a wise idea ... "The Compaq ciss adapters require faked responses to get reasonable behavior out of them. In addition, the ciss command set is by no means adequate to support the functionality of a RAID controller, and thus the supported Compaq adapters utilize portions of the control protocol from earlier" I'm specifically looking at the Proliant DL360, which has this card ... can you provide any comments, or insight, concerning what the man page states? Should I shy away from this controller? :( The P600 should work just fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reproducible kernel panic
Arjan Van Leeuwen wrote: Please read the original thread: http://lists.freebsd.org/mailman/htdig/freebsd-stable/2004-November/009307.html I couldn't get a crashdump on this machine, but I provided a lot of information (traces) in that thread. Since no one replied to my last post in that thread, I didn't know what else to do. But if you tell me what else you want, I'll get it for you immediately. And Mohan told me that he couldn't really guess as to what caused the problem from the trace. He needs a real crashdump to attempt to understand what went wrong and try to fix it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reproducible kernel panic
Jeff Behl wrote: You're helpful reply doesn't seem to include any information on where to upload a crash dump, if that's what is being asked. I haven't dealt with them before. Perhaps you'd be so kind as to direct? A reply that helps work around a problem is always welcome, especially when it keeps a remotely located host from continuously rebooting. Getting one crashdump and being able to download it would be useful. I cannot provide you with a place to upload it to, but you should be able to put it somewhere that we can grab the core and examine it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reproducible kernel panic
Arjan Van Leeuwen wrote: I had a panic that looked a lot like this (panic in swi, came up when I had some network traffic), and it's also been reported by other people than me. Turning of SACK seems to work for most people (at least it worked for me). Put net.inet.tcp.sack.enable=0 in /etc/sysctl.conf. And how exactly is this supposed to help anyone fix the problem. If you provide crashdumps then solving the problem becomes much easier, but nothing will get fixed if you just turn it off. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: supporting broadcom gig BCM5751
Can you try http://yogurt.org/FreeBSD/bge_5750.diff
It got my 5751 working.
Peter Radcliffe ([EMAIL PROTECTED]) wrote:
> I'm trying to install a new dell machine at work but it's coming up
> with an unknown internal gig ether card and it's stupidly fussy about
> PCI cards (won't boot with random cards in it).
>
> The device is; 0x14e4 0x1677 which some searching tells me is a
> broadcom BCM5751 gig ether card.
>
> Adding the device ids to if_bge.c and if_bgereg.h;
>
> #define BCOM_DEVICEID_BCM5751 0x1677
>
> { BCOM_VENDORID, BCOM_DEVICEID_BCM5751,
> "Broadcom BCM5751 Gigabit Ethernet" },
>
> and PXE booting with the new kernel gives me;
>
> bge0: mem
> 0xdfcf-0xdfcf irq 11 at device 0.0 on pci2
> NMI ISA a0, EISA ff
> RAM parity error, likely hardware failure.
>
> Fatal trap 19: non-maskable interrupt trap while in kernel mode
> instruction pointer = 0x8:0xc028a8cb
> stack pointer = 0x10:0xc0821d4c
> frame pointer = 0x10:0xc0821d54
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, IOPL = 0
> current process = 0 (swapper)
> interrupt mask = net tty bio cam
> trap number = 19
> panic: non-maskable interrupt trap
>
> This doesn't happen with a default kernel (or my special build kernel
> without the source patch). ANy hints or does this need real driver
> support work ?
>
> P.
>
> --
> pir
--
-ps
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/twe twe.c twe_compat.h twe_freebsd.ctwe_tables.h tweio.h twereg.h twevar.h
The latest firmware will be needed to use the 3ware management utilities and unfortunately there is no way to do this online. You will have to flash the controller using a floppy booting into DOS. I just put in changes to the API today which will stop the API from even being used unless it is with the latest driver. Bad mojo will happen if the the API were allowed to be run on older drivers. --On Sunday, August 10, 2003 8:54 PM -0400 Mike Tancsa <[EMAIL PROTECTED]> wrote: Hi, Thank you for your work on this card! I have quite a few boxes that run various 3wares cards with diverse firmware revs. Are there any caveats with respect to models and firmware versions in terms of how they might interact ? ---Mike At 01:25 PM 10/08/2003 -0700, Paul Saab wrote: ps 2003/08/10 13:25:46 PDT FreeBSD src repository Modified files:(Branch: RELENG_4) sys/dev/twe twe.c twe_compat.h twe_freebsd.c twe_tables.h tweio.h twereg.h twevar.h Log: MFC: Support for the 3ware API Revision ChangesPath 1.1.2.7 +92 -59src/sys/dev/twe/twe.c 1.1.2.4 +4 -1 src/sys/dev/twe/twe_compat.h 1.2.2.6 +77 -33src/sys/dev/twe/twe_freebsd.c 1.1.2.3 +3 -0 src/sys/dev/twe/twe_tables.h 1.1.2.3 +10 -0 src/sys/dev/twe/tweio.h 1.1.2.5 +1 -1 src/sys/dev/twe/twereg.h 1.1.2.5 +3 -1 src/sys/dev/twe/twevar.h ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sparc8 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- ===> usr.bin/vi *** Error code 1 (fuck fumerola) *** Error code 1 (fuck matt dillon) ===> usr.bin/vis ===> usr.bin/vmstat ===> usr.bin/w ===> usr.bin/wall ===> usr.bin/wc ===> usr.bin/what ===> usr.bin/whereis ===> usr.bin/which ===> usr.bin/who ===> usr.bin/whois ===> usr.bin/window ===> usr.bin/write ===> usr.bin/xargs ===> usr.bin/xinstall ===> usr.bin/xlint ===> usr.bin/xlint/lint1 yacc: 1 shift/reduce conflict ===> usr.bin/xlint/lint2 ===> usr.bin/xlint/xlint ===> usr.bin/xlint/llib ===> usr.bin/xstr ===> usr.bin/yacc ===> usr.bin/yes ===> usr.bin/ypcat ===> usr.bin/ypmatch ===> usr.bin/ypwhich ===> usr.bin/dig ===> usr.bin/dnskeygen ===> usr.bin/dnsquery ===> usr.bin/host ===> usr.bin/vacation ===> usr.bin/uac ===> usr.bin/chkey ===> usr.bin/newkey ===> usr.sbin ===> usr.sbin/IPXrouted ===> usr.sbin/ac ===> usr.sbin/accton ===> usr.sbin/adduser ===> usr.sbin/amd ===> usr.sbin/amd/include ===> usr.sbin/amd/libamu ===> usr.sbin/amd/amd ===> usr.sbin/amd/amq ===> usr.sbin/amd/doc ===> usr.sbin/amd/fixmount ===> usr.sbin/amd/fsinfo yacc: 2 shift/reduce conflicts ===> usr.sbin/amd/hlfsd ===> usr.sbin/amd/mk-amd-map ===> usr.sbin/amd/pawd ===> usr.sbin/amd/scripts ===> usr.sbin/amd/wire-test ===> usr.sbin/ancontrol ===> usr.sbin/arp ===> usr.sbin/atm ===> usr.sbin/atm/atmarpd ===> usr.sbin/atm/scspd ===> usr.sbin/bootparamd ===> usr.sbin/bootparamd/bootparamd ===> usr.sbin/bootparamd/callbootd ===> usr.sbin/burncd ===> usr.sbin/cdcontrol ===> usr.sbin/chkgrp ===> usr.sbin/chown ===> usr.sbin/chroot ===> usr.sbin/ckdist ===> usr.sbin/config ===> usr.sbin/cron ===> usr.sbin/cron/lib ===> usr.sbin/cron/cron ===> usr.sbin/cron/crontab ===> usr.sbin/crunch ===> usr.sbin/crunch/crunchgen ===> usr.sbin/crunch/crunchide ===> usr.sbin/ctm ===> usr.sbin/ctm/ctm ===> usr.sbin/ctm/ctm_rmail ===> usr.sbin/ctm/ctm_smail ===> usr.sbin/ctm/ctm_dequeue ===> usr.sbin/daemon ===> usr.sbin/dev_mkdb ===> usr.sbin/devinfo ===> usr.sbin/digictl ===> usr.sbin/edquota ===> usr.sbin/extattr ===> usr.sbin/extattrctl ===> usr.sbin/faithd ===> usr.sbin/fdcontrol ===> usr.sbin/fdformat ===> usr.sbin/fdread ===> usr.sbin/fdwrite ===> usr.sbin/fwcontrol ===> usr.sbin/getfmac ===> usr.sbin/getpmac ===> usr.sbin/ifmcstat ===> usr.sbin/inetd ===> usr.sbin/iostat ===> usr.sbin/jail ===> usr.sbin/kbdcontrol ===> usr.sbin/kbdmap ===> usr.sbin/kernbb ===> usr.sbin/kldxref ===> usr.sbin/lastlogin ===> usr.sbin/mailwrapper ===> usr.sbin/manctl ===> usr.sbin/memcontrol ===> usr.sbin/mergemaster ===> usr.sbin/mixer ===> usr.sbin/mld6query ===> usr.sbin/mlxcontrol ===> usr.sbin/mountd ===> usr.sbin/moused ===> usr.sbin/mrouted ===> usr.sbin/mrouted/common ===> usr.sbin/mrouted/mrouted ===> usr.sbin/mrouted/mrinfo ===> usr.sbin/mrouted/map-mbone ===> usr.sbin/mrouted/mtrace ===> usr.sbin/mrouted/testrsrr ===> usr.sbin/mtest ===> usr.sbin/mtree ==-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- ===> usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) ===> usr.bin/vis ===> usr.bin/vmstat ===> usr.bin/w ===> usr.bin/wall ===> usr.bin/wc ===> usr.bin/what ===> usr.bin/whereis =
sparc16 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- ===> usr.bin/vi *** Error code 1 (fuck fumerola) *** Error code 1 (fuck matt dillon) ===> usr.bin/vis ===> usr.bin/vmstat ===> usr.bin/w ===> usr.bin/wall ===> usr.bin/wc ===> usr.bin/what ===> usr.bin/whereis ===> usr.bin/which ===> usr.bin/who ===> usr.bin/whois ===> usr.bin/window ===> usr.bin/write ===> usr.bin/xargs ===> usr.bin/xinstall ===> usr.bin/xlint ===> usr.bin/xlint/lint1 yacc: 1 shift/reduce conflict ===> usr.bin/xlint/lint2 ===> usr.bin/xlint/xlint ===> usr.bin/xlint/llib ===> usr.bin/xstr ===> usr.bin/yacc ===> usr.bin/yes ===> usr.bin/ypcat ===> usr.bin/ypmatch ===> usr.bin/ypwhich ===> usr.bin/dig ===> usr.bin/dnskeygen ===> usr.bin/dnsquery ===> usr.bin/host ===> usr.bin/vacation ===> usr.bin/uac ===> usr.bin/chkey ===> usr.bin/newkey ===> usr.sbin ===> usr.sbin/IPXrouted ===> usr.sbin/ac ===> usr.sbin/accton ===> usr.sbin/adduser ===> usr.sbin/amd ===> usr.sbin/amd/include ===> usr.sbin/amd/libamu ===> usr.sbin/amd/amd ===> usr.sbin/amd/amq ===> usr.sbin/amd/doc ===> usr.sbin/amd/fixmount ===> usr.sbin/amd/fsinfo yacc: 2 shift/reduce conflicts ===> usr.sbin/amd/hlfsd ===> usr.sbin/amd/mk-amd-map ===> usr.sbin/amd/pawd ===> usr.sbin/amd/scripts ===> usr.sbin/amd/wire-test ===> usr.sbin/ancontrol ===> usr.sbin/arp ===> usr.sbin/atm ===> usr.sbin/atm/atmarpd ===> usr.sbin/atm/scspd ===> usr.sbin/bootparamd ===> usr.sbin/bootparamd/bootparamd ===> usr.sbin/bootparamd/callbootd ===> usr.sbin/burncd ===> usr.sbin/cdcontrol ===> usr.sbin/chkgrp ===> usr.sbin/chown ===> usr.sbin/chroot ===> usr.sbin/ckdist ===> usr.sbin/config ===> usr.sbin/cron ===> usr.sbin/cron/lib ===> usr.sbin/cron/cron ===> usr.sbin/cron/crontab ===> usr.sbin/crunch ===> usr.sbin/crunch/crunchgen ===> usr.sbin/crunch/crunchide ===> usr.sbin/ctm ===> usr.sbin/ctm/ctm ===> usr.sbin/ctm/ctm_rmail ===> usr.sbin/ctm/ctm_smail ===> usr.sbin/ctm/ctm_dequeue ===> usr.sbin/daemon ===> usr.sbin/dev_mkdb ===> usr.sbin/devinfo ===> usr.sbin/digictl ===> usr.sbin/edquota ===> usr.sbin/extattr ===> usr.sbin/extattrctl ===> usr.sbin/faithd ===> usr.sbin/fdcontrol ===> usr.sbin/fdformat ===> usr.sbin/fdread ===> usr.sbin/fdwrite ===> usr.sbin/fwcontrol ===> usr.sbin/getfmac ===> usr.sbin/getpmac ===> usr.sbin/ifmcstat ===> usr.sbin/inetd ===> usr.sbin/iostat ===> usr.sbin/jail ===> usr.sbin/kbdcontrol ===> usr.sbin/kbdmap ===> usr.sbin/kernbb ===> usr.sbin/kldxref ===> usr.sbin/lastlogin ===> usr.sbin/mailwrapper ===> usr.sbin/manctl ===> usr.sbin/memcontrol ===> usr.sbin/mergemaster ===> usr.sbin/mixer ===> usr.sbin/mld6query ===> usr.sbin/mlxcontrol ===> usr.sbin/mountd ===> usr.sbin/moused ===> usr.sbin/mrouted ===> usr.sbin/mrouted/common ===> usr.sbin/mrouted/mrouted ===> usr.sbin/mrouted/mrinfo ===> usr.sbin/mrouted/map-mbone ===> usr.sbin/mrouted/mtrace ===> usr.sbin/mrouted/testrsrr ===> usr.sbin/mtest ===> usr.sbin/mtree ==-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- ===> usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) ===> usr.bin/vis ===> usr.bin/vmstat ===> usr.bin/w ===> usr.bin/wall ===> usr.bin/wc ===> usr.bin/what ===> usr.bin/whereis =
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
Danny Braniss ([EMAIL PROTECTED]) wrote: > In message <[EMAIL PROTECTED]>you write: > }This is really weird. I have two valinux rackmount boxes, duel cpu's. > } > }I was testing the PXE stuff and booting one of the boxes regularly. > }All of a sudden every time I reboot I get: > } > > i've seen the same, i just reboot it, and it works. sometimes, while > the kernel is doing it's init stuff it panics. i haven't seen it fail > more than once in a row, so i was thinking maybe some network error > that was not dealt properly. btw, the boxes are DELL. He was not seeing a PXE bug, it was a loader issue with the BIOS. The PXE bug you are seeing is with anything build 078 or earlier. Intel has a bug in their rom which they fixed back in March of this year. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: someone MFC something to -stable recently that would explain ...
Rebuild genassym
paul
The Hermit Hacker ([EMAIL PROTECTED]) wrote:
>
> I've tried to remove locore.s, no difference. I've tried building
> GENERIC, just in case I erroneously removed something while building my
> custom kernel, same error ...
>
> I'm going from a fresh install of 4.1-RELEASE -> 4.1-STABLE, or, at least,
> trying to ... and I'm building the kernel as 'make buildkernel' ...
>
>
> cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs
>-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
>-fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include
> -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2
>/usr/src/sys/i386/i386/locore.s
> /tmp/ccg38208.s: Assembler messages:
> /tmp/ccg38208.s:1743: Error: .space specifies non-absolute value
> /tmp/ccg38208.s:2454: Error: undefined symbol L0^A in operation setting PTmap
> /tmp/ccg38208.s:2454: Error: undefined symbol PDRSHIFT in operation setting PTmap
> /tmp/ccg38208.s:1711: Error: undefined symbol L0^A in operation
> /tmp/ccg38208.s:1711: Error: undefined symbol PAGE_SIZE in operation
> /tmp/ccg38208.s:1712: Error: undefined symbol L0^A in operation
> /tmp/ccg38208.s:1712: Error: undefined symbol PDESIZE in operation
> /tmp/ccg38208.s:2454: Error: undefined symbol L0^A in operation setting APTmap
> /tmp/ccg38208.s:2454: Error: undefined symbol PDRSHIFT in operation setting APTmap
> /tmp/ccg38208.s:1720: Error: undefined symbol L0^A in operation
> /tmp/ccg38208.s:1720: Error: undefined symbol PAGE_SIZE in operation
> /tmp/ccg38208.s:1721: Error: undefined symbol L0^A in operation
> /tmp/ccg38208.s:1721: Error: undefined symbol PDESIZE in operation
> /tmp/ccg38208.s:1927: Error: undefined symbol UPAGES in operation
> /tmp/ccg38208.s:1927: Error: undefined symbol PAGE_SIZE in operation
> /tmp/ccg38208.s:2315: Error: undefined symbol BI_ESYMTAB in operation
> /tmp/ccg38208.s:2320: Error: undefined symbol BI_SYMTAB in operation
> /tmp/ccg38208.s:2321: Error: undefined symbol BI_ESYMTAB in operation
> /tmp/ccg38208.s:2325: Error: undefined symbol BI_KERNEND in operation
>
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Paul Saab
Technical Yahoo
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
Do You .. uhh .. Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pxeboot problems with 4.0-stable
You need to tell me a bit more information.. I know for a fact that build 079 bootroms on the Intel Etherexpress cards (fxp) have no known issues. There are bugs in their older roms which corrupt the stack and cause our loader to trigger a fault. I need to know the card you are using, the Intel build version (07X). Build 079 is the latest build from Intel and it is the only PXE 2.0 rom that I know of which has no known bugs. Anything newer than 079, I have not tested myself.. paul Alan Edmonds ([EMAIL PROTECTED]) wrote: > > Is anyone using pxeboot from 4.0-STABLE with the latest Intel PXE ROM > (3.0.03)? I'm getting a register dump when it's loading the kernel. > > Thanks, > -- > Alan Edmonds Director of International Technology > DigitalConvergence.:Com > [EMAIL PROTECTED] > Phone: +1-214-292-6040 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
