Re: ZFS boot inside on the second partition inside a slice
I just redo everything, and changed the order of freebsd-zfs and freebsd-swap. The "Read error" still happens! On Wed, Jun 15, 2011 at 8:07 PM, Zhihao Yuan wrote: > On Wed, Jun 15, 2011 at 7:58 PM, Xin LI wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 06/15/11 17:42, Zhihao Yuan wrote: >>> Hi, >>> >>> I configured my disk layout according to >>> http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition >>> >>> But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G >>> freebsd-swap partition appears first inside the slice. >>> After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0 >>> gives me a "Read error". >> >> Where did your second slice start? There can be a lot of reasons why it >> gives Read error. > > After an NTFS partition of 12GB. > This should be the problem with zfsboot, because if I use sysinstall > to install a bootmgr, the boot gives me a "not UFS" error, which means > the boot0 is done (am I right?). > >> >> I personally recommend using GPT scheme instead of MBR, as you have a >> dedicated partition for gptzfsboot, which is much cleaner than this >> approach. >> > > Yeah, yeah, I agree. I should not plan to play Windows games. > >> Cheers, >> - -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! Live free or die >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.17 (FreeBSD) >> >> iQEcBAEBCAAGBQJN+VUrAAoJEATO+BI/yjfBpksH/2ZswQ+ogdDpYwvhRIjJaqLs >> NEl8FtC2Ua+c3F2sNwrLK5a/fn/LL+jPAXndvuQdxOaz41Iqtnt8w1i9Dz5ATkva >> T+i0fnRVwXFqjrlRTWK+ODtNtrhI2/7ECAIfOOLNhaiJnPRrJJgvxJ6V5W+/N+l7 >> Lt4yMp6hGbhO/9Yp2UoaQuUThOTz+dKNZGECd1nLT+ooHbTPhBvjii080hHowNl6 >> Ef+JBaEng2NbRJPxYWrRwz6R7A44RDXvrKzn5w/TuUa+4fYrS25EZxygzIh3xjFX >> 2ILP25yabJ+Vw5o8bFCsJ3ExbEfq0PnfROHanRSdTjMDra27dGY9JZKyytE+Ykc= >> =D5+X >> -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" >> > > > > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___ > 4BSD -- http://4bsd.biz/ > -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: ZFS boot inside on the second partition inside a slice
On Wed, Jun 15, 2011 at 7:58 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/15/11 17:42, Zhihao Yuan wrote: >> Hi, >> >> I configured my disk layout according to >> http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition >> >> But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G >> freebsd-swap partition appears first inside the slice. >> After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0 >> gives me a "Read error". > > Where did your second slice start? There can be a lot of reasons why it > gives Read error. After an NTFS partition of 12GB. This should be the problem with zfsboot, because if I use sysinstall to install a bootmgr, the boot gives me a "not UFS" error, which means the boot0 is done (am I right?). > > I personally recommend using GPT scheme instead of MBR, as you have a > dedicated partition for gptzfsboot, which is much cleaner than this > approach. > Yeah, yeah, I agree. I should not plan to play Windows games. > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBCAAGBQJN+VUrAAoJEATO+BI/yjfBpksH/2ZswQ+ogdDpYwvhRIjJaqLs > NEl8FtC2Ua+c3F2sNwrLK5a/fn/LL+jPAXndvuQdxOaz41Iqtnt8w1i9Dz5ATkva > T+i0fnRVwXFqjrlRTWK+ODtNtrhI2/7ECAIfOOLNhaiJnPRrJJgvxJ6V5W+/N+l7 > Lt4yMp6hGbhO/9Yp2UoaQuUThOTz+dKNZGECd1nLT+ooHbTPhBvjii080hHowNl6 > Ef+JBaEng2NbRJPxYWrRwz6R7A44RDXvrKzn5w/TuUa+4fYrS25EZxygzIh3xjFX > 2ILP25yabJ+Vw5o8bFCsJ3ExbEfq0PnfROHanRSdTjMDra27dGY9JZKyytE+Ykc= > =D5+X > -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" > -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: ZFS boot inside on the second partition inside a slice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/11 17:42, Zhihao Yuan wrote: > Hi, > > I configured my disk layout according to > http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition > > But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G > freebsd-swap partition appears first inside the slice. > After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0 > gives me a "Read error". Where did your second slice start? There can be a lot of reasons why it gives Read error. I personally recommend using GPT scheme instead of MBR, as you have a dedicated partition for gptzfsboot, which is much cleaner than this approach. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJN+VUrAAoJEATO+BI/yjfBpksH/2ZswQ+ogdDpYwvhRIjJaqLs NEl8FtC2Ua+c3F2sNwrLK5a/fn/LL+jPAXndvuQdxOaz41Iqtnt8w1i9Dz5ATkva T+i0fnRVwXFqjrlRTWK+ODtNtrhI2/7ECAIfOOLNhaiJnPRrJJgvxJ6V5W+/N+l7 Lt4yMp6hGbhO/9Yp2UoaQuUThOTz+dKNZGECd1nLT+ooHbTPhBvjii080hHowNl6 Ef+JBaEng2NbRJPxYWrRwz6R7A44RDXvrKzn5w/TuUa+4fYrS25EZxygzIh3xjFX 2ILP25yabJ+Vw5o8bFCsJ3ExbEfq0PnfROHanRSdTjMDra27dGY9JZKyytE+Ykc= =D5+X -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"
Re: em0 watchdog timeouts on 8-STABLE
I have hardware now, am working on reproducing this. Just curious, do you have the em driver defined in the kernel, or as a module? Jack On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: > On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick > wrote: > > > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: > > > I recently updated my server to the latest 8-STABLE, and upgraded to > v28 > > > ZFS. I have not had these problems on any other version of 8-STABLE or > > > 7-STABLE, which this box was upgraded from some time ago. > > > > > > Now, during my weekly scrub, I get the following messages and em0 is > > > unresponsive: > > > > > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- > resetting > > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN > > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP > > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- > resetting > > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN > > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP > > > > > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog > > > timeouts start occurring pretty quickly once I/O ramps up. > > > > > > Here's some possibly relevant information, let me know if anything else > > > would be helpful to troubleshoot. > > > > > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE > > #17: > > > Mon Jun 6 19:40:19 EDT 2011 > > > r...@foghornleghorn.res.openband.net: > /usr/obj/usr/src/sys/FOGHORNLEGHORN > > > amd64 > > > > > > em0: port > > 0xe800-0xe83f > > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on > > pci7 > > > > > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 > rev=0x05 > > > hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > > > class = network > > > subclass = ethernet > > > > > > And, the SAS cards: > > > > > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter > > > dev.mpt.0.%driver: mpt > > > dev.mpt.0.%location: slot=0 function=0 > > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > > subdevice=0xa580 class=0x01 > > > dev.mpt.0.%parent: pci1 > > > dev.mpt.0.debug: 3 > > > dev.mpt.0.role: 1 > > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter > > > dev.mpt.1.%driver: mpt > > > dev.mpt.1.%location: slot=0 function=0 > > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > > subdevice=0xa580 class=0x01 > > > dev.mpt.1.%parent: pci2 > > > dev.mpt.1.debug: 3 > > > dev.mpt.1.role: 1 > > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter > > > dev.mpt.2.%driver: mpt > > > dev.mpt.2.%location: slot=0 function=0 > > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 > > > subdevice=0x30a0 class=0x01 > > > dev.mpt.2.%parent: pci6 > > > dev.mpt.2.debug: 3 > > > dev.mpt.2.role: 1 > > > > Please provide output from the following commands (as root): > > > > # pciconf -lvcb > > > > hostb0@pci0:0:0:0: class=0x06 card=0x59561002 chip=0x59561002 rev=0x00 > hdr=0x00 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 GFX Dual Slot' >class = bridge >subclass = HOST-PCI > pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >class = bridge >subclass = PCI-PCI > pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >class = bridge >subclass = PCI-PCI > pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >class = bridge >subclass = PCI-PCI > pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >class = bridge >subclass = PCI-PCI > pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >class = bridge >subclass = PCI-PCI > pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 rev=0x00 > hdr=0x01 >vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >class = bridge >subclass = PCI-PCI
ZFS boot inside on the second partition inside a slice
Hi, I configured my disk layout according to http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G freebsd-swap partition appears first inside the slice. After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0 gives me a "Read error". What should do? Thanks. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: em0 watchdog timeouts on 8-STABLE
In the kernel. Here's my kernel configuration: http://pastebin.com/raw.php?i=4JL814m3 On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: > I have hardware now, am working on reproducing this. Just curious, do you > have > the em driver defined in the kernel, or as a module? > > Jack > > > On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: > >> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >> wrote: >> >> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >> > > I recently updated my server to the latest 8-STABLE, and upgraded to >> v28 >> > > ZFS. I have not had these problems on any other version of 8-STABLE or >> > > 7-STABLE, which this box was upgraded from some time ago. >> > > >> > > Now, during my weekly scrub, I get the following messages and em0 is >> > > unresponsive: >> > > >> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >> resetting >> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN >> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP >> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >> resetting >> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN >> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP >> > > >> > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog >> > > timeouts start occurring pretty quickly once I/O ramps up. >> > > >> > > Here's some possibly relevant information, let me know if anything >> else >> > > would be helpful to troubleshoot. >> > > >> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE >> > #17: >> > > Mon Jun 6 19:40:19 EDT 2011 >> > > r...@foghornleghorn.res.openband.net: >> /usr/obj/usr/src/sys/FOGHORNLEGHORN >> > > amd64 >> > > >> > > em0: port >> > 0xe800-0xe83f >> > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 >> on >> > pci7 >> > > >> > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 >> rev=0x05 >> > > hdr=0x00 >> > > vendor = 'Intel Corporation' >> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >> (82541PI)' >> > > class = network >> > > subclass = ethernet >> > > >> > > And, the SAS cards: >> > > >> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.0.%driver: mpt >> > > dev.mpt.0.%location: slot=0 function=0 >> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >> > > subdevice=0xa580 class=0x01 >> > > dev.mpt.0.%parent: pci1 >> > > dev.mpt.0.debug: 3 >> > > dev.mpt.0.role: 1 >> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.1.%driver: mpt >> > > dev.mpt.1.%location: slot=0 function=0 >> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >> > > subdevice=0xa580 class=0x01 >> > > dev.mpt.1.%parent: pci2 >> > > dev.mpt.1.debug: 3 >> > > dev.mpt.1.role: 1 >> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.2.%driver: mpt >> > > dev.mpt.2.%location: slot=0 function=0 >> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >> > > subdevice=0x30a0 class=0x01 >> > > dev.mpt.2.%parent: pci6 >> > > dev.mpt.2.debug: 3 >> > > dev.mpt.2.role: 1 >> > >> > Please provide output from the following commands (as root): >> > >> > # pciconf -lvcb >> > >> >> hostb0@pci0:0:0:0: class=0x06 card=0x59561002 chip=0x59561002 >> rev=0x00 >> hdr=0x00 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 GFX Dual Slot' >>class = bridge >>subclass = HOST-PCI >> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>class = bridge >>subclass = PCI-PCI >> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>class = bridge >>subclass = PCI-PCI >> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>class = bridge >>subclass = PCI-PCI >> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>class = bridge >>subclass = PCI-PCI >> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>class = bridge >>subclass = PCI-
Re: doscmd under 8-stable, anyone?
On Wed, Jun 15, 2011 at 04:44:55PM +0200, Joerg Wunsch wrote: > As Kostik Belousov wrote: > > > Do sysctl security.bsd.map_at_zero=1 > > Just for the record, this sysctl also makes my really really old utree > binary work again. The binary dates back to 386BSD 0.0, and I'm only > keeping it out of curiosity: > > j@uriah 66% ls -l /usr/local/bin/utree > -rwxr-xr-x 1 bin bin 179639 Apr 30 1992 /usr/local/bin/utree* > > The only thing to make it run is to use a termcap entry that is > smaller than 1024 byte, as this used to be a hard-coded limitation in > the termcap library of those days, and the binary is statically > linked. TERM=vt100 works, xterm no longer does. > > The ability to run this binary only serves as a proof that no backward > compatibility has ever been broken in FreeBSD. ;-) (Obviously, all > the various COMPAT_* options must be present in the kernel config.) Yes, doscmd and N-magic a.out binaries were the arguments to implement the sysctl instead of outright disable of the mapping at address 0. You are the first documented case of the wiseness of the decision :). BTW, I semi-jokingly committed the support for FreeBSD-1.0/i386 ABI on amd64 on April 1. Would be interesting to see how does your binary behaves. pgpll3h9Y77Ec.pgp Description: PGP signature
Re: doscmd under 8-stable, anyone?
2011/6/15 Jeremy Chadwick :
> On Wed, Jun 15, 2011 at 03:57:05PM +0200, Joerg Wunsch wrote:
>> When trying to use doscmd on 8-stable, all I get is:
>>
>> Error mapping HMA, HMA disabled: : Invalid argument
>> Segmentation fault (core dumped)
>>
>> The segfault happens at the end of mem_init(), when the allocated DOS
>> memory (which is located at virtual address 0) is attempted to be
>> written to. Apparently, the mmap() failure that causes the "HMA
>> disabled" message is actually a fatal error rather than a benign one
>> the could be ignored, as it results in no valid DOS memory allocation
>> at all.
>>
>> Right now, the only older system I could test it against uses FreeBSD
>> 5.x, where the mmap() works as expected. So does anyone have an idea
>> why this mmap() call:
>>
>> if (mmap((caddr_t)0x00, 0x10,
>> PROT_EXEC | PROT_READ | PROT_WRITE,
>> MAP_ANON | MAP_FIXED | MAP_SHARED,
>> -1, 0) == MAP_FAILED) {
>> perror("Error mapping HMA, HMA disabled: ");
>> HMA_a20 = -1;
>> close(HMA_fd_off);
>> close(HMA_fd_on);
>> return;
>> }
>>
>> yields an EINVAL now under 8-stable?
As I remember, mapping of "zero" page forbidden by default.
> I imagine that the page size ordeal is probably what's biting you. Now,
> I'm not sure if page size in that above context refers to "kernel page
> size" (e.g. hw.pagesizes or hw.pagesize) or if it refers to "a page of
> memory" as in what libc/malloc uses.
It refers. mmap(2) is system call.
On i386/amd64 "big" page size is 2MB, and code above is trying to
allocate 1MB, so memory will be allocated with 4KB-sized pages.
>
> I'm not sure why a person would need or want MAP_FIXED in this
> situation; why can't they just take the result of mmap() (a void *) and
> use that as a base address offset instead of assuming zero in their
> software?
AFAIK, doscmd is trying to emulate real mode on real hardware while
being in protected mode, thus it want first pages of memory.
Another way to do the same thing - open /dev/mem and call mmap() at zero offset.
___
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: doscmd under 8-stable, anyone?
As Kostik Belousov wrote: > Do sysctl security.bsd.map_at_zero=1 Just for the record, this sysctl also makes my really really old utree binary work again. The binary dates back to 386BSD 0.0, and I'm only keeping it out of curiosity: j@uriah 66% ls -l /usr/local/bin/utree -rwxr-xr-x 1 bin bin 179639 Apr 30 1992 /usr/local/bin/utree* The only thing to make it run is to use a termcap entry that is smaller than 1024 byte, as this used to be a hard-coded limitation in the termcap library of those days, and the binary is statically linked. TERM=vt100 works, xterm no longer does. The ability to run this binary only serves as a proof that no backward compatibility has ever been broken in FreeBSD. ;-) (Obviously, all the various COMPAT_* options must be present in the kernel config.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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: doscmd under 8-stable, anyone?
As Kostik Belousov wrote: > > So does anyone have an idea > > why this mmap() call: ... > > yields an EINVAL now under 8-stable? > > Do sysctl security.bsd.map_at_zero=1 Ah, thanks! Now it works. Well, at least it doesn't crash anymore (I somehow have to fix my boot environment, hopefully I'll be able to perform a fresh installation of FreeDOS there.) So I guess this should be added to doscmd's documentation then. As Jeremy Chadwick wrote: > I'm not sure why a person would need or want MAP_FIXED in this > situation; why can't they just take the result of mmap() (a void *) and > use that as a base address offset instead of assuming zero in their > software? Because MS-DOS utilities are written in the assumption of running at address 0 (or only slightly beyond). Remember, this mmap() maps the MS-DOS emulator base memory (that's why it is fatal if the allocation fails). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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: doscmd under 8-stable, anyone?
Hi Joerg,
Flip security.bsd**.map_at_zero to 1.
On Wed, Jun 15, 2011 at 3:57 PM, Joerg Wunsch <
freebsd-sta...@uriah.heep.sax.de> wrote:
> When trying to use doscmd on 8-stable, all I get is:
>
> Error mapping HMA, HMA disabled: : Invalid argument
> Segmentation fault (core dumped)
>
> The segfault happens at the end of mem_init(), when the allocated DOS
> memory (which is located at virtual address 0) is attempted to be
> written to. Apparently, the mmap() failure that causes the "HMA
> disabled" message is actually a fatal error rather than a benign one
> the could be ignored, as it results in no valid DOS memory allocation
> at all.
>
> Right now, the only older system I could test it against uses FreeBSD
> 5.x, where the mmap() works as expected. So does anyone have an idea
> why this mmap() call:
>
>if (mmap((caddr_t)0x00, 0x10,
> PROT_EXEC | PROT_READ | PROT_WRITE,
> MAP_ANON | MAP_FIXED | MAP_SHARED,
> -1, 0) == MAP_FAILED) {
>perror("Error mapping HMA, HMA disabled: ");
>HMA_a20 = -1;
>close(HMA_fd_off);
>close(HMA_fd_on);
>return;
>}
>
> yields an EINVAL now under 8-stable?
>
> --
> cheers, J"org .-.-. --... ...-- -.. . DL8DTL
>
> http://www.sax.de/~joerg/NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
> ___
> 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"
>
--
Good, fast & cheap. Pick any two.
___
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: doscmd under 8-stable, anyone?
On Wed, Jun 15, 2011 at 03:57:05PM +0200, Joerg Wunsch wrote:
> When trying to use doscmd on 8-stable, all I get is:
>
> Error mapping HMA, HMA disabled: : Invalid argument
> Segmentation fault (core dumped)
>
> The segfault happens at the end of mem_init(), when the allocated DOS
> memory (which is located at virtual address 0) is attempted to be
> written to. Apparently, the mmap() failure that causes the "HMA
> disabled" message is actually a fatal error rather than a benign one
> the could be ignored, as it results in no valid DOS memory allocation
> at all.
>
> Right now, the only older system I could test it against uses FreeBSD
> 5.x, where the mmap() works as expected. So does anyone have an idea
> why this mmap() call:
>
> if (mmap((caddr_t)0x00, 0x10,
>PROT_EXEC | PROT_READ | PROT_WRITE,
>MAP_ANON | MAP_FIXED | MAP_SHARED,
>-1, 0) == MAP_FAILED) {
> perror("Error mapping HMA, HMA disabled: ");
> HMA_a20 = -1;
> close(HMA_fd_off);
> close(HMA_fd_on);
> return;
> }
>
> yields an EINVAL now under 8-stable?
Do sysctl security.bsd.map_at_zero=1
pgps0JeiyjSft.pgp
Description: PGP signature
Re: doscmd under 8-stable, anyone?
On Wed, Jun 15, 2011 at 03:57:05PM +0200, Joerg Wunsch wrote:
> When trying to use doscmd on 8-stable, all I get is:
>
> Error mapping HMA, HMA disabled: : Invalid argument
> Segmentation fault (core dumped)
>
> The segfault happens at the end of mem_init(), when the allocated DOS
> memory (which is located at virtual address 0) is attempted to be
> written to. Apparently, the mmap() failure that causes the "HMA
> disabled" message is actually a fatal error rather than a benign one
> the could be ignored, as it results in no valid DOS memory allocation
> at all.
>
> Right now, the only older system I could test it against uses FreeBSD
> 5.x, where the mmap() works as expected. So does anyone have an idea
> why this mmap() call:
>
> if (mmap((caddr_t)0x00, 0x10,
>PROT_EXEC | PROT_READ | PROT_WRITE,
>MAP_ANON | MAP_FIXED | MAP_SHARED,
>-1, 0) == MAP_FAILED) {
> perror("Error mapping HMA, HMA disabled: ");
> HMA_a20 = -1;
> close(HMA_fd_off);
> close(HMA_fd_on);
> return;
> }
>
> yields an EINVAL now under 8-stable?
Based on what I can determine from the mmap(2) man page:
MAP_FIXED Do not permit the system to select a different address
than the one specified. If the specified address can-
not be used, mmap() will fail. If MAP_FIXED is speci-
fied, addr must be a multiple of the pagesize. If a
MAP_FIXED request is successful, the mapping estab-
lished by mmap() replaces any previous mappings for the
process' pages in the range from addr to addr + len.
Use of this option is discouraged.
[EINVAL] MAP_FIXED was specified and the addr argument was not
page aligned, or part of the desired address space
resides out of the valid address space for a user
process.
I imagine that the page size ordeal is probably what's biting you. Now,
I'm not sure if page size in that above context refers to "kernel page
size" (e.g. hw.pagesizes or hw.pagesize) or if it refers to "a page of
memory" as in what libc/malloc uses.
I'm not sure why a person would need or want MAP_FIXED in this
situation; why can't they just take the result of mmap() (a void *) and
use that as a base address offset instead of assuming zero in their
software?
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
doscmd under 8-stable, anyone?
When trying to use doscmd on 8-stable, all I get is:
Error mapping HMA, HMA disabled: : Invalid argument
Segmentation fault (core dumped)
The segfault happens at the end of mem_init(), when the allocated DOS
memory (which is located at virtual address 0) is attempted to be
written to. Apparently, the mmap() failure that causes the "HMA
disabled" message is actually a fatal error rather than a benign one
the could be ignored, as it results in no valid DOS memory allocation
at all.
Right now, the only older system I could test it against uses FreeBSD
5.x, where the mmap() works as expected. So does anyone have an idea
why this mmap() call:
if (mmap((caddr_t)0x00, 0x10,
PROT_EXEC | PROT_READ | PROT_WRITE,
MAP_ANON | MAP_FIXED | MAP_SHARED,
-1, 0) == MAP_FAILED) {
perror("Error mapping HMA, HMA disabled: ");
HMA_a20 = -1;
close(HMA_fd_off);
close(HMA_fd_on);
return;
}
yields an EINVAL now under 8-stable?
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
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: gpt labels for zfs partitions don't appear in /dev/gpt
W dniu 2011-06-15 14:12, Andrey V. Elsukov pisze:
On 15.06.2011 15:43, Bartosz Stec wrote:
As you see I have ada{0-2}p3 labeled as disk{0-2} All labeled partitions have
valid gpt id but
zfs partitions don't have accesible gpt label in /dev/gpt:
It always worked so. Read geom(4) manual page, especially about SPOILING.
Ah, I see your point now.
As you see labels was firstly seen, but removed at the end. I tried to set
blank label and then
correct one again, but no luck.
Any ideas what's possibly wrong here?
There are two reasons:
1. glabel does not create providers for providers which are already in use.
2. `gpart modify` does not touch partition provider and it is not spoiled and
retasted.
Problem appeared after my pool was broken and I imported it from some boot CD to fix
this by "import
-F".
Now I have unreadable output from zpool commands, like this:
NAMESTATE READ WRITE
CKSUM
zroot ONLINE 0 0
0
raidz1-0 ONLINE 0 0
0
gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE 0 0
0
gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE 0 0
0
gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE 0 0
0
You can disable gptids and this output will be changed back:
echo kern.geom.label.gptid.enable="0">> /boot/loader.conf
Yes, indeed it did the trick. Thank you for your detailed explanation.
--
Bartosz Stec
___
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: gpt labels for zfs partitions don't appear in /dev/gpt
On 15.06.2011 15:43, Bartosz Stec wrote:
> As you see I have ada{0-2}p3 labeled as disk{0-2} All labeled partitions have
> valid gpt id but
> zfs partitions don't have accesible gpt label in /dev/gpt:
It always worked so. Read geom(4) manual page, especially about SPOILING.
> As you see labels was firstly seen, but removed at the end. I tried to set
> blank label and then
> correct one again, but no luck.
> Any ideas what's possibly wrong here?
There are two reasons:
1. glabel does not create providers for providers which are already in use.
2. `gpart modify` does not touch partition provider and it is not spoiled and
retasted.
> Problem appeared after my pool was broken and I imported it from some boot CD
> to fix this by "import
> -F".
>
> Now I have unreadable output from zpool commands, like this:
>
> NAMESTATE READ WRITE
> CKSUM
> zroot ONLINE 0 0
>0
> raidz1-0 ONLINE 0 0
>0
> gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE 0 0
>0
> gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE 0 0
>0
> gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE 0 0
>0
>
You can disable gptids and this output will be changed back:
echo kern.geom.label.gptid.enable="0" >> /boot/loader.conf
--
WBR, Andrey V. Elsukov
___
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"
gpt labels for zfs partitions don't appear in /dev/gpt
Hi list,
please take a look at this:
#gpart show
=> 34 80293181 ada0 GPT (38G)
34 128 1 freebsd-boot (64k)
162 2097152 2 freebsd-swap (1.0G)
2097314 76068013 3 freebsd-zfs (36G)
78165327 2127888- free - (1.0G)
=> 34 78165293 ada1 GPT (37G)
34 128 1 freebsd-boot (64k)
162 2097152 2 freebsd-swap (1.0G)
2097314 76068013 3 freebsd-zfs (36G)
=> 34 80293181 ada2 GPT (38G)
34 128 1 freebsd-boot (64k)
162 2097152 2 freebsd-swap (1.0G)
2097314 76068013 3 freebsd-zfs (36G)
78165327 2127888- free - (1.0G)
# gpart show -l
=> 34 80293181 ada0 GPT (38G)
34 128 1 (null) (64k)
162 2097152 2 swap0 (1.0G)
2097314 76068013 3 disk0 (36G)
78165327 2127888- free - (1.0G)
=> 34 78165293 ada1 GPT (37G)
34 128 1 (null) (64k)
162 2097152 2 swap1 (1.0G)
2097314 76068013 3 disk1 (36G)
=> 34 80293181 ada2 GPT (38G)
34 128 1 (null) (64k)
162 2097152 2 swap2 (1.0G)
2097314 76068013 3 disk2 (36G)
78165327 2127888- free - (1.0G)
As you see I have ada{0-2}p3 labeled as disk{0-2}
All labeled partitions have valid gpt id but zfs partitions don't have
accesible gpt label in /dev/gpt:
# glabel list
Geom name: ada0p1
Providers:
1. Name: gptid/fe8c7129-bc68-11df-8955-0050dad823cd
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 128
length: 65536
index: 0
Consumers:
1. Name: ada0p1
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
Geom name: ada0p2
Providers:
1. Name: gpt/swap0
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 82944
Mode: r1w1e1
secoffset: 0
offset: 0
seclength: 2097152
length: 1073741824
index: 0
Consumers:
1. Name: ada0p2
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 82944
Mode: r1w1e2
Geom name: ada0p3
Providers:
1. Name: gptid/2ea57c66-bc69-11df-8955-0050dad823cd
Mediasize: 38946822656 (36G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1073824768
Mode: r1w1e1
secoffset: 0
offset: 0
seclength: 76068013
length: 38946822656
index: 0
Consumers:
1. Name: ada0p3
Mediasize: 38946822656 (36G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1073824768
Mode: r1w1e2
Geom name: ada1p1
Providers:
1. Name: gptid/060c432a-6852-11df-a16c-0050dad823cd
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 128
length: 65536
index: 0
Consumers:
1. Name: ada1p1
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
Geom name: ada1p2
Providers:
1. Name: gpt/swap1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 82944
Mode: r1w1e1
secoffset: 0
offset: 0
seclength: 2097152
length: 1073741824
index: 0
Consumers:
1. Name: ada1p2
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 82944
Mode: r1w1e2
Geom name: ada1p3
Providers:
1. Name: gptid/5bc92016-6852-11df-a16c-0050dad823cd
Mediasize: 38946822656 (36G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1073824768
Mode: r1w1e1
secoffset: 0
offset: 0
seclength: 76068013
length: 38946822656
index: 0
Consumers:
1. Name: ada1p3
Mediasize: 38946822656 (36G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1073824768
Mode: r1w1e2
Geom name: ada2p1
Providers:
1. Name: gptid/c506cc78-bc3a-11df-8066-0050dad823cd
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 128
length: 65536
index: 0
Consumers:
1. Name: ada2p1
Mediasize: 65536 (64k)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 17408
Mode: r0w0e0
Geom name: ada2p2
Providers:
1. Name: gpt/swap2
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Stripesize: 0
Re: Networking - CARP interfaces
On Tue, 14 Jun 2011 17:01:21 -0400, Steve Polyack wrote: I'll just have to adapt and ensure they have the same IP addresses then. I have a suspicion that the important part may be the number of IP addresses on the CARP interface. If CARP sends an advertisement from each IP alias on a CARP interface, then I think that would explain what you are seeing - and also possibly give you a workaround by adding two more bogus IPs on your primary datacenter firewalls (where IPs W and Z are normally missing). - Steve I'll give it a try, although I think in a scenario where the carp interfaces have the same number of IPs and these IPs differ, both interfaces will claim mastership. Will post results. Now that I look at the spec, it looks like both the count and the addresses themselves are provided in VRRP packets. CARP likely does the same. I can't speak for whether these things are considered along with the VHID and password, but it's worth a shot. I think you are correct, though. CARP does the same and should you have different IP addresses on the master/backup machines they will misbehave. I think the way to solve this issue is to split the two other IP addresses onto a separate carpN interface... -- Kind regards Daniel ___ 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: em0 watchdog timeouts on 8-STABLE
On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick wrote: > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: > > I recently updated my server to the latest 8-STABLE, and upgraded to v28 > > ZFS. I have not had these problems on any other version of 8-STABLE or > > 7-STABLE, which this box was upgraded from some time ago. > > > > Now, during my weekly scrub, I get the following messages and em0 is > > unresponsive: > > > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP > > > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog > > timeouts start occurring pretty quickly once I/O ramps up. > > > > Here's some possibly relevant information, let me know if anything else > > would be helpful to troubleshoot. > > > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE > #17: > > Mon Jun 6 19:40:19 EDT 2011 > > r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN > > amd64 > > > > em0: port > 0xe800-0xe83f > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on > pci7 > > > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > > class = network > > subclass = ethernet > > > > And, the SAS cards: > > > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.0.%driver: mpt > > dev.mpt.0.%location: slot=0 function=0 > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > subdevice=0xa580 class=0x01 > > dev.mpt.0.%parent: pci1 > > dev.mpt.0.debug: 3 > > dev.mpt.0.role: 1 > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.1.%driver: mpt > > dev.mpt.1.%location: slot=0 function=0 > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > subdevice=0xa580 class=0x01 > > dev.mpt.1.%parent: pci2 > > dev.mpt.1.debug: 3 > > dev.mpt.1.role: 1 > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.2.%driver: mpt > > dev.mpt.2.%location: slot=0 function=0 > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 > > subdevice=0x30a0 class=0x01 > > dev.mpt.2.%parent: pci6 > > dev.mpt.2.debug: 3 > > dev.mpt.2.role: 1 > > Please provide output from the following commands (as root): > > # pciconf -lvcb > hostb0@pci0:0:0:0: class=0x06 card=0x59561002 chip=0x59561002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 GFX Dual Slot' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx0 port A)' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx0 port B)' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' class = bridge subclass = PCI-PCI pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' class = bridge subclass = PCI-PCI pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' class = bridge subclass = PCI-PCI pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx1 port A)' class = bridge subclass = PCI-PCI atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 Serial ATA Controller' class = mass storage subclass = ATA ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devic
Re: em0 watchdog timeouts on 8-STABLE
On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: > I recently updated my server to the latest 8-STABLE, and upgraded to v28 > ZFS. I have not had these problems on any other version of 8-STABLE or > 7-STABLE, which this box was upgraded from some time ago. > > Now, during my weekly scrub, I get the following messages and em0 is > unresponsive: > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog > timeouts start occurring pretty quickly once I/O ramps up. > > Here's some possibly relevant information, let me know if anything else > would be helpful to troubleshoot. > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE #17: > Mon Jun 6 19:40:19 EDT 2011 > r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN > amd64 > > em0: port 0xe800-0xe83f > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on pci7 > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > > And, the SAS cards: > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter > dev.mpt.0.%driver: mpt > dev.mpt.0.%location: slot=0 function=0 > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > subdevice=0xa580 class=0x01 > dev.mpt.0.%parent: pci1 > dev.mpt.0.debug: 3 > dev.mpt.0.role: 1 > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter > dev.mpt.1.%driver: mpt > dev.mpt.1.%location: slot=0 function=0 > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > subdevice=0xa580 class=0x01 > dev.mpt.1.%parent: pci2 > dev.mpt.1.debug: 3 > dev.mpt.1.role: 1 > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter > dev.mpt.2.%driver: mpt > dev.mpt.2.%location: slot=0 function=0 > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 > subdevice=0x30a0 class=0x01 > dev.mpt.2.%parent: pci6 > dev.mpt.2.debug: 3 > dev.mpt.2.role: 1 Please provide output from the following commands (as root): # pciconf -lvcb # vmstat -i # sysctl -a | grep msi # dmesg -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
em0 watchdog timeouts on 8-STABLE
I recently updated my server to the latest 8-STABLE, and upgraded to v28 ZFS. I have not had these problems on any other version of 8-STABLE or 7-STABLE, which this box was upgraded from some time ago. Now, during my weekly scrub, I get the following messages and em0 is unresponsive: Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP My scrub is scheduled to start at 03:00:00, so it looks like watchdog timeouts start occurring pretty quickly once I/O ramps up. Here's some possibly relevant information, let me know if anything else would be helpful to troubleshoot. FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN amd64 em0: port 0xe800-0xe83f mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on pci7 em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet And, the SAS cards: dev.mpt.0.%desc: LSILogic SAS/SATA Adapter dev.mpt.0.%driver: mpt dev.mpt.0.%location: slot=0 function=0 dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 subdevice=0xa580 class=0x01 dev.mpt.0.%parent: pci1 dev.mpt.0.debug: 3 dev.mpt.0.role: 1 dev.mpt.1.%desc: LSILogic SAS/SATA Adapter dev.mpt.1.%driver: mpt dev.mpt.1.%location: slot=0 function=0 dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 subdevice=0xa580 class=0x01 dev.mpt.1.%parent: pci2 dev.mpt.1.debug: 3 dev.mpt.1.role: 1 dev.mpt.2.%desc: LSILogic SAS/SATA Adapter dev.mpt.2.%driver: mpt dev.mpt.2.%location: slot=0 function=0 dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 subdevice=0x30a0 class=0x01 dev.mpt.2.%parent: pci6 dev.mpt.2.debug: 3 dev.mpt.2.role: 1 -- Joshua Boyd JBipNet E-mail: boy...@jbip.net Cell: (513) 375-0157 http://www.jbip.net ___ 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"
