Re: mergemaster broken -- take 2
In article <496819f...@vintners.net> you write: > cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out > make buildworld |& tee /root/make-buildworld-090108.out > make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out You know about script(1) I take it? It makes keeping a log like this much easier. Ben ___ 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: mergemaster broken -- take 2
Mike Lempriere wrote: > Thanks everyone for the advice -- I got it working this time just fine. > Works much better when one follows the directions accurately instead of > by memory. W00t! :) -- This .signature sanitized for your protection ___ 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: 2 (very old) bugs?
Yannick Cadin wrote: > Hi everybody, > > Is someone can confirm me that there are 2 bugs never fixed: > > - first in the stat command. Only with the -x option. If you execute > stat -x on /tmp or /usr/bin/passwd parameters for example, the numeric > representation of mode is wrong. The "special" bits are always 0. No > suid-bit, no sticky bit! Our version of stat(1) is essentially an exact duplicate of the code from NetBSD. I imported this originally, but I have not not had time to merge changes for a while now. If anyone is interested in taking this on have a look at: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/ If you get stuck with something please ask for help on -hackers first. If you get a patch against HEAD I will be glad to take a look at it, and commit it if appropriate. hth, Doug -- This .signature sanitized for your protection ___ 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: mergemaster broken -- take 2
Thanks everyone for the advice -- I got it working this time just fine. Works much better when one follows the directions accurately instead of by memory -- the bottom line is that this time I remembered to jot down the commands before heading downtown to the machine rack room where there's no browser access... I started over and followed UPDATING: cd /usr/obj rm -R * cd /usr/src rm -R * cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out make buildworld |& tee /root/make-buildworld-090108.out make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out users ps ax | more shutdown -r now 4 (single user) fsck -p mount -u / mount -a cd /usr/src mergemaster -p make installworld |& tee /root/make-installworld-090108.out make delete-old (forgot to do tee redirect) mergemaster -i (did not do tee redirect) shutdown -r now Oliver Fromme wrote: Greg Byshenk wrote: > Andrei Kolu wrote: > > Mike Lempriere wrote: > > > Hi folks -- sorry to be a nag, but my main production system is barely > > > limping along on an old kernel with mismatched libraries. I have no > > > idea what else to do -- please help! > > > --- > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for > > > 6-stable to 7-stable. > > > No problems with cvsup, make buildworld, make installworld, make > > > buildkernel, mergemaster -p. > > > make installkernel, boot to single user. Then mergemaster -- blammo: As others have pointed out, the order is wrong, which caused the problem Mike is seeing. The correct order is listed in /usr/src/UPDATING. > The reasons for the other methods being wrong are (as I understand them): > > - You should build your new world before building your new kernel, as > it may be the case that some aspects of the new kernel build are > dependent upon aspects of the new world build. If you build your > new kernel before building your new world, you will be building > your new kernel against the old world. In particular, building the kernel uses the new toolchain (i.e. compiler, linker, make(1) binary and so on) that was built in /usr/obj during buildworld. That's why you have to do buildworld first, then "make kernel". > - You should install your new kernel before installing your new world, > as it can be the case that some aspects of the new world will not be > understood by your old kernel. A new kernel should always be > compatible with an old userland/world, but an old kernel may not > always be compatible with a new userland/world. That's correct. Note that your kernel config should include the appropriate "options COMPAT_*" lines if you update across a major version boundary, e.g. "options_COMPAT_FREEBSD6" when you update from 6.x to 7.x. The GENERIC kernel already has those. > > NOTE: I do not reboot my system until everything is updated. Why it is > > necessary to boot new kernel and then upgrade world is beyound me..YMMW > > - I suppose that it is not strictly necessary to reboot between > installing kernel and world, but I always do so. It _is_ necessary. If you don't reboot, you're still running the old kernel which might not be able to support new binaries and libraries that installworld will install on your system. For example, there may be new syscalls that the new binaries will try to use, but the old kernel doesn't know about them. It doesn't happen often, so you can get away without rebooting most of the time. But it's risky, especially when updating across major versions. So the recommendation is to always reboot after installing the new kernel and before performing the "installworld". It's also important that "installworld" is the last step (except for mergemaster), because this is the point of no return. As long as you still have the old userland (world), you can still boot the old kernel and everything is fine. You can start all over froms cratch, if necessary. But as soon as you have started "installworld", your system will not be able to work with the old kernel anymore. And remember: Always make a backup before you start to update. And verify that the backup works. Better safe than sorry. Best regards Oliver -- Mike Lempriere- Home: m...@vintners.net Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: mikel...@tmail.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: Big problems with 7.1 locking up :-(
At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: Big problems with 7.1 locking up :-(
At 1:58 AM + 1/9/09, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. So the last two days I have been round upgrading all our servers, knowing that I had run the system stably on identical hardware for some time. Since then I have starte seeing machines lock up. This always happens under heavy disc load. When I bring the machine back up then sometimes it fails to fsck due to a partialy truncated inode. The locksup appear to be disc related [...] One of my friends is also having trouble with lockups on two machines he had upgraded to 7.1. Also seems to be related to heavy disk I/O, although I'm not sure the symptoms are the same as what you report. Both machines had been running 7.0-release without trouble. On at least one of the systems, he's also working with (what I consider) very large file systems (over 2 TB). Both machines are using a 3ware controller with its RAID. I realize that isn't much to go on, but it suggests that there is some problem wider than just your (Pete's) usage. I think his situation is such that lockups like this are simply not acceptable, and the last I heard he was reverting back to 7.0-release. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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"
Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
>On Mon, Jan 05, 2009 at 11:36:54AM +0100, Barbara wrote: > >[...] > > > I've tried all the thing you've suggested with > > the same result. > > I've disabled "LAN Option ROM", but it seems that I don't have > > the other options you mentioned. > > I've downloaded and burned the 7.1-RELEASE dvd > > and tried to boot from it, but it hangs at the same point. > > Finally I've tried > > booting a CURRENT snapshot cd (8.0-CURRENT-200812) and I was able to properly > > configure the device in sysinstall. > > Any idea about the problem? > >No, there is no source code differences between CURRENT and 7.1- RELEASE. > > > I've installed > > from 7.0 and I have another NIC, but being now age in GENERIC, I hope it will > > not cause troubles to other people installing for the first time. > > Anyway thank > > you for now, and ask me if there is something that I can do to fix the problem > > like more tests, patches, etc. > > > >Would try the following WIP version? >http://people. freebsd.org/~yongari/age/if_age.c >http://people.freebsd. org/~yongari/age/if_agereg.h >I have no longer access to L1 hardware so I don't know whether it >helps or not. > >-- >Regards, >Pyun YongHyeon Well, it works! As I've said, it's not a real problem for me, but I'm so sorry about not having tested before so it could be merged before 7.1-RELEASE, but I had it disabled and nearly forgot about that. Please, feel free to ask whenever you want if you want me doing tests on that NIC. Thanks Barbara ___ 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"
mini itx from via - acpi issues on 7.1R
hail, I'm running 7.1R (tried 8.0-CURRENT also) on a via mini itx (dmesg bellow) and if I load acpi module, I have no lan. it appears, I can set IP, even the led would blink when I ping. but no signal of bits on the other pc whatsoever. tcpdump sees nothing in both endpoints. if acpi is not loaded, vr0 works as it should. i really think acpi would help this box, on power purposes, so here I am asking. thanks, matheus ps: should I mail acpi@ with, or instead ? $ dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Transmeta(tm) Crusoe(tm) Processor TM5700 (798.13-MHz 586-class CPU) Origin = "GenuineTMx86" Id = 0x543 Stepping = 3 Features=0x84893f real memory = 117374976 (111 MB) avail memory = 100737024 (96 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) uhci0: port 0xe000-0xe01f irq 15 at device 9.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe100-0xe11f irq 5 at device 9.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xe8131000-0xe81310ff irq 10 at device 9.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered vgapci0: port 0xe200-0xe2ff mem 0xe000-0xe7ff,0xe812-0xe812 irq 11 at device 13.0 on pci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe300-0xe30f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 17.4 (no driver attached) vr0: port 0xe600-0xe6ff mem 0xe813-0xe81300ff irq 15 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x51 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:11:85:e3:2a:17 vr0: [ITHREAD] cpu0 on motherboard pmtimer0 on isa0 orm0: at iomem 0xc-0xc8fff,0xcc000-0xd5fff pnpid ORM on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) Timecounter "TSC" frequency 798129274 Hz quality 800 Timecounters tick every 1.000 msec ad0: DMA limited to UDMA33, device found non-ATA66 cable ad0: 19464MB at ata0-master UDMA33 Trying to mount root from ufs:/dev/ad0s2a v...@pci0:0:18:0: class=0x02 card=0x01021106 chip=0x30651106 rev=0x51 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6102 Rhine II PCI Fast Ethernet Controller||Used by GERICOM in laptop Webengine Advanced' class = network subclass = ethernet -- We will call you cygnus, The God of balance you shall be ___ 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: Big problems with 7.1 locking up :-(
> Since ULE is now default in 7.1 and not in 7.0, perhaps you can try > that? Actually you might be on to something there one of the main differences between out test GL360 and the live ones is that the test one has less cores in it, and is under less load. So multiprocessing problems may well show up on the live where they wont on the test box. I shall try building a kernel with the BSD scheduler adn see what happens there. probbaly not today, as am loathe to cause anymore downtime right now. thanks, -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: Big problems with 7.1 locking up :-(
On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. Not sure if this is related but when our system "froze" the box was pingable, and you could switch virtual consoles... however, you could not type anything on the screen or connect to any sockets. Num-lock would still work so the box wasn't solidly frozen. This used to happen a couple of times every week or two. We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. (our box was a Dell PE1750, 2GB of RAM, amr RAID controller, bge network driver) The primary application was just ntpd and apache with mpm_worker & threads. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ 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"
New snd_hda import and very low mixer volume
Hi! I've just upgraded from 7.1-PRERELEASE to 7.1-STABLE via source upgrade and divcovered that my sound stopped working. I was aware about recent HDA driver update and tried to switch hw.snd.default_unit back and forth but that did not help. Finally I've realised that's just mixer values changed their meaning: now I can't hear anything at levels 50:50 of both 'mixer pcm' and 'mixer vol' and have to increase values significantly to make sound: upto 85:85 of both. Isn't it a bug? I've Intel D975XBX motherboard with onboard Azalia HDA, default unit is 0: $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: at cad 2 nid 1 on hdac0 [MPSAFE] (1p:2v/1r:1v channels duplex default) pcm1: at cad 2 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels) Eugene Grosbein ___ 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: Medical database Vidal
In article <20090109184126.ga2...@pollux2.free.local.net> you write: > When mounting a (cd9660) CD-ROM of the medical database Vidal in order > to try an installation with wine, I've discovered that I cannot see > two files (visible under Windows), setup.exe and some .ini file the > full name of which I have forgotten now, while I can perfectly see > the merlin-vcd-data.zip file in the dat directory. > > How on Unix earth is this possible ?? As you may already know, native ISO9660 (well, level 1, which is what is usually used) only supports very limited filenames (8.3, uppercase, every file must have a version number). As a result, a number of extensions have been developed: Unix systems use a system called Rock Ridge, which supports long filenames and the usual POSIX metadata; Win32 systems use a system called Joliet, which uses Unicode filenames and supports vfat-ish metadata; Apple have their own system which supports HFSish metadata. Some CDs are built with more than one extension system, in which case there are now several completely independant directory trees on the disc. It's perfectly possible to make the different trees contain different files; indeed, it's possible to make the same file appear to contain different contents under different systems. See e.g. the -hide, -hide-joliet, -hide-hfs options to mkisofs. I would guess that your CD has both Rock Ridge and Joliet extensions, and that the creator has hidden the Win32-specific files from the Unix directory tree because they thought they wouldn't be useful. If for some reason you need to see the CD as a Win32 machine would, you can use the -r option to mount_cd9660. Ben ___ 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: ACPI support?
On Fri, 09 Jan 2009 10:01:33 +0200 Krassimir Slavchev wrote: > I have found that thread. FWIW, I started a new thread[1] on freebsd-mobile, to update the status now after FreeBSD 7.1 has been released > The problem may be with allocating resources by ACPI PCI-PCI bridge. > There is a way to set needed values: > http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html Interesting. For my laptop, it seems that these bridges have the problem: pcib2: irq 17 at device 28.0 on pci0 pcib2: domain0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 16 at device 28.1 on pci0 pcib3: domain0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode0x0-0x0 pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 and also these: pcib4: irq 18 at device 28.2 on pci0 pcib4: domain0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 19 at device 28.3 on pci0 pcib5: domain0 pcib5: secondary bus 5 pcib5: subordinate bus 7 pcib5: I/O decode0x0-0x0 pcib5: no prefetched decode pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.RP04 - AE_NOT_FOUND pci5: on pcib5 pci5: domain=0, physical bus=5 bge0 (the wired interface is on pcib4: bge0: irq 18 at device 0.0 on pci4 pcib4: bge0 requested unsupported memory range 0-0x (decoding 0-0, 0-0) bge0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). bge0: couldn't map memory device_attach: bge0 attach returned 6 and wpi0 (the wireless) is on pcib3: wpi0: irq 17 at device 0.0 on pci3 wpi0: Driver Revision 20071127 pcib3: wpi0 requested unsupported memory range 0-0x (decoding 0-0, 0-0) wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0x). wpi0: could not allocate memory resource device_attach: wpi0 attach returned 6 With acpi disabled, the bridges shoiw up like this: pcib2: irq 17 at device 28.0 on pci0 pcib2: domain0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 16 at device 28.1 on pci0 pcib3: domain0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode0xf000-0xfff pcib3: memory decode 0xc820-0xc82f pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: irq 18 at device 28.2 on pci0 pcib4: domain0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode0xf000-0xfff pcib4: memory decode 0xc830-0xc83f pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 19 at device 28.3 on pci0 pcib5: domain0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode0xf000-0xfff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 bge with acpi disabled: bge0: mem 0xc830-0xc830 irq 17 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xc830 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to vector 48 bge0: using IRQ 256 for MSI miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0018, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:16:36:54:a9:ae bge0: [MPSAFE] bge0: [ITHREAD] wpi with acpi disabled: wpi0: mem 0xc820-0xc8200fff irq 17 at device 0.0 on pci3 wpi0: Driver Revision 20071127 wpi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc820 wpi0: Hardware Revision (0x1) wpi0: Regulatory Domain: MoW2 wpi0: Hardware Type: B wpi0: Hardware Revision: ? wpi0: SKU does support 802.11a wpi0: bpf attached wpi0: Ethernet address: 00:13:02:3e:d4:ce wpi0: bpf attached wpi0: bpf attached ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 60 wpi0: [MPSAFE] wpi0: [ITHREAD] wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Perhaps I should try to patch my pci too. References: 1) http://lists.freebsd.org/pipermail/freebsd-mobile/2009-January/011294.html -- Torfinn ___ 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"
Medical database Vidal
When mounting a (cd9660) CD-ROM of the medical database Vidal in order to try an installation with wine, I've discovered that I cannot see two files (visible under Windows), setup.exe and some .ini file the full name of which I have forgotten now, while I can perfectly see the merlin-vcd-data.zip file in the dat directory. How on Unix earth is this possible ?? Harald -- FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 ___ 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"
Broken loader on 7.1-STABLE?
Good morning everyone, I was wondering if anyone else was seeing loader (v1.02) break after updating from 7.1-RELEASE to 7.1-STABLE. After performing the prescribed updating procedure (via the handbook), the system will go through the normal steps and after the boot menu will present the following error: Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0 According to the bugbusting page on the FreeBSD wiki there's two issues at work that cause this behavior; patches were committed to HEAD/RELENG earlier last year in Mar and Aug. Up until now I've never come across this problem in 6.x or 7.0. In doing a little research I've come across a few older threads via google where it was believed that the problem was caused by improper CFLAGS in make.conf. I've commented mine out and rebuilt things.. with the same end result. In fact, if it's any help, my CFLAGS declaration in make.conf is taken verbatim from the /usr/share/examples/etc/make.conf. Furthermore, on selecting option 6 from the boot menu (escape to loader prompt), the system [I'm assuming] crashes displaying a blinking ASCII pattern from which only a hard reboot will work. FWIW, this is a fairly plain system.. nothing special in sysctl.conf or loader.conf, and the kernel is pretty stock as well (more or less GENERIC with my sound device and pf). A temporary fix for me was to copy over loader.old to loader in /boot. Any comments or suggestions would be greatly appreciated. All I ask is to please CC me in the reply to the list as I don't currently subscribe to -stable. TIA Reuben A. Popp -- I build no system. I ask an end to privilege, the abolition of slavery, equality of rights, and the reign of law. Justice, nothing else. That is the alpha and omega of my argument. -- Pierre-Joseph Proudhon ___ 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: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
On Mon, Jan 5, 2009 at 7:41 PM, Brian Duke wrote: > #make -j4 buildworld; make -j4 buildkernel; make installkernel Use instead make -j4 buildworld && make buildkernel && make installkernel If any of your commands failed you were unable to know. i suppose it failed building kernel. -- 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
Pete French wrote: Are you using the same disk controller as Peter ? Do both of you run with quotas on the file system ? By lockup, do you mean it doesnt respond to the network either or just anything that needs disk IO ? I dont think he can be using yhe same controller, as mine is an embedded HPO unit. they do make a separate plugin one though - P400 SAS controller. My symptoms are that the thing locks hard and respionds to nothing, no keypresses or anything. I am assuming that the disc is the first thing to go though, ebcause I see data which was being written to a file and a processes reading from that file to the network. more of the file comes over the network than makes it phyiscally onto the disc The only useful error I ever saw was the message about spin lock / turnstile locks being held for too long. -pete. OK, perhaps my issue is different then. My symptoms seem to be a hang from anything that triggers a fork(), such as entering a command at a shell prompt or entering a user name at the console's login prompt. Network activity still works -- all the TCP connections stay up until I drop into the kernel debugger or power cycle. Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ 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: Big problems with 7.1 locking up :-(
> Are you using the same disk controller as Peter ? Do both of you run > with quotas on the file system ? By lockup, do you mean it doesnt > respond to the network either or just anything that needs disk IO ? I dont think he can be using yhe same controller, as mine is an embedded HPO unit. they do make a separate plugin one though - P400 SAS controller. My symptoms are that the thing locks hard and respionds to nothing, no keypresses or anything. I am assuming that the disc is the first thing to go though, ebcause I see data which was being written to a file and a processes reading from that file to the network. more of the file comes over the network than makes it phyiscally onto the disc The only useful error I ever saw was the message about spin lock / turnstile locks being held for too long. -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: Big problems with 7.1 locking up :-(
At 09:49 AM 1/9/2009, Guy Helmer wrote: RAID controller with a pair of mirrored drives connected. Each one has both ethernets connected, bundled using lagg and LACP. I can't tell whether my situation is related, but I am seeing lockups on SMP Supermicro servers with both older (NetBurst-ish) and current Xeon CPUs. I have been dropping into the kernel debugger and getting lock information and process backtraces, but so far nothing has been conclusively identified. I think the issue I'm seeing was introduced sometime between October 2 and November 24 in the RELENG_7 branch, and I suppose the next step is to do a binary search for the offending change. Are you using the same disk controller as Peter ? Do both of you run with quotas on the file system ? By lockup, do you mean it doesnt respond to the network either or just anything that needs disk IO ? ---Mike ___ 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: Big problems with 7.1 locking up :-(
Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. So the last two days I have been round upgrading all our servers, knowing that I had run the system stably on identical hardware for some time. Since then I have starte seeing machines lock up. This always happens under heavy disc load. When I bring the machine back up then sometimes it fails to fsck due to a partialy truncated inode. The locksup appear to be disc related - on my mysql msater machine it will come back up with files somewhat shorted than those which ahve aready been transmitted to the slave (i.e. some data was in memory, and claimed to have been written to the drive, but never made it onto the disc). The only time I have seen anything useful on the screen was during one lockup where I got a message about a spin lock being held too long and some comment in parentheses about it being a turnstile lock. Help! :-( I am now downgrading all the machine to 7.0 as fast as I can - though the machine I am trying to compile it on has locked up once during the compile so I havent got anywhere so far. The machines are HP Proliant DL360 G5s - they have an embedded P400i RAID controller with a pair of mirrored drives connected. Each one has both ethernets connected, bundled using lagg and LACP. I can't tell whether my situation is related, but I am seeing lockups on SMP Supermicro servers with both older (NetBurst-ish) and current Xeon CPUs. I have been dropping into the kernel debugger and getting lock information and process backtraces, but so far nothing has been conclusively identified. I think the issue I'm seeing was introduced sometime between October 2 and November 24 in the RELENG_7 branch, and I suppose the next step is to do a binary search for the offending change. Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ 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: more marvell marvels
> On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote: > > hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf: > > > > ms...@pci0:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab > > rev=0x12 hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' > > class = network > > subclass = ethernet > > cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 03[50] = VPD > > cap 05[5c] = MSI supports 1 message, 64 bit > > cap 10[e0] = PCI-Express 1 legacy endpoint > > > > nothing new here, problems have been reported before, but: > > > > my very first attempt - after a very long time - of booting 7.1-stable, > > produced > > a panic because msk could not find its physio, by the time i had the > serial > > console > > attached and working, that problem disappeared :-( > > now, after reboot, it sometimes hangs - because the net is not working, > and > > only if > > I unplug the ethernet, (no signs of the driver seeing this), and replug > things > > begin > > to work. btw, i had to set > > hw.msk.legacy_intr="1" > > to get things working. > > > > any patches for 7.1-stable to test? > > > > If memory serve me right you have Yukon EC Ultra with 88E1149 PHY, > right? e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [ITHREAD] >CURRENT has some stability fixes but the source wouldn't be > compiled on stable/7 yet due to KPI differences. I have plan to add > some features in next week which make it possible to use HEAD > version on stable/7. > > I'm not sure the patch for 88E8040 could be applied to stable/7 > but the patch has some fixes for link state handling. Would you > give it try? > http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14 > Note, the 88E8040 patch is not complete yet and may cause other > problems too. I'll try asap thanks, danny > > -- > Regards, > Pyun YongHyeon ___ 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: more marvell marvels
On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote: > hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf: > > ms...@pci0:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab > rev=0x12 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 03[50] = VPD > cap 05[5c] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 legacy endpoint > > nothing new here, problems have been reported before, but: > > my very first attempt - after a very long time - of booting 7.1-stable, > produced > a panic because msk could not find its physio, by the time i had the serial > console > attached and working, that problem disappeared :-( > now, after reboot, it sometimes hangs - because the net is not working, and > only if > I unplug the ethernet, (no signs of the driver seeing this), and replug > things > begin > to work. btw, i had to set > hw.msk.legacy_intr="1" > to get things working. > > any patches for 7.1-stable to test? > If memory serve me right you have Yukon EC Ultra with 88E1149 PHY, right? CURRENT has some stability fixes but the source wouldn't be compiled on stable/7 yet due to KPI differences. I have plan to add some features in next week which make it possible to use HEAD version on stable/7. I'm not sure the patch for 88E8040 could be applied to stable/7 but the patch has some fixes for link state handling. Would you give it try? http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14 Note, the 88E8040 patch is not complete yet and may cause other problems too. -- Regards, Pyun YongHyeon ___ 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"
more marvell marvels
hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf: ms...@pci0:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 03[50] = VPD cap 05[5c] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 legacy endpoint nothing new here, problems have been reported before, but: my very first attempt - after a very long time - of booting 7.1-stable, produced a panic because msk could not find its physio, by the time i had the serial console attached and working, that problem disappeared :-( now, after reboot, it sometimes hangs - because the net is not working, and only if I unplug the ethernet, (no signs of the driver seeing this), and replug things begin to work. btw, i had to set hw.msk.legacy_intr="1" to get things working. any patches for 7.1-stable to test? danny ___ 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: NIC for VLAN
Hi, BCE-based cards looks good on paper, but it's firmware is of poor quality compared to BGE-based cards. The BCE-cards could sink 1.48Mpps, but it ftq drops 800Kpps, and the host sees 600Kpps. TX is ~800Kpps (according to sephe). That said, I'm using dot1q vlan trunks on both bce and bge based cards, and it's working well. Regards, Daniel. On Jan 8, 2009, at 11:26 AM, Oliver Fromme wrote: Edvaldo Silva wrote: Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under FreeBSD? I'm using bge(4) and bce(4) interfaces (Broadcom GBit) and fxp(4) ones (100 MBit) in enviroments with heavy use of VLANs. They work very well. There are no problems with the MTU. 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 "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie ___ 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: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
On Mon, Jan 05, 2009 at 11:36:54AM +0100, Barbara wrote: [...] > I've tried all the thing you've suggested with > the same result. > I've disabled "LAN Option ROM", but it seems that I don't have > the other options you mentioned. > I've downloaded and burned the 7.1-RELEASE dvd > and tried to boot from it, but it hangs at the same point. > Finally I've tried > booting a CURRENT snapshot cd (8.0-CURRENT-200812) and I was able to > properly > configure the device in sysinstall. > Any idea about the problem? No, there is no source code differences between CURRENT and 7.1-RELEASE. > I've installed > from 7.0 and I have another NIC, but being now age in GENERIC, I hope it > will > not cause troubles to other people installing for the first time. > Anyway thank > you for now, and ask me if there is something that I can do to fix the > problem > like more tests, patches, etc. > Would try the following WIP version? http://people.freebsd.org/~yongari/age/if_age.c http://people.freebsd.org/~yongari/age/if_agereg.h I have no longer access to L1 hardware so I don't know whether it helps or not. -- Regards, Pyun YongHyeon ___ 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: kernel dump with 7.1-RELEASE
Hi, I'm assuming you configured a a dump-device in rc.conf, but just in case, here are the options: db ~> grep dump /etc/defaults/rc.conf [...@gonzales] dumpdev="AUTO"# Device to crashdump to (device name, AUTO, or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. using SWAP as the dumpdevice is the recommended way, as you sorta pointed out. More information can be found at: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html On Jan 8, 2009, at 5:05 PM, Omer Faruk Sen wrote: Hi, I am having kernel dumps with FreeBSD 7.1 panic: semexit - semid not allocated cpuid = 1 Uptime : 8m22s Cannot dump. No dump device defined Sleeping thread (tid 100129, pid 1479) owns a non-sleepable lock I know it is not clear and there were no swap space configured on this server (which I will re-install with swap space) but can someone enlighten me about this since I think this bug was also in FreeBSD 6.2 and fixed in FreeBSD 6.3 Regards. ___ 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: igb on a Nehalem system, buildworld stats
On Fri, Jan 9, 2009 at 6:14 PM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel wrote: >> > [snip] >>> >> >>> >> If you have a back to back connection to another NIC on Port 0, no >>> >> switch, >>> >> does >>> >> it still autoneg to 100? >>> >> >>> >>> Connected back to back w/ another box w/ a GigE NIC, it now does >>> 1000baseTX: >>> >>> igb0: flags=8843 metric 0 mtu 1500 >>>options=19b >>>ether 00:30:48:c5:db:e2 >>>inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1 >>>inet 192.168.70.2 netmask 0xff00 broadcast 192.168.70.255 >>>media: Ethernet autoselect (1000baseTX ) >>>status: active >>> >>> But still not without problems. I hafta ifconfig down/up it several >>> times until I can see the other end. W/c is the same for igb1. >> >> >> OK, so you have some switch issue. What do you mean "see the other end", >> if its back to back and boots up I assume it gets link, if you have the >> address >> assigned in rc.conf, and you run tcpdump on the partner do you see the arp >> when it comes online, and at that point can the other side ping it? >> > > By 'see the other end' , I meant that even if It says 1000baseTX, i > still can't ping the other end, well not really, as I can now see it > gots bad chksums: > > 1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2 > 1. 51 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 > (0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags > [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP > echo request, id 14852, seq 0, length 64 > 12 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), > length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto > ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 > > 192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64 > 1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 > (0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags > [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP > echo request, id 14852, seq 1, length 64 > 11 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), > length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto > ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 > > 192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64 > > and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has > been in production for some time) > >> Oh, and what is the link partner hardware? >> > > The switch? it's a Dlink 48-Port DGS-1248T GigE switch. > > Thanks. > btw, I tried 200812-CURRENT and CURRENT as of Jan 7 and the behavior is still the same :-( >> Jack >> >> > > > > -- > cheers > mars > -- cheers mars ___ 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: igb on a Nehalem system, buildworld stats
On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel wrote: > [snip] >> >> >> >> If you have a back to back connection to another NIC on Port 0, no >> >> switch, >> >> does >> >> it still autoneg to 100? >> >> >> >> Connected back to back w/ another box w/ a GigE NIC, it now does >> 1000baseTX: >> >> igb0: flags=8843 metric 0 mtu 1500 >>options=19b >>ether 00:30:48:c5:db:e2 >>inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1 >>inet 192.168.70.2 netmask 0xff00 broadcast 192.168.70.255 >>media: Ethernet autoselect (1000baseTX ) >>status: active >> >> But still not without problems. I hafta ifconfig down/up it several >> times until I can see the other end. W/c is the same for igb1. > > > OK, so you have some switch issue. What do you mean "see the other end", > if its back to back and boots up I assume it gets link, if you have the > address > assigned in rc.conf, and you run tcpdump on the partner do you see the arp > when it comes online, and at that point can the other side ping it? > By 'see the other end' , I meant that even if It says 1000baseTX, i still can't ping the other end, well not really, as I can now see it gots bad chksums: 1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2 1. 51 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP echo request, id 14852, seq 0, length 64 12 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 > 192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64 1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP echo request, id 14852, seq 1, length 64 11 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 > 192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64 and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has been in production for some time) > Oh, and what is the link partner hardware? > The switch? it's a Dlink 48-Port DGS-1248T GigE switch. Thanks. > Jack > > -- cheers mars ___ 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: igb on a Nehalem system, buildworld stats
On Fri, Jan 9, 2009 at 12:02 AM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 2:50 AM, Mars G Miro > wrote: > > On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel wrote: > >> Well, I am at Intel you know, and even we don't seem to have any systems > >> with > >> 82576 down in my group here. The way link works I can be about 99.9% > sure > >> in saying its not the driver. Its preproduction so there are lots of > >> possibilities, > >> and the biggest problem is its going to be difficult to help when I > don't > >> have any > >> such hardware :( > >> > >> I've heard from the 1G product team that they have seen EEPROM > mismatches > >> on systems that will result in things not working in funny ways. > > > > > > Jahh, I've seen those but not w/ Intel NICs. I believe it was from > > Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-) > > > > > >> > >> If you have a back to back connection to another NIC on Port 0, no > switch, > >> does > >> it still autoneg to 100? > >> > > Connected back to back w/ another box w/ a GigE NIC, it now does > 1000baseTX: > > igb0: flags=8843 metric 0 mtu 1500 >options=19b >ether 00:30:48:c5:db:e2 >inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1 > inet 192.168.70.2 netmask 0xff00 broadcast 192.168.70.255 > media: Ethernet autoselect (1000baseTX ) >status: active > > But still not without problems. I hafta ifconfig down/up it several > times until I can see the other end. W/c is the same for igb1. > OK, so you have some switch issue. What do you mean "see the other end", if its back to back and boots up I assume it gets link, if you have the address assigned in rc.conf, and you run tcpdump on the partner do you see the arp when it comes online, and at that point can the other side ping it? Oh, and what is the link partner hardware? Jack ___ 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: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..."
Robert Noland schrieb: I'm really not sure that I am the best person to try and tackle this, Hi, Robert, thank you very much for your reply! but it does fall somewhere near me... Can you send me a pciconf -lv. You are welcome! Well, as stated in the reports, I'm prepared to help with additional information and tests I can provide. My main background is Gentoo (GNU/Linux source based rolling meta- distribution), thus knowing my way around building my hand-crafted kernels ... Kind regards Manfred . --- --- --- pciconf -lv --- --- --- hos...@pci0:0:0:0: class=0x06 card=0x00e11849 chip=0x00e110de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Host/PCI Bridge' <= class = bridge subclass = HOST-PCI is...@pci0:0:1:0: class=0x060100 card=0x00e01849 chip=0x00e010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 LPC Interface Bridge' class = bridge subclass = PCI-ISA no...@pci0:0:1:1: class=0x0c0500 card=0x00e41849 chip=0x00e410de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI System Management' class = serial bus subclass = SMBus oh...@pci0:0:2:0: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB oh...@pci0:0:2:1: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB eh...@pci0:0:2:2: class=0x0c0320 card=0x00e81849 chip=0x00e810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Enhanced PCI to USB Controller' class = serial bus subclass = USB atap...@pci0:0:8:0: class=0x01018a card=0x00e51849 chip=0x00e510de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Parallel ATA Controller' class = mass storage subclass = ATA atap...@pci0:0:10:0:class=0x010185 card=0x00e31849 chip=0x00e310de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Serial ATA Controller' class = mass storage subclass = ATA pc...@pci0:0:11:0: class=0x060400 card=0x chip=0x00e210de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 AGP Host to PCI Bridge' <= class = bridge subclass = PCI-PCI pc...@pci0:0:14:0: class=0x060400 card=0x chip=0x00ed10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI-PCI Bridge' <= class = bridge subclass = PCI-PCI hos...@pci0:0:16:0: class=0x06 card=0x chip=0x169510b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ULi M1695 K8 Northbridge with PCIe and hypertransport' class = bridge subclass = HOST-PCI pc...@pci0:0:17:0: class=0x060400 card=0x chip=0x524b10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pc...@pci0:0:18:0: class=0x060400 card=0x chip=0x524c10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pc...@pci0:0:19:0: class=0x060400 card=0x chip=0x524d10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' class = bridge subclass = PCI-PCI hos...@pci0:0:24:0: class=0x06 card=0x chip=0x12001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hos...@pci0:0:24:1: class=0x06 card=0x chip=0x12011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Address Map' class = bridge subclass = HOST-PCI hos...@pci0:0:24:2: class=0x06 card=0x chip=0x12021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron DRAM Controller' class = bridge subclass = HOST-PCI hos...@pci0:0:24:3: class=0x06 card=0x chip=0x12031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Miscellaneous Control' class = bridge subclass = HOST-PCI hos...@pci0:0:24:4: class=0x06 card=0x chip=0x12041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h
Re: igb on a Nehalem system, buildworld stats
On Fri, Jan 9, 2009 at 2:50 AM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel wrote: >> Well, I am at Intel you know, and even we don't seem to have any systems >> with >> 82576 down in my group here. The way link works I can be about 99.9% sure >> in saying its not the driver. Its preproduction so there are lots of >> possibilities, >> and the biggest problem is its going to be difficult to help when I don't >> have any >> such hardware :( >> >> I've heard from the 1G product team that they have seen EEPROM mismatches >> on systems that will result in things not working in funny ways. > > > Jahh, I've seen those but not w/ Intel NICs. I believe it was from > Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-) > > >> >> If you have a back to back connection to another NIC on Port 0, no switch, >> does >> it still autoneg to 100? >> Connected back to back w/ another box w/ a GigE NIC, it now does 1000baseTX: igb0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c5:db:e2 inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1 inet 192.168.70.2 netmask 0xff00 broadcast 192.168.70.255 media: Ethernet autoselect (1000baseTX ) status: active But still not without problems. I hafta ifconfig down/up it several times until I can see the other end. W/c is the same for igb1. > [snip] -- cheers mars ___ 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: ACPI support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Thanks for your reply! Torfinn Ingolfsen wrote: > On Tue, 06 Jan 2009 13:12:05 +0200 > Krassimir Slavchev wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hello All, >> >> I have had a problem detecting the network card on my notebook when >> ACPI is enabled for a year. The problem still exists in 7.1-RELEASE. > > Which make and model notebook is this? > Acer Aspire 5920G > You have my sympaties, my own laptop[1] (Acer Aspire 5672) have the same > sort of problem - drivers for NICs (both wired and wireless) will not > attach if acpi is enabled. And this laptop gets too hot when acpi is > disabled - I fear it will overheat. Linux runs fine[2] on it. > same > I had a lot of help in trying to fix the problem a wbile back (check > the freebsd-mobile mailing list archives), but in the end, nothing > helped. I have found that thread. > > I can only offer general advice, not a solution. Try too look for > a modfified DSDT for your notebook, perhpas you will find something > that helps. > > References: > 1) http://tingox.googlepages.com/aceraspireas5672andfreebsd > 2) http://tingox.googlepages.com/as5672_xubuntu Modifying the DSDT was the first thing I tried a year ago but nothing. The problem may be with allocating resources by ACPI PCI-PCI bridge. There is a way to set needed values: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html I am still not sure where is the exact problem! Whether something is wrong with ACPI PCI-PCI bridge or ACPI does not offer these resources? I would like to work on this and any help is welcome Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJZwRdxJBWvpalMpkRAuP0AJ9gn2sc9vF2emPfqEBxl7suNYNzTgCePbWp k8L3cDbNfYYxJ6gT6b/541g= =wZlz -END PGP SIGNATURE- ___ 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"
