Problem installing 11-stable on a Dell 5510, UEFI boot
Hello, I have a nice new Dell Precision 5510 laptop that I ordered preloaded with Ubuntu 14.10, and I'd *really* like to have FreeBSD on it instead. I've put the memstick image on a 2GB USB stick per the instructions on freebsd.org, but when I bring up the boot menu on the 5510 the USB drive isn't offered as a boot device. I've disabled Secure Boot & I made sure that the 5510 is allowed to boot from a USB device. I then decided to build my own image, following the instructions on the wiki: gpart create -s gpt da0 gpart add -t efi -s 800K da0 gpart add -t freebsd-ufs da0 dd if=/boot/boot1.efifat of=/dev/da0p1 newfs -U -L FreeBSD /dev/da0p2 Followed by: mount /dev/da0p2 /mnt make DESTDIR=/mnt installkernel installworld distribution echo "/dev/da0p2 / ufs rw 1 1" >> /mnt/etc/fstab umount /mnt It took a while to install and apparently worked fine, with no errors, but it still didn't show up in the boot menu. I had created an Ubuntu recovery image when I first fired up the 5510 and wrote it to a USB drive, and it shows up in the boot menu. Just for fun I downloaded a Linux Mint 18 XFCE installation ISO that I copied to the USB drive using the same method I used for the FreeBSD memstick image. It shows up on the boot menu & I verified that I can boot it. I'll run Mint with XFCE if I have to, but I'd really prefer FreeBSD. Can anyone offer suggestions as to what I should try next? Thanks! -- Richard Kuhns Wintek Corporation 427 N 6th Street Lafayette, IN 47901-2211 Main: 765-742-8428 Direct: 765-269-8541 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Virtualbox on my new Dell 7810
Hi all, I'm having another issue with my new desktop machine, this time with Virtualbox. I originally sent this to freebsd-emulation a few days ago, but I haven't had any response. I'm hoping someone here can help me. My machine is running FreeBSD 10.2-PRERELEASE #2 r284595 with a GENERIC kernel. I built & installed virtualbox-ose-4.3.28 (and kmod, of course) from ports. /etc/make.conf contains NO_LPR=yes NO_PROFILE= true CUPS_OVERWRITE_BASE=yes OPTIONS_SET= OPTIMIZED_CFLAGS OPTIONS_UNSET= NLS DEFAULT_VERSIONS=python=2.7 python2=2.7 gcc=4.9 bdb=5 perl=5.22 At boot, I now see the following: vboxdrv: fAsync=1 offMin=0x3ae80 offMax=0x3ae80 supdrvGipCreate: omni timer not supported, falling back to synchronous mode I've never seen the supdrvGipCreate message before. I first moved a 32 bit Windows 7 VM from my old desktop which was running a FreeBSD-stable a week or 2 old (literally; I took the drive out of the old machine). The first time I tried to boot the VM it took about 7 minutes. The CPU I allocated to the VM stayed at 100%. After some googling, I turned off hyperthreading in the 7810's BIOS. The VM now boots in a reasonable time and is almost usable. It'll be ok for 2 or 3 seconds, then almost freeze up for a little while (so far always less than a minute), and then be ok again for a few seconds. When it 'freezes up' its CPU is at 100%. As a test I started installing a 64 bit Windows 8.1 VM. It behaves exactly the same way. Does anyone have any ideas or suggestions? I'm hoping there's a BIOS setting I can tweak to make this work. Thanks in advance! -- Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Getting going with a new Dell 7810
On 06/17/15 11:43, Adam McDougall wrote: > On 06/16/2015 12:55, Richard Kuhns wrote: >> Greetings all, >> >> I've just received a new Dell Precision 7810. I've installed FreeBSD >> 10.1 (UEFI boot), checked out sources, built world & kernel and am now >> running r284449. So far, so good. >> >> The problem is Xorg. I'm running the latest Xorg in ports; I just did a >> 'make install clean' in /usr/ports/x11/xorg with no errors. >> >> The display card is a FirePro W4100. lspci shows: >> >> 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. >> [AMD/ATI] Cape Verde GL [FirePro W4100] >> > > If it is brand new, it is probably not supported and probably won't be > for a while. Please see https://wiki.freebsd.org/Graphics for a list of > devices which does include your Radeon HD 4670. That's what I was afraid of. I was hoping that the message that it was using syscons when my machine was using vt had something to do with it, but based on a couple of other messages that isn't the case. Thanks! -- Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Getting going with a new Dell 7810
On 06/16/15 15:58, John Nielsen wrote: > On Jun 16, 2015, at 12:39 PM, Ronald Klop wrote: > >> What does 'sysctl kern.vty' say? If it is not 'vt', you need the following >> stuff. >> >> /boot/loader.conf should contain >> kern.vty="vt" >> >> And /etc/rc.conf >> kld_list="radeonkms" >> >> Or something similar. >> >> FreeBSD is in the transition of old-style syscons- and vt-terminal. The last >> one has support for modern KMS graphics, but is not the default on 10 yet. > > With UEFI boot it will be using vt but with the efifb driver by default. > Hopefully loading the radeon KMS driver (as Ronald suggests above) will let > it take over. Try it with just a “kldload radeonkms” before adding it to > rc.conf, just in case something gets wedged.. As you said, it is using vt. Unfortunately loading radeonkms didn't help. It actually seems to be a regression; the only RADEON line /var/log/Xorg.0.log now is the one that lists all the supported chipsets. Immediately after that line it ends with [ 4005.835] (II) VESA: driver for VESA chipsets: vesa [ 4005.835] (++) Using config file: "/home/rjk/xorg.conf.new" [ 4005.836] (==) ServerLayout "X.org Configured" [ 4005.836] (**) |-->Screen "Screen0" (0) [ 4005.836] (**) | |-->Monitor "Monitor0" [ 4005.836] (**) | |-->Device "Card0" [ 4005.836] (**) |-->Screen "Screen1" (1) [ 4005.836] (**) | |-->Monitor "Monitor1" [ 4005.836] (**) | |-->Device "Card1" [ 4005.836] (**) |-->Input Device "Mouse0" [ 4005.836] (**) |-->Input Device "Keyboard0" [ 4005.836] (==) Automatically adding devices [ 4005.836] (==) Automatically enabling devices [ 4005.836] (==) Not automatically adding GPU devices [ 4005.836] (**) FontPath set to: /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/, /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/ [ 4005.836] (**) ModulePath set to "/usr/local/lib/xorg/modules" [ 4005.836] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 4005.836] (WW) Disabling Mouse0 [ 4005.836] (WW) Disabling Keyboard0 [ 4005.836] (II) [KMS] Kernel modesetting enabled. [ 4005.836] (WW) Falling back to old probe method for vesa [ 4005.836] Number of created screens does not match number of detected devices. Configuration failed. [ 4005.836] (EE) Server terminated with error (2). Closing log file. I noticed in the previous log that it said >>> [ 1292.463] (--) Using syscons driver with X support (version 2.0) which made me think I had something set up incorrectly, since it's using vt, not syscons. >> On Tue, 16 Jun 2015 18:55:10 +0200, Richard Kuhns wrote: >> >>> Greetings all, >>> >>> I've just received a new Dell Precision 7810. I've installed FreeBSD >>> 10.1 (UEFI boot), checked out sources, built world & kernel and am now >>> running r284449. So far, so good. >>> >>> The problem is Xorg. I'm running the latest Xorg in ports; I just did a >>> 'make install clean' in /usr/ports/x11/xorg with no errors. >>> >>> The display card is a FirePro W4100. lspci shows: >>> >>> 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. >>> [AMD/ATI] Cape Verde GL [FirePro W4100] >>> >>> It has 4 DisplayPorts, and I have 2 monitors plugged in. If I run 'Xorg >>> -configure' it says >>> >>> Number of created screens does not match number of detected devices. >>> Configuration failed. >>> >>> Looking through /var/log/Xorg.0.log it appears that the X server is >>> trying to use the RADEON driver, but ends with: >>> >>> = >>> [ 1292.463] (--) Using syscons driver with X support (version 2.0) >>> [ 1292.463] (--) using VT number 9 >>> >>> [ 1292.485] (II) [KMS] Kernel modesetting enabled. >>> [ 1292.485] (WW) Falling back to old probe method for vesa >>> [ 1292.485] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card >>> support >>> [ 1292.485] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 >>> [ 1292.485] (II) RADEON(0): Pixel depth = 24 bits sto
Getting going with a new Dell 7810
Greetings all, I've just received a new Dell Precision 7810. I've installed FreeBSD 10.1 (UEFI boot), checked out sources, built world & kernel and am now running r284449. So far, so good. The problem is Xorg. I'm running the latest Xorg in ports; I just did a 'make install clean' in /usr/ports/x11/xorg with no errors. The display card is a FirePro W4100. lspci shows: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100] It has 4 DisplayPorts, and I have 2 monitors plugged in. If I run 'Xorg -configure' it says Number of created screens does not match number of detected devices. Configuration failed. Looking through /var/log/Xorg.0.log it appears that the X server is trying to use the RADEON driver, but ends with: = [ 1292.463] (--) Using syscons driver with X support (version 2.0) [ 1292.463] (--) using VT number 9 [ 1292.485] (II) [KMS] Kernel modesetting enabled. [ 1292.485] (WW) Falling back to old probe method for vesa [ 1292.485] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1292.485] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 1292.485] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 1292.485] (==) RADEON(0): Default visual is TrueColor [ 1292.485] (==) RADEON(0): RGB weight 888 [ 1292.485] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 1292.485] (--) RADEON(0): Chipset: "VERDE" (ChipID = 0x682c) [ 1292.579] (EE) RADEON(0): [drm] Failed to open DRM device for pci::03:00.0: No such file or directory [ 1292.579] (EE) RADEON(0): Kernel modesetting setup failed [ 1292.579] (II) UnloadModule: "radeon" [ 1292.579] (EE) Screen(s) found, but none have a usable configuration. [ 1292.579] (EE) Fatal server error: [ 1292.579] (EE) no screens found(EE) [ 1292.580] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1292.580] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 1292.580] (EE) [ 1292.580] (EE) Server terminated with error (1). Closing log file. Should I be able to use this video card? I've done some googling, and apparently at least some Linux people are using it. It's not a huge deal if it doesn't work; I can install a Radeon HD 4670 that I know works. If I've mis-configured something, though, I'd like to fix it. Thanks for any comments! -- Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Problem building world (amd64) this morning
On 04/10/15 16:42, Dimitry Andric wrote: > On 10 Apr 2015, at 21:32, Michael Grimm wrote: >> >> Dimitry Andric wrote: >> >>> On 10 Apr 2015, at 20:55, Michael Grimm wrote: >> >>>> I can confirm that. r281288 compiles without failing, r281289 fails. >>> >>> I've tried all possible ways of reproducing this problem, but it always >>> works for me. Can somebody who experiences the problem please do a >>> clean build using script(1), and post the full build log somewhere? >>> Preferably a make buildworld without -j, so commands are not >>> interspersed. >> >> Compilation at r281289 is on its way. I'll send you a link after completion. > > Thanks, but you can stop that compilation now. :) I finally managed to > reproduce the problem, and it turns out I also had to MFC r272814 and > r272815, which I have done in r281382. That should really fix it > properly... Sorry for the breakage. > > -Dimitry > Checking back in after being offline for a couple of days, I find it's fixed :-) Many thanks! -- Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Sanity Check on Mac Mini
On 03/07/13 17:18, Doug Hardie wrote: > > On 7 March 2013, at 11:57, Kevin Oberman wrote: > >> On Thu, Mar 7, 2013 at 11:10 AM, Doug Hardie wrote: >> >> On 7 March 2013, at 06:42, Richard Kuhns wrote: >> >>> On 03/07/13 01:59, Doug Hardie wrote: >>>> I have a new Mac Mini and have encountered the same problem reported last >>>> year by Richard Kuhns. YongHyeon PYUN provided some patches to the kernel >>>> that resolved the problem. However, without an internet connection its a >>>> bit tricky to get them into the system. Here is the approach I believe >>>> will work, but wanted to check first before I really mess things up. >>>> >>>> 1. Downloaded from current today via svnweb.freebsd.org: >>>> sys/dev/bge/if_bgereg.h >>>> sys/dev/bge/if_bge.c >>>> sys/dev/mii/brgphy.c >>>> >>>>I believe the patches are incorporated in today's versions. The >>>> comments indicate such. Thus I don't need to apply the original supplied >>>> patch. >>>> >>>> 2. Put those on a flash drive. >>>> >>>> 3. Install 9.1 release from flash drive onto the Mini disk. Have to >>>> include the system source. >>>> >>>> 4. Copy the files from 1 above from flash over the files on the disk. >>>> >>>> 5. Rebuild the kernel and install it. >>>> >>>> Thanks, >>>> >>>> -- Doug >>> >>> That's worked for me 3 times now. >> >> Thanks. Well, I got 9.1 Release installed, but it won't boot from the >> internal disk. It doesn't see the disk as bootable. I installed using the >> entire disk for FreeBSD. I used the i386 release. Perhaps I need to switch >> to the amd64 release? >> >> I would generally recommend using the amd64 release, but it may not get your >> system to boot. >> >> How is your disk partitioned? GPT? Some BIOSes are broken and assume that a >> GPT formatted disk is UEFI and will not recognize them if they lack the UEFI >> boot partition. UEFI boot is a current project that seems likely to reach >> head in the fairly near future, but it's not possible now. > > No idea what the default partitioning is for BSDInstall. However the Mini is > only EFI or UFEI with some fallbacks although the comments I find in the web > indicate that different models have different fallbacks. > > One comment indicates that an older unit will boot if its MBR partitioning. > I don't know if the new installer supports that or not. > >> >> You may be able to tweak your BIOS to get it to work or you may have to >> install using the traditional partitioning system. The installer defaults to >> GPT, but can create either. >> >> I have such a system (ThinkPad T520) and I have two disks... one that came >> with the system and containing Windows, and my GPT formatted FreeBSD disk. I >> wrote a FreeBSD BootEasy boot into the MBR of the Windows disk and it CAN >> boot the GPT disk just fine. Not ideal for most, but it works well for me > > Based on a comment I say, waiting till the empty folder icon appears and then > plugging in the install memstick causes the mini to boot from disk. That > just downright weird, but it works. I could live with that, but this is an > unattended server and would experience some down time if I am not there when > there is a power failure. > > I just found some "instructions" for using MBR with bsdinstall, but given > there is an effort to create a UEFI boot which I suspect would expect to find > the GPT boot partition, perhaps I should just go with the memstick approach? > > -- Doug > FWIW, here are the brief notes I made for what has been working for me for the last year or so; most recently with a new Mini purchased about 2 weeks ago. I'm using the entire drive for FreeBSD. Hit Option key while booting, then select 'Windows' USB image. Now trying GPT; looks fine, but will only boot with USB stick in place. If it's not there, just get a folder with a '?' when starting up. Using MBR; boots ok without USB stick. It just takes about 30 seconds before it actually boots. Select YES when asked about GMT. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Sanity Check on Mac Mini
On 03/07/13 01:59, Doug Hardie wrote: > I have a new Mac Mini and have encountered the same problem reported last > year by Richard Kuhns. YongHyeon PYUN provided some patches to the kernel > that resolved the problem. However, without an internet connection its a bit > tricky to get them into the system. Here is the approach I believe will > work, but wanted to check first before I really mess things up. > > 1. Downloaded from current today via svnweb.freebsd.org: > sys/dev/bge/if_bgereg.h > sys/dev/bge/if_bge.c > sys/dev/mii/brgphy.c > > I believe the patches are incorporated in today's versions. The comments > indicate such. Thus I don't need to apply the original supplied patch. > > 2. Put those on a flash drive. > > 3. Install 9.1 release from flash drive onto the Mini disk. Have to include > the system source. > > 4. Copy the files from 1 above from flash over the files on the disk. > > 5. Rebuild the kernel and install it. > > Thanks, > > -- Doug That's worked for me 3 times now. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/28/12 19:08, YongHyeon PYUN wrote: > On Wed, Nov 28, 2012 at 10:12:05AM -0500, Richard Kuhns wrote: >> On 11/27/12 19:19, YongHyeon PYUN wrote: >>> On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: >>>> On 11/27/12 00:24, YongHyeon PYUN wrote: >>>>> On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: >>>>>> On 11/21/12 21:08, YongHyeon PYUN wrote: >>>>>>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >>>>>>>> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>>>>>>>> On 11/20/12 03:52, YongHyeon PYUN wrote: >>>>>>>>>> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Over the last month or so I've installed FreeBSD 9 (-stable) on >>>>>>>>>>> several Mac >>>>>>>>>>> Minis via the memstick image; they seem to be pretty good little >>>>>>>>>>> boxes for >>>>>>>>>>> things like offsite secondary nameservers, for example, and they're >>>>>>>>>>> easily >>>>>>>>>>> replaced in case of problems. >>>>>>>>>>> >>>>>>>>>>> However, the newest minis have slightly different hardware, and >>>>>>>>>>> FreeBSD can't >>>>>>>>>>> find the built-in NIC. pciconf -lv on the new mini shows it as >>>>>>>>>>> >>>>>>>>>>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 >>>>>>>>>>> chip=0x168614e4 rev=0x01 >>>>>>>>>> >>>>>>>>>> It seems this controller is BCM57766. >>>>>>>>>> >>>>>>>>>>> hdr=0x00 >>>>>>>>>>> vendor = 'Broadcom Corporation' >>>>>>>>>>> class = network >>>>>>>>>>> subclass = ethernet >>>>>>>>>>> >>>>>>>>>>> The previous edition mini (that works) reports >>>>>>>>>>> >>>>>>>>>>> bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 >>>>>>>>>>> rev=0x10 hdr=0x00 >>>>>>>>>>> vendor = 'Broadcom Corporation' >>>>>>>>>>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>>>>>>>>>> class = network >>>>>>>>>>> subclass = ethernet >>>>>>>>>>> >>>>>>>>>>> Is there a chance that adding the new card/chip info to the current >>>>>>>>>>> driver would >>>>>>>>>>> allow it to work? I'll be happy to test and report back. I'm afraid >>>>>>>>>>> I'm not >>>>>>>>>>> familiar enough with hardware at that level to figure out the patch >>>>>>>>>>> myself. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Try attached patch and let me know whether the patch works or not. >>>>>>>>>> If the patch works please share dmesg output(bge(4) and brgphy(4) >>>>>>>>>> output only). >>>>>>>>>> Note, the patch was generated against CURRENT. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'm afraid it didn't help. I ended up grabbing if_bge.c and >>>>>>>>> if_bgereg.h from >>>>>>>> >>>>>>>> I guess you also need to copy brgphy.c from HEAD to >>>>>>>> /usr/src/sys/dev/mii directory. >>>>>>>> >>>>>>>>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there >>>>>>>>> were no >>>>>>>>> errors during the build, but still no NIC. >>>>>>>> >>>>>>>> Does it mean you're not seeing
Re: bge on the new Mac Mini
On 11/27/12 19:19, YongHyeon PYUN wrote: > On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: >> On 11/27/12 00:24, YongHyeon PYUN wrote: >>> On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: >>>> On 11/21/12 21:08, YongHyeon PYUN wrote: >>>>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >>>>>> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>>>>>> On 11/20/12 03:52, YongHyeon PYUN wrote: >>>>>>>> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Over the last month or so I've installed FreeBSD 9 (-stable) on >>>>>>>>> several Mac >>>>>>>>> Minis via the memstick image; they seem to be pretty good little >>>>>>>>> boxes for >>>>>>>>> things like offsite secondary nameservers, for example, and they're >>>>>>>>> easily >>>>>>>>> replaced in case of problems. >>>>>>>>> >>>>>>>>> However, the newest minis have slightly different hardware, and >>>>>>>>> FreeBSD can't >>>>>>>>> find the built-in NIC. pciconf -lv on the new mini shows it as >>>>>>>>> >>>>>>>>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 >>>>>>>>> chip=0x168614e4 rev=0x01 >>>>>>>> >>>>>>>> It seems this controller is BCM57766. >>>>>>>> >>>>>>>>> hdr=0x00 >>>>>>>>> vendor = 'Broadcom Corporation' >>>>>>>>> class = network >>>>>>>>> subclass = ethernet >>>>>>>>> >>>>>>>>> The previous edition mini (that works) reports >>>>>>>>> >>>>>>>>> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 >>>>>>>>> rev=0x10 hdr=0x00 >>>>>>>>> vendor = 'Broadcom Corporation' >>>>>>>>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>>>>>>>> class = network >>>>>>>>> subclass = ethernet >>>>>>>>> >>>>>>>>> Is there a chance that adding the new card/chip info to the current >>>>>>>>> driver would >>>>>>>>> allow it to work? I'll be happy to test and report back. I'm afraid >>>>>>>>> I'm not >>>>>>>>> familiar enough with hardware at that level to figure out the patch >>>>>>>>> myself. >>>>>>>>> >>>>>>>> >>>>>>>> Try attached patch and let me know whether the patch works or not. >>>>>>>> If the patch works please share dmesg output(bge(4) and brgphy(4) >>>>>>>> output only). >>>>>>>> Note, the patch was generated against CURRENT. >>>>>>>> >>>>>>> >>>>>>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h >>>>>>> from >>>>>> >>>>>> I guess you also need to copy brgphy.c from HEAD to >>>>>> /usr/src/sys/dev/mii directory. >>>>>> >>>>>>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there >>>>>>> were no >>>>>>> errors during the build, but still no NIC. >>>>>> >>>>>> Does it mean you're not seeing bge0 interface? Or you can't pass >>>>>> any traffic via bge0? >>>>> >>>>> Oops, it seems I've not included your device ID in the diff. >>>>> Try attach one instead. Make sure you use brgphy.c from HEAD. >>>>> >>>> >>>> There's progress! With your latest patch using brgphy.c, if_bge.c, and >>>> if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the >>>> moment I try to configure it the box locks up completely; it won't even >>>> toggle >>>>
Re: bge on the new Mac Mini
On 11/27/12 00:24, YongHyeon PYUN wrote: > On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: >> On 11/21/12 21:08, YongHyeon PYUN wrote: >>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >>>> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>>>> On 11/20/12 03:52, YongHyeon PYUN wrote: >>>>>> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Over the last month or so I've installed FreeBSD 9 (-stable) on several >>>>>>> Mac >>>>>>> Minis via the memstick image; they seem to be pretty good little boxes >>>>>>> for >>>>>>> things like offsite secondary nameservers, for example, and they're >>>>>>> easily >>>>>>> replaced in case of problems. >>>>>>> >>>>>>> However, the newest minis have slightly different hardware, and FreeBSD >>>>>>> can't >>>>>>> find the built-in NIC. pciconf -lv on the new mini shows it as >>>>>>> >>>>>>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 >>>>>>> rev=0x01 >>>>>> >>>>>> It seems this controller is BCM57766. >>>>>> >>>>>>> hdr=0x00 >>>>>>> vendor = 'Broadcom Corporation' >>>>>>> class = network >>>>>>> subclass = ethernet >>>>>>> >>>>>>> The previous edition mini (that works) reports >>>>>>> >>>>>>> bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 >>>>>>> rev=0x10 hdr=0x00 >>>>>>> vendor = 'Broadcom Corporation' >>>>>>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>>>>>> class = network >>>>>>> subclass = ethernet >>>>>>> >>>>>>> Is there a chance that adding the new card/chip info to the current >>>>>>> driver would >>>>>>> allow it to work? I'll be happy to test and report back. I'm afraid I'm >>>>>>> not >>>>>>> familiar enough with hardware at that level to figure out the patch >>>>>>> myself. >>>>>>> >>>>>> >>>>>> Try attached patch and let me know whether the patch works or not. >>>>>> If the patch works please share dmesg output(bge(4) and brgphy(4) >>>>>> output only). >>>>>> Note, the patch was generated against CURRENT. >>>>>> >>>>> >>>>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h >>>>> from >>>> >>>> I guess you also need to copy brgphy.c from HEAD to >>>> /usr/src/sys/dev/mii directory. >>>> >>>>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were >>>>> no >>>>> errors during the build, but still no NIC. >>>> >>>> Does it mean you're not seeing bge0 interface? Or you can't pass >>>> any traffic via bge0? >>> >>> Oops, it seems I've not included your device ID in the diff. >>> Try attach one instead. Make sure you use brgphy.c from HEAD. >>> >> >> There's progress! With your latest patch using brgphy.c, if_bge.c, and >> if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the >> moment I try to configure it the box locks up completely; it won't even >> toggle >> the caps lock LED. >> >> Booting single user and running ifconfig shows: >> >> bge0: flags=8802 metric 0 mtu 1500 >> options=8009b >> ether a8:20:66:11:3b:d6 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> I did a verbose boot; here's the part that seems to be relevant to bge0: >> >> bge0: >> mem >> 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 >> bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > ^ > > All these information are garbage which indicates a bug in the diff. > >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: OUI 0x001be9, model 0x0024, rev. 1 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> bge0: bpf attached >> bge0: Ethernet address: a8:20:66:11:3b:d6 >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 >> >> I greatly appreciate your efforts. I'm sorry for the delay getting back with >> you, but we had a busy Thanksgiving weekend. >> > > Try again with attached bge.57766.diff3. > Thanks for testing! > I don't think the patch actually got attached :-( -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/21/12 21:08, YongHyeon PYUN wrote: > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>> On 11/20/12 03:52, YongHyeon PYUN wrote: >>>> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>>>> Hi all, >>>>> >>>>> Over the last month or so I've installed FreeBSD 9 (-stable) on several >>>>> Mac >>>>> Minis via the memstick image; they seem to be pretty good little boxes for >>>>> things like offsite secondary nameservers, for example, and they're easily >>>>> replaced in case of problems. >>>>> >>>>> However, the newest minis have slightly different hardware, and FreeBSD >>>>> can't >>>>> find the built-in NIC. pciconf -lv on the new mini shows it as >>>>> >>>>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 >>>>> rev=0x01 >>>> >>>> It seems this controller is BCM57766. >>>> >>>>> hdr=0x00 >>>>> vendor = 'Broadcom Corporation' >>>>> class = network >>>>> subclass = ethernet >>>>> >>>>> The previous edition mini (that works) reports >>>>> >>>>> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 >>>>> hdr=0x00 >>>>> vendor = 'Broadcom Corporation' >>>>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>>>> class = network >>>>> subclass = ethernet >>>>> >>>>> Is there a chance that adding the new card/chip info to the current >>>>> driver would >>>>> allow it to work? I'll be happy to test and report back. I'm afraid I'm >>>>> not >>>>> familiar enough with hardware at that level to figure out the patch >>>>> myself. >>>>> >>>> >>>> Try attached patch and let me know whether the patch works or not. >>>> If the patch works please share dmesg output(bge(4) and brgphy(4) >>>> output only). >>>> Note, the patch was generated against CURRENT. >>>> >>> >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from >> >> I guess you also need to copy brgphy.c from HEAD to >> /usr/src/sys/dev/mii directory. >> >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no >>> errors during the build, but still no NIC. >> >> Does it mean you're not seeing bge0 interface? Or you can't pass >> any traffic via bge0? > > Oops, it seems I've not included your device ID in the diff. > Try attach one instead. Make sure you use brgphy.c from HEAD. > There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802 metric 0 mtu 1500 options=8009b ether a8:20:66:11:3b:d6 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Thank you! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/20/12 03:52, YongHyeon PYUN wrote: > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >> Hi all, >> >> Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac >> Minis via the memstick image; they seem to be pretty good little boxes for >> things like offsite secondary nameservers, for example, and they're easily >> replaced in case of problems. >> >> However, the newest minis have slightly different hardware, and FreeBSD can't >> find the built-in NIC. pciconf -lv on the new mini shows it as >> >> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 >> rev=0x01 > > It seems this controller is BCM57766. > >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> class = network >> subclass = ethernet >> >> The previous edition mini (that works) reports >> >> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >> class = network >> subclass = ethernet >> >> Is there a chance that adding the new card/chip info to the current driver >> would >> allow it to work? I'll be happy to test and report back. I'm afraid I'm not >> familiar enough with hardware at that level to figure out the patch myself. >> > > Try attached patch and let me know whether the patch works or not. > If the patch works please share dmesg output(bge(4) and brgphy(4) > output only). > Note, the patch was generated against CURRENT. > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Just to make sure you know, I've made no local modifications at all. This was a fresh install and I've touched nothing except for these 2 files. Thanks! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 12:09, Gary Palmer wrote: > On Fri, Nov 16, 2012 at 11:27:17AM -0500, Richard Kuhns wrote: >> On 11/16/12 11:20, Gary Palmer wrote: >>> On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: >>>> On 11/16/12 10:41, Alfred Perlstein wrote: >>>>> Often that is all that is needed. It's worth a shot and reporting back. >>>>> >>>>> Do you know how to update the table in the driver, rebuild/install >>>>> kernel and check? >>>>> >>>>> -Alfred >>>>> >>>> >>>> I'm afraid not. I grepped for the hex value reported on the one that works >>>> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. >>>> So I >>>> don't know what to add :-( >>>> >>>> I don't have any problem with rebuilding and installing a new kernel, >>>> though. >>> >>> 14e4 is the ID for Broadcom >>> 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip >>> >>> http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list >>> of the BCM PCI ID values >>> >>> There is a (frequently incomplete) database of user reported PCI values at >>> http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip >>> >>> Linux uses the tg3 driver for that chipset apparently, but I think thats >>> a general dumping ground for a lot of Broadcom products. Not sure what the >>> appropriate FreeBSD driver to add the ID code to would be. >>> >>> Regards, >>> >>> Gary >>> >> >> Sorry, I should have been more clear. I grepped for those values in >> /usr/src/sys/dev/bge/*, since that's the driver that's used on the older >> minis. >> I assume that's where the table is that Alfred mentioned; I just don't know >> what >> to add to it. >> > > The probe table appears to be bge_devs in if_bge.c. The values there are > #define'd in if_bgereg.h, but for a quick hack you just need to add the value > to the table > > Gary > Thanks, I found it. I also found that the reason I couldn't find it before was that I didn't tell grep to ignore case :-( -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 11:20, Gary Palmer wrote: > On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: >> On 11/16/12 10:41, Alfred Perlstein wrote: >>> Often that is all that is needed. It's worth a shot and reporting back. >>> >>> Do you know how to update the table in the driver, rebuild/install >>> kernel and check? >>> >>> -Alfred >>> >> >> I'm afraid not. I grepped for the hex value reported on the one that works >> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So >> I >> don't know what to add :-( >> >> I don't have any problem with rebuilding and installing a new kernel, though. > > 14e4 is the ID for Broadcom > 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip > > http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list > of the BCM PCI ID values > > There is a (frequently incomplete) database of user reported PCI values at > http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip > > Linux uses the tg3 driver for that chipset apparently, but I think thats > a general dumping ground for a lot of Broadcom products. Not sure what the > appropriate FreeBSD driver to add the ID code to would be. > > Regards, > > Gary > Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 10:41, Alfred Perlstein wrote: > Often that is all that is needed. It's worth a shot and reporting back. > > Do you know how to update the table in the driver, rebuild/install > kernel and check? > > -Alfred > I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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"
bge on the new Mac Mini
Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Thanks! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /misc/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /misc/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 -5 bytes available *** [boot2] Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** [all] Error code 1 Stop in /usr/src/sys/boot/i386. *** [all] Error code 1 Stop in /usr/src/sys/boot. *** [all] Error code 1 Stop in /usr/src/sys. *** [sys.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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"
csup not updating all files
Sorry to followup on my own post, but I figured out what was going on. It
appears to be a problem with csup.
I've been using csup to maintain 2 CVS Repositories, one at home and one at
work.
The last couple of times I've run csup there were lots of 'checksum mismatches',
so csup said it would download the entire file. I was watching it this morning
and saw it going through {/usr/src}/sys, usr.bin, and usr.sbin. It didn't,
however, actually download all of the files. When it said it was finished
(successfully!), the last file downloaded was in sys/netinet. This was on my
home system (amd64).
I tried on a machine a machine at work (i386) with the same results, except that
csup stopped downloading files much earlier. I restarted the csup; it picked up
where it left off (somewhere in sys/dev) complaining about checksum mismatches.
It then downloaded a fair number of files but still stopped before reaching
usr.bin. (Sorry I don't have hard numbers on how many files).
I installed cvsup. It picked up where csup had left off (also complaining about
checksums), but it updated everything and I've been able to buildworld and
buildkernel without any problems.
So my earlier problem was due to /usr/src/gnu being updated while
/usr/src/sys/sys wasn't :-( .
--
Richard Kuhns My Desk: 765-269-8541
Wintek Corporation Internet Support: 765-269-8503
427 N 6th Street STE C Consulting: 765-269-8504
Lafayette, IN 47901-2211 Accounting: 765-269-8502
___
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"
Problem building gdb with up-to-date sources
Hello, I just tried to run a buildworld for RELENG_8/amd64 after a fresh csup, and I'm getting the following error: /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c: In function 'fbsd_thread_get_name': /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:442: error: 'struct ptrace_lwpinfo' has no member named 'pl_tdname' I looked in /usr/src/sys/sys/ptrace.h, and 'pl_tdname' isn't there. Running 'cvs log' on ptrace.h, though, shows: revision 1.34 date: 2010/11/22 14:42:13; author: attilio; state: Exp; lines: +2 -0 SVN rev 215679 on 2010-11-22 14:42:13Z by attilio Add the ability for GDB to printout the thread name along with other thread specific informations. In order to do that, and in order to avoid KBI breakage with existing infrastructure the following semantic is implemented: - For live programs, a new member to the PT_LWPINFO is added (pl_tdname) ... Any suggestions? I didn't see anything in /usr/src/UPDATING. Thanks in advance! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: FreeBSD8.0 sound on Dell Optiplex 960
On 02/25/10 13:42, Richard Kuhns wrote: On 02/25/10 12:38, Tom Evans wrote: On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhns wrote: Hello, I'm hoping someone can give me some help getting audio working on this beast. I'm by no means an audiophile; I just like to listen to the occasional CD and/or online station while I work. None of the jacks on the back of the tower seem to do anything. In addition, when starting a Virtual Machine under VirtualBox, I get a popup saying: "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details, the Error ID is HostAudioNotResponding. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: (play) default pcm1: (play/rec) pcm2: (play/rec) Per the snd_hda manpage, I'm also attaching the hda-related output from a verbose boot. Any help would be greatly appreciated! Thanks, - Richart Your default device is currently the HDMI output on your graphics card. You probably want to play with sysctl snd.default_unit=1 (or 2) to set it to one of the analog outputs. One should be the front audio, the other one should be the back. Once you've got it sorted out, add to /etc/sysctl.conf to persist it. Cheers Tom OK, now I can get sound from both vlc and xmms as long as I plug the speakers into the headphone jack on the front of the tower, which is a major improvement! It doesn't make any difference which (non-zero) value I give to hw.snd.default_unit. VMs no longer complain at startup, but there's still no audio from them; there's also no sound from flash. I'm pretty sure that's what BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is 8 AM for me). Many thanks for your help! While I know it's generally bad form to follow up to myself, I've made some more progress and it might be useful to someone else. The problem with flash was apparently that I had to symlink /usr/compat/linux/lib/libssl.so.5 to the currently installed version, libssl.so.0.9.8g. Strange but true... At any rate, I now have sound from everything I did before except for VMs under Virtual Box. Once again, thanks, Tom, for your help. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: FreeBSD8.0 sound on Dell Optiplex 960
On 02/25/10 12:38, Tom Evans wrote: On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhns wrote: Hello, I'm hoping someone can give me some help getting audio working on this beast. I'm by no means an audiophile; I just like to listen to the occasional CD and/or online station while I work. None of the jacks on the back of the tower seem to do anything. In addition, when starting a Virtual Machine under VirtualBox, I get a popup saying: "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details, the Error ID is HostAudioNotResponding. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: (play) default pcm1: (play/rec) pcm2: (play/rec) Per the snd_hda manpage, I'm also attaching the hda-related output from a verbose boot. Any help would be greatly appreciated! Thanks, - Richart Your default device is currently the HDMI output on your graphics card. You probably want to play with sysctl snd.default_unit=1 (or 2) to set it to one of the analog outputs. One should be the front audio, the other one should be the back. Once you've got it sorted out, add to /etc/sysctl.conf to persist it. Cheers Tom OK, now I can get sound from both vlc and xmms as long as I plug the speakers into the headphone jack on the front of the tower, which is a major improvement! It doesn't make any difference which (non-zero) value I give to hw.snd.default_unit. VMs no longer complain at startup, but there's still no audio from them; there's also no sound from flash. I'm pretty sure that's what BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is 8 AM for me). Many thanks for your help! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: [kde-freebsd] problem hal - k3b ?
On Thursday 19 April 2007 12:12, Michael Nottebrock wrote: > On Wednesday, 18. April 2007, Beni wrote: > > Hi List, > > > > I think I have a problem with hal(d) and k3b (version 1.0 from ports) : > > my whole system freezes when starting up k3b. I get the splash screen and > > then it all stops and a ctrl-alt-del is the only way out. > > Other people have reported kernel panics. It looks to me like k3b's device > probing and hald's device probing at the same time manages to tickle a bug > in ata(4). > > Ref: > http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.html > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034486.html > > I'm afraid a true kernel hacker will have to inconvenince themselves with > running k3b and hal in order to have this one fixed. FWIW, I haven't seen > in happening on 5.5. > > > Cheers, FWIW: I've been running with a kernel from Jan 22 with no problem. I built and installed a new kernel/world today and can't run k3b as described above. I've since reverted to my old kernel and everything's fine again. - Rich -- Richard Kuhns Wintek Corporation E-mail: [EMAIL PROTECTED] 427 N 6th Street Tel: +1 (765) 742-8428 Lafayette, IN 47901-1126 Fax: +1 (765) 742-0646 United States of America ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gdm problem with kernel as of 2005-01-04
I just finished a buildworld/buildkernel/mergemaster on my Dell Inspiron 9300. Upon rebooting, I noticed that gdm seemed to start earlier in the boot process than it used to. When the login screen appeared, the mouse seemed to work fine, but nothing I typed appeared. Attempting to use C-A-F1 to switch to vty0 just beeped. C-A-Del worked to reboot the laptop. I booted single user, commented out gdm_enable="YES" in /etc/rc.conf, and rebooted -- everything was fine. I put the gdm_enable back and ran /usr/X11R6/etc/rc.d/gdm.sh start -- gdm started, fully functional. I rebooted again -- gdm ignored the keyboard. After several reboots, I've found that gdm seems to work fine as long as I don't have 'gdm_enable="YES"' in /etc/rc.conf when the machine boots. I've just finished upgrading gdm (using portmanager); still the same problem. If anyone has suggestions/wants me to try anything, just say so. Thanks! - Rich -- Richard Kuhns Wintek Corporation E-mail: [EMAIL PROTECTED] 427 N 6th Street Tel: +1 (765) 742-8428 Lafayette, IN 47901-1126 Fax: +1 (765) 742-0646 United States of America ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LEAP and iwi
Just wondering -- has anyone managed to successfully use LEAP with an Intel PRO/Wireless 2200? It works under XP, but I'd much prefer to stay with FreeBSD (6.0) as much as possible. Thanks... -- Richard Kuhns Wintek Corporation E-mail: [EMAIL PROTECTED] 427 N 6th Street Tel: +1 (765) 742-8428 Lafayette, IN 47901-1126 Fax: +1 (765) 742-0646 United States of America ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
