Re: Installing FreeBSD from USB flash drive - some experiments
Here's the steps I use to create a 1GB USB image: # dd if=/dev/zero of=bootable.image bs=1m count=1 oseek=1000 conv=sparse # mdconfig -a -t vnode -f bootable.image -u 0 # newfs -m 0 -o space -n /dev/md0 # mount /dev/md0 /mnt # cd /usr/src # make installworld DESTDIR=/mnt # make distribution DESTDIR=/mnt # make installkernel DESTDIR=/mnt # umount /mnt At this point you have a file "bootable.image" but instead of actually making that a bootable dd image, I choose to create a dump file which is a bit more flexible as you can restore it to a USB stick of any size. # dump -0 -C 8 -f - /dev/md0 | gzip -9 > bootable.dump.gz # mdconfig -d -u 0 At this point, you have a dump file which you can use to create a bootable USB as follows: Assuming the USB stick is /dev/da0 ! # dd if=/dev/zero of=/dev/da0 bs=16k # fdisk -BI /dev/da0 # disklabel -B -w /dev/da0s1 # newfs -m 0 -o space -n /dev/da0s1a # mount -o noatime,async /dev/da0s1a /mnt # gzcat bootable.dump.gz | ( cd /mnt ; restore -rvf - ) # umount /mnt Hope that helps - Andrew ___ 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: Installing FreeBSD from USB flash drive - some experiments
On Wednesday 11 March 2009 13:55:58 Clifton Royston wrote: > I think I have found some limitations of the current sysinstall which > currently make it currently difficult to convert a working FreeBSD ISO > to an installable or live-disk flash image. Booting the kernel is > easy. Getting the rest of the way is harder. I have a working USB installer for 7.1 but it is not terribly straightfoward. > Background: AFAICT the release ISOs don't currently mount the media > they were booted from (da0a in this case.) Instead they load > boot/mfsroot.gz (compressed memory image) as the root fs, which is fine > and makes good sense, but they don't then mount the boot media anywhere > under it. (My guess is that this was probably originally done to > support the floppy boot case.) Yes, I think so. > So how can you direct it to install from the USB media? > > 1) If you try to select media via the menu options, you can't select > USB specifically, nor specify an arbitrary device as the source > (/dev/da0a in this case), so you can't get the booted medium mounted to > install from, so you can't get the distributions accessible, so install > doesn't work. Picking CD as the media seems to mean specifically an > cd or acd device. For some reason the "Install from UFS" thing doesn't let you mount anything, I think this would be fairly easy to fix. I didn't actually attempt to fix this, instead I split my USB stick in 2. The first partition was 2.5Gb FAT32, the last 1.5Gb was UFS. I put the CD image on there and did boot0cfg etc.. The reason FAT goes first is that otherwise when you put it into a Windows PC (as I'd like people to be able to do to edit the install.cfg) Windows gets confused and wants to format the disk.. Putting UFS last gets around this and it still works fine. > 5) "The emergency holographic shell, then?" Yes, you can get into > the emergency holographic shell, with the very limited set of commands > from the mfsroot bin/sbin/stand. However, if you try using the > emergency holographic shell to mount da0a - as far as I can tell, you > can't do so, because there is no mount in mfsboot's stand, only > mount_nfs. (I'm guessing the "mount" operation for acd0 or cd0 is > coded into sysinstall?) The usual mount command of course exists on the > media, but it's on the LiveCD portion which isn't mounted at this > point... Yeah, the lack of mount in /stand on the install disk is a big caveat. I suspect you could go into label and add /dev/da0a (also, argh, DD is bad, use an MBR) and tell it not to newfs it and then sysinstall will mount it for you. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Installing FreeBSD from USB flash drive - some experiments
It seems like questions about installing FreeBSD from a USB drive
come up at regular intervals. With the low price of flash drives these days,
it would
be sort of nice to be able to offer a way for users to conveniently
roll their own USB installer images, or even to offer them for download
as well as the ISOs.
I spent some time working on it this weekend, initially because I was
trying to get the current pfSense 1.2.2 (based on FreeBSD 7.0) to
install on the Geode-based fit-PC box. (I eventually got there with
pfSense 1.2.3, based on 7.1.)
While troubleshooting problems with installing pfSense from USB, I
ended up also building USB images from the 7.1-RELEASE bootonly and the
7.1-RELEASE disc1 ISOs. To do this I've been hacking on Dario Freni's
fbsd-installiso2img.sh script from 2006, to convert FreeBSD or
FreeBSD-based ISOs to image files. Initially I thought everything was
working fine, because the bootonly image came right up into sysinstall,
but when I dug a little deeper and tried with a USB image built from
the disc1 liveCD/install ISO, I found that it actually seems not to be
workable as it stands.
I think I have found some limitations of the current sysinstall which
currently make it currently difficult to convert a working FreeBSD ISO
to an installable or live-disk flash image. Booting the kernel is
easy. Getting the rest of the way is harder.
Background: AFAICT the release ISOs don't currently mount the media
they were booted from (da0a in this case.) Instead they load
boot/mfsroot.gz (compressed memory image) as the root fs, which is fine
and makes good sense, but they don't then mount the boot media anywhere
under it. (My guess is that this was probably originally done to
support the floppy boot case.)
So how can you direct it to install from the USB media?
1) If you try to select media via the menu options, you can't select
USB specifically, nor specify an arbitrary device as the source
(/dev/da0a in this case), so you can't get the booted medium mounted to
install from, so you can't get the distributions accessible, so install
doesn't work. Picking CD as the media seems to mean specifically an
cd or acd device.
3) "Aha!" you say, "No problem. If you're using a USB system, you
can instead choose install from filesystem." Good point, but the file
system on the USB flash is not mounted, and you can't mount it via the
menu.
4) "So, the LiveCD, then?" The LiveCD function in sysinstall seems to
also currently require the install/liveCD image to be on a cd or acd
device. With no such device, it won't mount anything and remains stuck
at the "Please insert a LiveCD or DVD" prompt until you cancel.
5) "The emergency holographic shell, then?" Yes, you can get into
the emergency holographic shell, with the very limited set of commands
from the mfsroot bin/sbin/stand. However, if you try using the
emergency holographic shell to mount da0a - as far as I can tell, you
can't do so, because there is no mount in mfsboot's stand, only
mount_nfs. (I'm guessing the "mount" operation for acd0 or cd0 is
coded into sysinstall?) The usual mount command of course exists on the
media, but it's on the LiveCD portion which isn't mounted at this
point...
As far as I could tell, from the state you're in after the system
boots, it's not possible to bootstrap up to where you can access the
contents of the flash drive. Perhaps I'm just not creative enough.
I'm looking for the simplest way to make this workable, so that one
could automatically generate a bootable flash drive image from a given
FreeBSD ISO. Would adding an /etc/fstab mount entry for da0a (inside a
modified version of mfsroot.gz) be honored after loading the root, to
get the install medium premounted for bootstrapping?
I'm attaching my hacked-up fbsd-installiso2img.sh in case anyone else
is interested in playing with it further.
-- Clifton
- cut here
#!/bin/sh
# fbsd-install-iso2img.sh
# Original version by Dario Freni 9/2006
# Enhancements by Clifton Royston 3/2009.
# License: Beerware
# You can set some variables here. Edit them to fit your needs.
# Set serial variable to 0 if you don't want serial console at all,
# 1 if you want comconsole and 2 if you want comconsole and vidconsole
serial=0
# Set nofstab=1 to not create any initial fstab on the USB drive;
# this makes the next two settings largely irrelevant.
nofstab=0
# Set rootperm=rw for root fs to mount r/w from the USB drive
# (Should be unnecessary.)
rootperm=ro
# Set USBLABEL here or with -L label to label the image file system,
# to help the loader find the root file system when booting;
# otherwise the USB must come up as da0 to finish loading successfully.
USBLABEL=
lbparams=
# Set dopause=1 here or with -p to pause and allow review or editing of
# the flash image before finalizing the image.
dopause=0
pause() {
echo "Press enter to continue"
read foo
}
set -u
if [ $# -ge 3 ]; then
flag=$1
if [ ${flag} = "-p"
Re: Performance with hundreds of nullfs mounts?
Ivan Voras wrote: I seem to remember hearing an anecdote somewhere that using hundreds (or thousands?) nullfs mounts for jails results in unreasonably bad file system access performance. Does somebody have this kind of setup / is it true? I'm using about several readonly nullfs mounts per jail: usr, bin sbin, lib, libexec, with ~20 jails per machine, and the speed is just fine, on 7.0-STABLE. - Andrew ___ 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"
Performance with hundreds of nullfs mounts?
hi, I seem to remember hearing an anecdote somewhere that using hundreds (or thousands?) nullfs mounts for jails results in unreasonably bad file system access performance. Does somebody have this kind of setup / is it true? ___ 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"
4 長期
5 � �� 給�� �!! 給 ��请件人��谢谢�� � 大家好�� � ���/票代�� �� �� ��票确认款�� � ��13928451175 � ���QQ��970378804 � �� 箱��yhsy111...@163.com 注���请件人��谢谢�� http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/guestbo ok 4 ��� [1]http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/gues tbook Yahoo!��� �� .���.�活��� [2]http://tw.fashion.yahoo.com/ � Yahoo! References 1. http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/guestbook 2. http://tw.fashion.yahoo.com/ ___ 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: SCHED_ULE + SMP Phenom freeze [SOLVED]
Just a quick success report - kern/120138 does indeed solve the Phenom X3 SCHED_ULE problem. Attached patch against recent -STABLE in case someone else runs into it in the near future: --- sys/kern/sched_ule.c.orig 2008-12-08 05:07:30.0 +0100 +++ sys/kern/sched_ule.c2009-03-11 00:09:43.0 +0100 @@ -1399,7 +1399,7 @@ * prevents excess thrashing on large machines and excess idle on * smaller machines. */ - steal_thresh = min(ffs(mp_ncpus) - 1, 4); + steal_thresh = min(fls(mp_ncpus) - 1, 4); affinity = SCHED_AFFINITY_DEFAULT; #endif } ___ 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: SCHED_ULE + SMP Phenom freeze
On Tue, Mar 10, 2009 at 11:37 PM, Timothy Brown wrote: > I had the same problem. I searched the FreeBSD problem report database and > came across this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120138 > > After manually applying the patch and recompiling the kernel, I am able to > boot with SCHED_ULE and SMP enabled. > > Cheers, > Tim Wow, thank you for this, going to apply in a moment (but I guess it's pretty obvious that this is the same issue and also explains the X3 mystery). Adding Jeff Roberson to cc: to remind about the issue, I think it wouldn't be a bad idea to get this committed eventually. m. ___ 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: SCHED_ULE + SMP Phenom freeze
Michal Varga wrote: > > Guys, I'd like to point out a still present (rather serious I guess) > problem with SCHED_ULE, possibly triggered when Phenom X3 CPUs are > used. > I had the same problem. I searched the FreeBSD problem report database and came across this: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120138 After manually applying the patch and recompiling the kernel, I am able to boot with SCHED_ULE and SMP enabled. Cheers, Tim -- View this message in context: http://www.nabble.com/SCHED_ULE-%2B-SMP-Phenom-freeze-tp22414759p22445089.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 09 March 2009 21:00:20 ian j hart wrote: > On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote: > > On Sun, Mar 08, 2009 at 05:05:12PM +, ian j hart wrote: > > > On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote: > > > > On Sat, Mar 07, 2009 at 05:17:57PM +, ian j hart wrote: > > > > > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: > > > > > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: > > > > > > > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: > > > > > > > > I found something interesting. I have another RTL8169SC > > > > > > > > that works perfectly fine without the patch. The hardware > > > > > > > > revision is 0x1800. After reading Linux driver > > > > > > > > (drivers/net/r8169c), I realised they use different masks > > > > > > > > for hardware revisions. With their logic, non-working chip > > > > > > > > seems to be 0x9800 (8110SCe) while working chip seems to > > > > > > > > be 0x1800 (8110SCd) with 0xfc80. FYI... > > > > > > > > > > > > > > Now armed with the information, I made it work without > > > > > > > reverting memory mapped I/O. :-) > > > > > > > > > > > > > > http://people.freebsd.org/~jkim/re/re.current2.diff > > > > > > > http://people.freebsd.org/~jkim/re/re.stable2.diff > > > > > > > > > > > > I like the patch. Since only RTL8169 family uses mask 0xfc80 > > > > > > it would be even better we can limit checking scope for RTL8169SC > > > > > > by comparing PCI device id. I don't know what other side effect > > > > > > would happen if the mask 0xfc80 would be used on 8101/8168 > > > > > > controllers. > > > > > > If the patch works on RTL8169SC would you commit the patch? > > > > > > I'd like to see multiple commits separated by each enhancements > > > > > > as the patch contains several fixes which are not directly > > > > > > related with the issue. > > > > > > > > > > Where are we on this? > > > > > > > > > > I have a headless firewall box which is not happy with 7.1-RELEASE. > > > > > I've upgraded to 7.1-STABLE as of yesterday and now I'm getting > > > > > 'PHY read failed' errors, although the network did come up, which > > > > > was an improvement. > > > > > > > > > > Is there a patch I can try? > > > > > > > > > > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname > > > > >=A D3RT LAN-G > > > > > > > > > > re0: port > > > > > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on > > > > > pci0 re0: Chip rev. 0x1800 > > > > > re0: MAC rev. 0x > > > > > re0: Ethernet address: 00:30:18:ae:1a:1b > > > > > re0: [FILTER] > > > > > re1: port > > > > > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on > > > > > pci0 re1: Chip rev. 0x1800 > > > > > re1: MAC rev. 0x > > > > > re1: Ethernet address: 00:30:18:ae:1a:1c > > > > > re1: [FILTER] > > > > > re2: port > > > > > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on > > > > > pci0 re2: Chip rev. 0x1800 > > > > > re2: MAC rev. 0x > > > > > re2: Ethernet address: 00:30:18:ae:1a:1d > > > > > re2: [FILTER] > > > > > > > > > > r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec > > > > > rev=0x10 hdr=0x00 r...@pci0:0:11:0:class=0x02 > > > > > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:12:0: > > > > > class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 > > > > > hdr=0x00 > > > > > > > > Have you tried re(4) in HEAD? > > > > I had one report that re(4) in HEAD still does not fix the issue so > > > > I posted a possible workaround for that. Unfortunately he didn't > > > > report back so I don't know whether it was right workaround or not. > > > > If re(4) in HEAD does not fix the issue, would you try attached > > > > patch and let me know how it goes? > > > > > > Firstly IANAKH, my expertise in this area stops after "make kernel". > > > > > > I updated > > > > > > /usr/src/sys/dev/re/if_re.c > > > /usr/src/sys/pci/if_rlreg.h > > > > > > to HEAD > > > > And after updating to HEAD did you apply my patch? > > > > > I still get "PHY read failed" with and without the patch. > > > > That's odd. Another user who has the same controller reports the > > fix fixed the issue. I also committed the patch to HEAD so would > > you give it spin again (without applying any patches)? > > Clarification: > Updated the two files listed to HEAD > build/install/reboot > Still getting PHY read failed > Patch file > build/install/reboot > Still getting PHY read failed > > If HEAD is the now same as the patched version I can't see how this will be > any different, but I'll try it tomorrow. Patched version was the same, excepting the cardbus removal, so it's no surprise it's still broken. Still on cvs here. /usr/src/sys/dev/re/if_re.c rev 1.155 /usr/src/sys/pci/if_rlreg.h rev 1.95 -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinf
Re: cd ripping to flac
On Sat, Mar 07, 2009 at 08:12:28AM +0100, Zoran Kolic wrote: > Howdy! > I'd like to rip my cd-s to flac files using some > command line app, like cdda2wav or cdparanoia. > Using pipe to flac utility would be nice and the > way I'd take. What program acts in that matter? What does this have to do with FreeBSD-stable? This question is better asked on freebsd-questions. > Since cdda2wav is in the base, I suppose people > use it regurarly. Something like: What do you mean by "base"? It is a port and not in the base system. -- Rick C. Petty ___ 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: computer with USB keyboard hangs in loader boot prompt after a time
Sergey Matveychuk wrote: Hi. I have a machine with Intel DX58SO X58 mother board (no ps/2 ports). I've installed FreeBSD 7.1 on it without any problem and it works fine. Till I need boot from another device. I press 6 in boot menu, get loader prompt and the computer hangs after a time. Quite random time. From second to tens seconds. I thought it just keyboard froze, but once the computer started beeping, so it looks like a memory corruption or something like that. As kib@ has told me, it was fixed with r189017 | jhb | 2009-02-25, and was MFCed with r189307 | jhb | 2009-03-03. Yeap, it works in STABLE now. -- Dixi. Sem. ___ 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"
computer with USB keyboard hangs in loader boot prompt after a time
Hi. I have a machine with Intel DX58SO X58 mother board (no ps/2 ports). I've installed FreeBSD 7.1 on it without any problem and it works fine. Till I need boot from another device. I press 6 in boot menu, get loader prompt and the computer hangs after a time. Quite random time. From second to tens seconds. I thought it just keyboard froze, but once the computer started beeping, so it looks like a memory corruption or something like that. -- Dixi. Sem. ___ 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"
ZFS root file system fun, flash USB, swap
Hello, I have a couple of questions, I'm using ZFS on FreeBSD 7.1/amd64. To avoid issues with sharing the disks with ZFS and UFS, I am using a USB pendrive on which I copy the /boot directory. My first problem is: the presence of the /boot/zfs/zpool.cache file is critical. Without it the kernel won't recognise the pool, so it stalls on boot. Is it possible to avoid it? Please note that I'm not using any disk partitioning scheme, I'm creating the pools using the complete disk. / dev/da0, /dev/da1. Somewhere I've read about GEOM provider and a ZFS improvement. Should I partition the disks in a given way so that ZFS would recognise the device? My goal is to have a box of configuration independent boot flash pendrives, with a pretty much generic kernel for different Dell models. But having the pendrives tied to particular machines would be a pain in the ass. As all the Dell machines are not the same, I need generic kernels with support for a pool created over a "mfi" raid5, or using individual disks, etc. Second question. Ivan Voras mentions in his wiki that swap on FreeBSD 7.1 over ZFS doesn't work. The post is from 2007. Is it still _not_ working? It seems that documentation over this issue is very sparse. Regarding the method to create the root filesystem, etc, what I'm doing is: zpool create pool/root zpool create pool/root/usr zpool create pool/root/var zpool create pool/home zpool create pool/whatever From a minimal FreeBSD installed on the flash, tar -c --exclude "./pool/" -f - | ( cd /pool/root && tar xpf -) #with that I have the system files in their proper place I edit the fstab in pool/root/etc so that /, /usr and /var point to pool/root, pool/root/usr and pool/root/var zpool set mountpoint=legacy pool/root For the rest of the datasets I set the proper mountpoints, and boot from the flash with a loader.conf instructing the kernel to get the root file system from "zfs:pool/root". It's quite simple, actually. Borja. ___ 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: impossible packet length ...
> > bce(4) is broken in stable, your best option is to revert to the > > driver in releng 7.1. > > Is anybody working on fixing bce(4) in stable? As far as > I can see in the repository, nothing happened recently. > The last commit in releng 7 was in December last year. I am slightly surprised by all of this, as I have a lot of machines with bce inerfaces, and they all work properly in STABLE. I realise that everyones situation is different, but I wouldnt say it's entirely broken. Certainly they work well enough on HP servers. I wouldnt be too afraid of deploying on this hardware. -pete. ___ 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: impossible packet length ...
Kostik Belousov wrote (on 2009-02-08):
> Danny Braniss wrote:
> > going through the logs, after it happened again, I got a glimps of this:
> >
> > Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o
> > leading ethernet header (len 0 pkt len 0)
> > Feb 6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not
> > responding, timed out
> > ...
> > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value
> > for
> > /defaults in hesiod.local
> > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in
> > "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig#^ZM-^KoM- abase"
> > Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length
> > (2068989523) from nfs server sunfire:/dist
> >
> > which seems to point fingers at bce...
>
> bce(4) is broken in stable, your best option is to revert to the
> driver in releng 7.1.
Is anybody working on fixing bce(4) in stable? As far as
I can see in the repository, nothing happened recently.
The last commit in releng 7 was in December last year.
Otherwise, I suggest to revert the source to the same
version as in releng 7.1. Unfortunately, bce(4) hardware
is not that uncommon; I have it in several dozen machines
at customers. Having a known broken driver in -stable
for several months is bad.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"C++ is to C as Lung Cancer is to Lung."
-- Thomas Funke
___
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"
