Re: ULE realtime scheduler advice needed
On 11/22/2022 5:00 PM, Tomoaki AOKI wrote:
A long shot, but I am curious if by chance you have hwpstate_intel for
your cpu frequency driver. If so, does setting
dev.hwpstate_intel.0.epp=0 make any difference ?
Yes, I have four of those, set to 50 by default. Let me try.
--HPS
FYI: I habitally run below manually (as root) when I'm on AC powerline.
sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
sysctl ${OID}=0 ; done
It was a bit of a POLA the first time I encountered this driver going
from 12 to RELENG_13. Same hardware behaved rather differently as its a
different power profile default than what I expected and for my use case
(firewall and router) it was causing dropped packets
---Mike
Re: ULE realtime scheduler advice needed
On 11/17/2022 11:47 PM, Hans Petter Selasky wrote: Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. Or is this perhaps a CPU frequency stepping issue? Any advice on where to look? A long shot, but I am curious if by chance you have hwpstate_intel for your cpu frequency driver. If so, does setting dev.hwpstate_intel.0.epp=0 make any difference ? ---Mike
make install[kernel|world] from read only /usr/obj possible ?
On RELENG_12, I was able to mount via NFS /usr/obj and src and do an
installworld on read only mounts. However, with RELENG_13 and above, I
get permission denied errors. The install seems to continue just fine,
but I am not sure if something subtle is being missed. Looking at what
gets installed, the kernel modules get installed just fine. However, it
seems installworld has some problems with static libs (.a files). They
dont seem to get re-installed. However, not sure if thats by design as
doing a quick checksum, there is no difference on the build server and
target of the ~ 700 .a files I checked in /usr/lib32 and /usr/lib. So
despite the time stamps being off, maybe it just does not bother to
update the target if they have not changed?
e.g.
make KERNCONF=vtnet installkernel
make warning: /usr/obj/usr/src: Permission denied.
make[1] warning: /usr/src/: Permission denied.
make[2] warning: /usr/obj/usr/src/amd64.amd64: Permission denied.
--
>>> Install check kernel
--
--
>>> Installing kernel vtnet on Tue May 24 13:50:52 EDT 2022
--
cd /usr/obj/usr/src/amd64.amd64/sys/vtnet; MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.1
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++ -target
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="cpp -target
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar"
ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy"
RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip"
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
make KERNEL=kernel install
make[2] warning: /usr/obj/usr/src/amd64.amd64/sys/vtnet: Permission denied.
thiskernel=`sysctl -n kern.bootfile || echo /boot/kernel/kernel` ; if [
! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg
/boot/kernel ; rm -rf /boot/kernel ; rm -rf /usr/lib/debug/boot/kernel
; else if [ -d /boot/kernel.old ] ; then chflags -R noschg
/boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel
/boot/kernel.old ; if [ -n "/usr/lib/debug" -a -d
/usr/lib/debug/boot/kernel ]; then rm -rf
/usr/lib/debug/boot/kernel.old ; mv /usr/lib/debug/boot/kernel
/usr/lib/debug/boot/kernel.old ; fi ; sysctl
kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi
kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel/
mkdir -p /usr/lib/debug/boot/kernel
install -p -m 555 -o root -g wheel kernel.debug /usr/lib/debug/boot/kernel/
cd /usr/src/sys/modules;
MAKEOBJDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules
KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 MACHINE=amd64
MACHINE_ARCH=amd64 MODULES_EXTRA="" WITHOUT_MODULES="" ARCH_FLAGS=""
DEBUG_FLAGS="-g" __MPATH=""
KERNBUILDDIR="/usr/obj/usr/src/amd64.amd64/sys/vtnet"
SYSDIR="/usr/src/sys" MODULE_TIED=yes WITH_CTF="1" KCSAN_ENABLED="yes"
COMPAT_FREEBSD32_ENABLED="yes" make install
make[3] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules:
Permission denied.
===> aac (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aac:
Permission denied.
install -T release -o root -g wheel -m 555 aac.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 aac.ko.debug
/usr/lib/debug/boot/kernel/
===> aacraid (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aacraid:
Permission denied.
install -T release -o root -g wheel -m 555 aacraid.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 aacraid.ko.debug
/usr/lib/debug/boot/kernel/
===> accf_data (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/accf_data:
Permission denied.
eg.
0{git}% ls -l /usr/lib32/libhei*
-r--r--r-- 1 root wheel - 53622 Mar 17 20:02 /usr/lib32/libheimbase.a
lrwxr-xr-x 1 root wheel - 17 May 24 17:11
/usr/lib32/libheimbase.so -> libheimbase.so.11
-r--r--r-- 1 root wheel - 13224 May 24 17:11 /usr/lib32/libheimbase.so.11
-r--r--r-- 1 root wheel - 54966 Mar 17 20:02 /usr/lib32/libheimbase_p.a
-r--r--r-- 1 root wheel - 67598 Mar 17 20:02 /usr/lib32/libheimntlm.a
lrwxr-xr-x 1 root wheel - 17 May 24 17:11
Re: observations on Ryzen 5xxx (Zen 3) processors
On 1/4/2022 11:56 AM, tech-lists wrote: On Tue, Jan 04, 2022 at 02:06:43PM +, tech-lists wrote: Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=e67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current/14) Can't build lang/perl5.32. I have many vms running perl5.32 and they're not seeing any issues. There's nothing in bugs suggesting there's an issue with this port right now. I would for sure try a clean src.conf first and use that as a baseline. Also, someome mentioned trying machdep.idle=spin In /boot/loader.conf But removing your src.conf optimizations would be the first place to try ---Mike
Re: ZFS feature compatibility?
On 1/25/2021 4:51 PM, John Kennedy wrote: > On Mon, Jan 25, 2021 at 04:17:18PM -0500, mike tancsa wrote: >> Is there a way to check from the bin if its the right version ? strings >> of the file doesnt seem to show anything useful. I wonder if its the >> UEFI boot that got missed ? Just >> >> gpart bootcode -p /boot/boot1.efifat -i 1ada8 >> gpart bootcode -p /boot/boot1.efifat -i 1ada9 >> >> I take it ? > I don't think that is the way to update UEFI anymore (although last time I > looked it was still documented that way in one place). > > For my last bootcode (which had UEFI & BIOS) update, I basically did this: > > gpart show nvd0 > => 40 976773088 nvd0 GPT (466G) >40 409600 1 efi (200M) >409640 1024 2 freebsd-boot (512K) >410664984- free - (492K) >411648 16777216 3 freebsd-swap (8.0G) > 17188864 959584256 4 freebsd-zfs (458G) > 976773120 8- free - (4.0K) > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd0 > partcode written to nvd0p2 > bootcode written to nvd0 > > mount -vt msdosfs /dev/nvd0p1 /mnt > /dev/nvd0p1 on /mnt (msdosfs, local, writes: sync 1 async 0, > reads: sync 13 async 0, fsid 5c003200) > install -p -m755 /boot/loader.efi /mnt/efi/boot/BOOTx64.efi > umount -v /mnt > /dev/nvd0p1: unmount from /mnt Thanks, I am new to the EFI world. Does the name now have to be BOOTx64.efi ? root@zoo2:/boot # ls -l /mnt/EFI/freebsd/ total 824 -rwxr-xr-x 1 root wheel 843776 Nov 21 10:50 loader.efi root@zoo2:/boot # ---Mike > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
On 1/25/2021 4:03 PM, Toomas Soome wrote:
>
>
>> On 25. Jan 2021, at 22:15, mike tancsa > <mailto:m...@sentex.net>> wrote:
>>
>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>
>>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current
>>>> mailto:freebsd-current@freebsd.org>>
>>>> wrote:
>>>>
>>>> I have a few machines on which I've been hesitant to run 'zpool
>>>> upgrade' as I'm not sure of the (boot?) implications. They report
>>>> like this ..
>>>>
>>>> imb@toshi:/home/imb> uname -a
>>>> FreeBSD toshi.auburn.protected-networks.net
>>>> <http://toshi.auburn.protected-networks.net> 14.0-CURRENT FreeBSD
>>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
>>>> r...@toshi.auburn.protected-networks.net
>>>> <mailto:r...@toshi.auburn.protected-networks.net>:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>> amd64
>>>>
>>>> imb@toshi:/home/imb> zpool status
>>>> pool: zroot
>>>> state: ONLINE
>>>> status: Some supported features are not enabled on the pool. The
>>>> pool can
>>>> still be used, but some features are unavailable.
>>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>>> the pool may no longer be accessible by software that does
>>>> not support
>>>> the features. See zpool-features(5) for details.
>>>>
>>>> Is it safe to upgrade the root pool?
>>>>
>>>> imb
>>> We can not boot from encrypted pool and draid. Rest is all ok.
>>> Please note, you may need to update the bootblocks.
>>>
>> last Friday on zoo.freebsd.org
>> <http://zoo.freebsd.org/>, m...@freebsd.org
>> <mailto:m...@freebsd.org> and I could not boot
>> again because v2 bookmarks were on the boot pool. I had to boot from
>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>> (stable/13-c256203-g51d73a3e46c)
>>
>> —Mike
>
> /*
> * List of ZFS features supported for read
> */
> static const char *features_for_read[] = {
> "org.illumos:lz4_compress",
> "com.delphix:hole_birth",
> "com.delphix:extensible_dataset",
> "com.delphix:embedded_data",
> "org.open-zfs:large_blocks",
> "org.illumos:sha512",
> "org.illumos:skein",
> "org.zfsonlinux:large_dnode",
> "com.joyent:multi_vdev_crash_dump",
> "com.delphix:spacemap_histogram",
> "com.delphix:zpool_checkpoint",
> "com.delphix:spacemap_v2",
> "com.datto:encryption",
> "com.datto:bookmark_v2",
> "org.zfsonlinux:allocation_classes",
> "com.datto:resilver_defer",
> "com.delphix:device_removal",
> "com.delphix:obsolete_counts",
> "com.intel:allocation_classes",
> "org.freebsd:zstd_compress",
> "com.delphix:bookmark_written",
> NULL
> };
>
> Are you sure you have bootblocks updated? ESP for UEFI boot and
> freebsd-boot for BIOS boot.
>
>
mjg did them IIRC. I just checked to make sure both were done and they
seem identical
root@zoo2:/home/mdtancsa # dd if=/dev/ada8p2 of=/tmp/8
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.046479 secs (11280092 bytes/sec)
root@zoo2:/home/mdtancsa # dd if=/dev/ada9p2 of=/tmp/9
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.054717 secs (9581751 bytes/sec)
root@zoo2:/home/mdtancsa # md5 /tmp/8 /tmp/9
MD5 (/tmp/8) = e294b1344cbb49c751474facc39998ec
MD5 (/tmp/9) = e294b1344cbb49c751474facc39998ec
root@zoo2:/home/mdtancsa #
Is there a way to check from the bin if its the right version ? strings
of the file doesnt seem to show anything useful. I wonder if its the
UEFI boot that got missed ? Just
gpart bootcode -p /boot/boot1.efifat -i 1ada8
gpart bootcode -p /boot/boot1.efifat -i 1ada9
I take it ?
MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f
root@zoo2:/boot # dd if=/dev/ada9p1 of=/tmp/91 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.557007 secs (376503669 bytes/sec)
root@zoo2:/boot # dd if=/dev/ada8p1 of=/tmp/81 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.475806 secs (440757874 bytes/sec)
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1
boot1 boot1.efi*
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1.efi
MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f
I am guessing they extracted boot blocks should match, no ?
---Mike
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote: > >> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current >> wrote: >> >> I have a few machines on which I've been hesitant to run 'zpool upgrade' as >> I'm not sure of the (boot?) implications. They report like this .. >> >> imb@toshi:/home/imb> uname -a >> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD >> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 >> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI >> amd64 >> >> imb@toshi:/home/imb> zpool status >> pool: zroot >> state: ONLINE >> status: Some supported features are not enabled on the pool. The pool can >>still be used, but some features are unavailable. >> action: Enable all features using 'zpool upgrade'. Once this is done, >>the pool may no longer be accessible by software that does not support >>the features. See zpool-features(5) for details. >> >> Is it safe to upgrade the root pool? >> >> imb > We can not boot from encrypted pool and draid. Rest is all ok. Please note, > you may need to update the bootblocks. > last Friday on zoo.freebsd.org, m...@freebsd.org and I could not boot again because v2 bookmarks were on the boot pool. I had to boot from another disk, remove the bookmarks and then boot. This was on RELENG_13 (stable/13-c256203-g51d73a3e46c) ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
I ran into an issue not being able to boot because of v2 bookmarks on the boot pool on RELENG_13 just last Friday. ---Mike On 1/25/2021 2:31 PM, Michael Butler via freebsd-current wrote: > I have a few machines on which I've been hesitant to run 'zpool > upgrade' as I'm not sure of the (boot?) implications. They report like > this .. > > imb@toshi:/home/imb> uname -a > FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD > 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 > r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI > amd64 > > imb@toshi:/home/imb> zpool status > pool: zroot > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not > support > the features. See zpool-features(5) for details. > > Is it safe to upgrade the root pool? > > imb > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/9/2020 7:32 AM, Lev Serebryakov wrote:
> On 07.11.2020 2:46, Eric Joyner wrote:
>
>> The other issue is that I still don't know which devices need a
>> restart / which devices do not, or whether a restart is strictly
>> necessary and if there is another way to do this without worrying
>> about restarting the device.
> Could this be copied from pre-iflib driver? It did right things
> without unneeded resets, including some `em` chips.
>
> BTW, I'm surprised, that pre-iflib drivers still available on Intel
> site and in ports. And sometimes works better :-(
>
For my specific case (no DHCLIENT and I210 chipset), I just used
--- if_em.c 2020-09-26 07:46:16.474942000 -0400
+++ /tmp/if_em.c 2020-11-09 08:13:55.888378000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And that seems to work for my particular chipset and use case.
---Mike
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 5:32 PM, Eric Joyner wrote:
> Could you reply to that issue with what you've found?
>
> Though, as far as I can recall, igb(4) devices are not supposed to do
> the iflib reset talked about in the bug, so I wouldn't expect to see a
> link flap on those.
>
Hi Eric,
I have added my findings to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
I tried it on 3 different vendor's boards. All I210 variants it seems.
I am testing with
--- if_em.c 2020-11-06 15:00:22.120953000 -0500
+++ /tmp/if_em.c 2020-11-06 14:59:55.678195000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And if fixes the problem, but not quite sure if it introduces any
regressions or other issues ?
---Mike
> - Eric
>
> On Fri, Nov 6, 2020 at 12:48 PM mike tancsa <mailto:m...@sentex.net>> wrote:
>
> On 11/6/2020 2:17 PM, mike tancsa wrote:
> > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >> Hello Ian,
> >>
> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >>
> >>> I noticed that my VLAN interfaces stopped working after a
> recent build.
> >>> tcpdump showed traffic leaving leaving and entering the
> interface but no
> >>> host on the network actually received any packets from this
> host. A
> >>> binary search led me to r360902 and indeed the following
> change fixed
> >>> the issue for me:
> >> Problem is, this change will return terrible situation when
> adding new VLAN
> >> will flap connection status.
> >>
> >> It all worked before iflib: hardware VLAN filtering worked, and
> >> adding/removing new VLAN didn't cause link to flap.
> >>
> >> Now, with iflib, looks like we can not have all good things at
> once :(
>
>
> Looks like this is captured in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818>
>
>
> > Hi All,
> >
> > Just came across this thread as I am running into this behaviour on
> > RELENG_12. Adding a new vlan causes all vlans on the parent
> interface
> > to flap. Not the greatest thing as it bounces a LOT of traffic
> > potentially, flaps routing etc. Is there a way around this ?
> >
> > This is on r367411 releng12
> >
> > igb0@pci0:2:0:0: class=0x02 card=0x153315d9
> chip=0x15338086
> > rev=0x03 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'I210 Gigabit Network Connection'
> > class = network
> > subclass = ethernet
> >
> > eg. just something simple like
> >
> > ifconfig vlan16 create 10.1.2.3/29 <http://10.1.2.3/29> vlandev
> igb1 vlan 16
> >
> > # dmesg | tail -8
> > igb1: link state changed to DOWN
> > vlan16: link state changed to DOWN
> > vlan2049: link state changed to DOWN
> > vlan15: link state changed to DOWN
> > igb1: link state changed to UP
> > vlan16: link state changed to UP
> > vlan2049: link state changed to UP
> > vlan15: link state changed to UP
> >
> >
> > ---Mike
> >
> >
> >
> >
> > ___
> > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> > To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
> >
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 2:17 PM, mike tancsa wrote: > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: >> Hello Ian, >> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: >> >>> I noticed that my VLAN interfaces stopped working after a recent build. >>> tcpdump showed traffic leaving leaving and entering the interface but no >>> host on the network actually received any packets from this host. A >>> binary search led me to r360902 and indeed the following change fixed >>> the issue for me: >> Problem is, this change will return terrible situation when adding new VLAN >> will flap connection status. >> >> It all worked before iflib: hardware VLAN filtering worked, and >> adding/removing new VLAN didn't cause link to flap. >> >> Now, with iflib, looks like we can not have all good things at once :( Looks like this is captured in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > Hi All, > > Just came across this thread as I am running into this behaviour on > RELENG_12. Adding a new vlan causes all vlans on the parent interface > to flap. Not the greatest thing as it bounces a LOT of traffic > potentially, flaps routing etc. Is there a way around this ? > > This is on r367411 releng12 > > igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I210 Gigabit Network Connection' > class = network > subclass = ethernet > > eg. just something simple like > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > # dmesg | tail -8 > igb1: link state changed to DOWN > vlan16: link state changed to DOWN > vlan2049: link state changed to DOWN > vlan15: link state changed to DOWN > igb1: link state changed to UP > vlan16: link state changed to UP > vlan2049: link state changed to UP > vlan15: link state changed to UP > > > ---Mike > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > Hello Ian, > > Thursday, May 28, 2020, 2:45:48 AM, you wrote: > >> I noticed that my VLAN interfaces stopped working after a recent build. >> tcpdump showed traffic leaving leaving and entering the interface but no >> host on the network actually received any packets from this host. A >> binary search led me to r360902 and indeed the following change fixed >> the issue for me: > Problem is, this change will return terrible situation when adding new VLAN > will flap connection status. > > It all worked before iflib: hardware VLAN filtering worked, and > adding/removing new VLAN didn't cause link to flap. > > Now, with iflib, looks like we can not have all good things at once :( Hi All, Just came across this thread as I am running into this behaviour on RELENG_12. Adding a new vlan causes all vlans on the parent interface to flap. Not the greatest thing as it bounces a LOT of traffic potentially, flaps routing etc. Is there a way around this ? This is on r367411 releng12 igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet eg. just something simple like ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 # dmesg | tail -8 igb1: link state changed to DOWN vlan16: link state changed to DOWN vlan2049: link state changed to DOWN vlan15: link state changed to DOWN igb1: link state changed to UP vlan16: link state changed to UP vlan2049: link state changed to UP vlan15: link state changed to UP ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deprecating ftpd in the FreeBSD base system?
On 9/16/2020 2:07 PM, sth...@nethelp.no wrote: > # override default of no subsystems > -Subsystemsftp/usr/libexec/sftp-server > +Subsystemsftpinternal-sftp -l INFO Hi, What is the difference between these two ? Is it not all OpenSSH ? ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current panics on connecting disks to a LSI-3108 controller
On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: > On 14-7-2020 07:45, Andriy Gapon wrote: >> On 14/07/2020 03:39, Willem Jan Withagen wrote: >>> And what I read from the manual page, mrsas plays even nicer with >>> CAM which is a >>> plus. >> If by "nicer" you mean that mfi does not integrate with CAM at all, >> then you are >> right :-) >> Also, last I looked mfi has some pretty serious bugs in its direct >> interface to >> GEOM. We've seen all kinds of crashes with mfi at work. > Right that was what I meant. > Disadvantage is that mfiutil no longer works. > But then if you JBOD, it does not really matter. > Unless it still uses caching for JBODs and then I'd like to know the > state of the > battery. > Take a look from the ports storcli or MegaCli You can do pretty well everything you need with those 2 tools to talk to mrsas attached disks eg MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 or storcli /c0 show all storcli /c0 show help storcli /c0 set jbod=on (enable jbod mode for drives) storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which AMD CPUs are supported -- temperature
On 2/13/2020 2:22 AM, Peter Jeremy wrote: > On 2020-Feb-12 15:23:51 -0500, mike tancsa wrote: >> Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I >> have seem correct as well as an APU >> >> CPU: AMD GX-412TC SOC (998.17-MHz K8-class >> CPU) > OTOH, I'm not confident about temperatures on my APU. The publicly > >> And on a fanless APU >> >> # sysctl -a dev.cpu.0.temperature >> dev.cpu.0.temperature: 62.6C >> >> # sysctl -a dev.amdtemp.0.core0.sensor0 >> dev.amdtemp.0.core0.sensor0: 63.1C > At what ambient temperature? I see a similar value from my (idle) APU3 > but don't believe the (implied) ~35K junction-to-ambient difference. Actually, it does seem a bit high. This is read from a PCEngines APU3. Since the CPU dissipates heat off the bottom metal case, I cant point my thermal laser temp reader directly at the CPU. Reading the temp off the top of the mother board with the top of the case off, I cant find any spots hotter than 35C... So 62C is probably a lot higher than it actually is. ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which AMD CPUs are supported -- temperature
On 2/12/2020 1:39 PM, Chris wrote: > Hard as I try I can not get anything close to the actual temperature > of the CPUs or cores while running on FreeBSD. > Family: Athlon X4 > Manufacturer: AuthenticAMD > Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I have seem correct as well as an APU CPU: AMD GX-412TC SOC (998.17-MHz K8-class CPU) CPU: AMD Ryzen 7 3700X 8-Core Processor (3593.33-MHz K8-class CPU) CPU: AMD Ryzen 7 2700X Eight-Core Processor (3693.17-MHz K8-class CPU) e.g. at idle # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 31.1C then start up # cat /dev/urandom | openssl sha256 # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 57.1C It agrees with what IPMI reports too from the MB # ipmitool sensor | grep "CPU Temp" CPU Temp | 31.000 | degrees C | ok | na | na | na | 93.000 | 94.000 | na And on a fanless APU # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 62.6C # sysctl -a dev.amdtemp.0.core0.sensor0 dev.amdtemp.0.core0.sensor0: 63.1C ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
On 11/30/2018 7:12 AM, O. Hartmann wrote: > > For IPv6, I only see my local linklocal address, fe80::... > > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: > linklocal address > assigned to the variable HISADDR. Somehow, the tun0 never obtains a > IPv6 aprefix so far. > > Can someone give a tip? What does you ppp.conf look like ? -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot message: sendmsg on igb0: No buffer space available
On 10/20/2018 4:31 AM, Dave Cottlehuber wrote: > On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote: >> Feeding entropy: . >> lo0: link state changed to UP >> sendmsg on igb0: No buffer space available >> igb0: link state changed to UP >> cxl1: link state changed to UP >> Starting Network: lo0 igb0 cxl0 cxl1. > I’m reasonably sure that this occurs when dhclient is trying before the > interface is available for use - is that likely in your case? Perhaps, but why the difference previous versions? Should not the interface be up'd before starting dhclient ? ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
boot message: sendmsg on igb0: No buffer space available
Since starting to test HEAD, I noticed at bootup time I get the message in dmesg sendmsg on igb0: No buffer space available It seems innocuous enough in that I dont see any obvious issues. Is it a symptom of some misconfiguration ? This originally was a releng11 box that I upgraded via source so /etc/ still has all the old bootup stuff. Speaking of which, what is the best way to update all the bootup scripts. It seems to have all changed since 11. Setting up harvesting: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . lo0: link state changed to UP sendmsg on igb0: No buffer space available igb0: link state changed to UP cxl1: link state changed to UP Starting Network: lo0 igb0 cxl0 cxl1. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot hang at r339386 (solved)
On 10/18/2018 2:50 PM, Mike Tancsa wrote: > On 10/18/2018 2:26 PM, Konstantin Belousov wrote: >> On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote: >>> On r339386 I am seeing a 100% hang at boot up time. Boot ends at >>> >>> Going back to r339385 works. But going to the next commit hangs the box >>> >>> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html >> Try the patch at https://reviews.freebsd.org/D17612 >> >> > Looks good both on my Ryzen and EPYC based boards! Thanks > Also tested on a PCEngines APU and looks good. ---<>--- Copyright (c) 1992-2018 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 12.0-ALPHA10 #4 r339418M: Thu Oct 18 14:37:48 EDT 2018 mdtan...@nanobsd2.sentex.ca:/pxe/12/obj/pxe/12/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(vga): resolution 640x480 CPU: AMD GX-412TC SOC (998.15-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x730f01 Family=0x16 Model=0x30 Stepping=1 Features=0x178bfbff Features2=0x3ed8220b AMD Features=0x2e500800 AMD Features2=0x1d4037ff Structured Extended Features=0x8 XSAVE Features=0x1 SVM: NP,NRIP,AFlush,DAssist,NAsids=8 TSC: P-state invariant, performance statistics real memory = 2012930048 (1919 MB) avail memory = 1909755904 (1821 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. ioapic1: Changing APIC ID to 5 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard Launching APs: 1 2 3 Timecounter "TSC" frequency 998147285 Hz quality 1000 random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8112ec50, 0) error 19 kbd0 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot hang at r339386 (solved)
On 10/18/2018 2:26 PM, Konstantin Belousov wrote: > On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote: >> On r339386 I am seeing a 100% hang at boot up time. Boot ends at >> >> Going back to r339385 works. But going to the next commit hangs the box >> >> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html > Try the patch at https://reviews.freebsd.org/D17612 > > Looks good both on my Ryzen and EPYC based boards! Thanks Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/amd64/pmap.c |=== |--- sys/amd64/amd64/pmap.c |+++ sys/amd64/amd64/pmap.c -- Patching file sys/amd64/amd64/pmap.c using Plan A... Hunk #1 succeeded at 637. Hunk #2 succeeded at 7099. Hunk #3 succeeded at 7143. Hunk #4 succeeded at 7156. Hunk #5 succeeded at 7325. Hunk #6 succeeded at 7448. Hunk #7 succeeded at 7478. Hunk #8 succeeded at 7506. Hunk #9 succeeded at 7521. Hunk #10 succeeded at 7530. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/include/pmap.h |=== |--- sys/amd64/include/pmap.h |+++ sys/amd64/include/pmap.h -- Patching file sys/amd64/include/pmap.h using Plan A... Hunk #1 succeeded at 430. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/pci/pci_cfgreg.c |=== |--- sys/amd64/pci/pci_cfgreg.c |+++ sys/amd64/pci/pci_cfgreg.c -- Patching file sys/amd64/pci/pci_cfgreg.c using Plan A... Hunk #1 succeeded at 271. done ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
boot hang at r339386
On r339386 I am seeing a 100% hang at boot up time. Boot ends at Copyright (c) 1992-2018 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 12.0-ALPHA10 r339415 GENERIC amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Ryzen 5 1600X Six-Core Processor (3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33255837696 (31715 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 2 cache groups x 3 core(s) x 2 hardware threads random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20181003/tbfadt-796) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard Launching APs: 10 1 2 3 9 11 8 5 7 6 4 Timecounter "TSC-low" frequency 1796668938 Hz quality 1000 random: entropy device external interface module_register_init: MOD_LOAD (vesa, 0x810e6a80, 0) error 19 kbd1 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module [ath_hal] loaded nexus0 vtvga0: on motherboard aesni0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard Adding boot verbose, shows the lines below before the hang. ACPI: 7 ACPI AML tables successfully acquired and loaded PCIe: Memory Mapped configuration base @ 0xf800 The box is hard locked up and I cannot break to debugger either. Going back to r339385 works. But going to the next commit hangs the box https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange panic at boot with vmm in loader.conf vs manually loading it
On 10/14/2018 2:19 PM, Mateusz Guzik wrote: > On 10/14/18, Mike Tancsa wrote: >> On 10/13/2018 12:48 PM, Allan Jude wrote: >>> Strange that your crash is in ZFS here... >>> >>> Can you take a crash dump? >>> >>> It looks like something is trying to write to uninitialized memory here. >> I will need to pop in another drive or can I do a netdump at this point ? >> > This should be fixed with https://svnweb.freebsd.org/changeset/base/339355 > i.e. just update. > Thanks, just tried and all is good! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange panic at boot with vmm in loader.conf vs manually loading it
On 10/13/2018 12:48 PM, Allan Jude wrote: > > Strange that your crash is in ZFS here... > > Can you take a crash dump? > > It looks like something is trying to write to uninitialized memory here. I will need to pop in another drive or can I do a netdump at this point ? ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/2018 12:52 PM, Navdeep Parhar wrote: > > The number of retries (the "Retr" column) should have been 0 in a > controlled test like this. Is this the default stack with all default > parameters or have you tuned TCP and/or sockets in any way? No tuning at all. After a reboot and one test, I am seeing a bunch of overflows. I am going to netboot back to RELENG_11 to confirm sysctl -a dev.cxl.1.stats dev.cxl.1.stats.rx_tls_octets: 0 dev.cxl.1.stats.rx_tls_records: 0 dev.cxl.1.stats.tx_tls_octets: 0 dev.cxl.1.stats.tx_tls_records: 0 dev.cxl.1.stats.rx_trunc3: 0 dev.cxl.1.stats.rx_trunc2: 12 dev.cxl.1.stats.rx_trunc1: 0 dev.cxl.1.stats.rx_trunc0: 0 dev.cxl.1.stats.rx_ovflow3: 0 dev.cxl.1.stats.rx_ovflow2: 58 dev.cxl.1.stats.rx_ovflow1: 0 dev.cxl.1.stats.rx_ovflow0: 0 dev.cxl.1.stats.rx_ppp7: 0 dev.cxl.1.stats.rx_ppp6: 0 dev.cxl.1.stats.rx_ppp5: 0 dev.cxl.1.stats.rx_ppp4: 0 dev.cxl.1.stats.rx_ppp3: 0 dev.cxl.1.stats.rx_ppp2: 0 dev.cxl.1.stats.rx_ppp1: 0 dev.cxl.1.stats.rx_ppp0: 0 dev.cxl.1.stats.rx_pause: 0 dev.cxl.1.stats.rx_frames_1519_max: 0 dev.cxl.1.stats.rx_frames_1024_1518: 6169625 dev.cxl.1.stats.rx_frames_512_1023: 473 dev.cxl.1.stats.rx_frames_256_511: 133 dev.cxl.1.stats.rx_frames_128_255: 150 dev.cxl.1.stats.rx_frames_65_127: 1015832 dev.cxl.1.stats.rx_frames_64: 4 dev.cxl.1.stats.rx_runt: 0 dev.cxl.1.stats.rx_symbol_err: 0 dev.cxl.1.stats.rx_len_err: 0 dev.cxl.1.stats.rx_fcs_err: 0 dev.cxl.1.stats.rx_jabber: 0 dev.cxl.1.stats.rx_too_long: 0 dev.cxl.1.stats.rx_ucast_frames: 7186215 dev.cxl.1.stats.rx_mcast_frames: 0 dev.cxl.1.stats.rx_bcast_frames: 2 dev.cxl.1.stats.rx_frames: 7186217 dev.cxl.1.stats.rx_octets: 9437149499 dev.cxl.1.stats.tx_ppp7: 0 dev.cxl.1.stats.tx_ppp6: 0 dev.cxl.1.stats.tx_ppp5: 0 dev.cxl.1.stats.tx_ppp4: 0 dev.cxl.1.stats.tx_ppp3: 0 dev.cxl.1.stats.tx_ppp2: 0 dev.cxl.1.stats.tx_ppp1: 0 dev.cxl.1.stats.tx_ppp0: 0 dev.cxl.1.stats.tx_pause: 222 dev.cxl.1.stats.tx_drop: 0 dev.cxl.1.stats.tx_frames_1519_max: 0 dev.cxl.1.stats.tx_frames_1024_1518: 5409152 dev.cxl.1.stats.tx_frames_512_1023: 11968 dev.cxl.1.stats.tx_frames_256_511: 162 dev.cxl.1.stats.tx_frames_128_255: 26 dev.cxl.1.stats.tx_frames_65_127: 3095205 dev.cxl.1.stats.tx_frames_64: 210 dev.cxl.1.stats.tx_error_frames: 0 dev.cxl.1.stats.tx_ucast_frames: 8516714 dev.cxl.1.stats.tx_mcast_frames: 0 dev.cxl.1.stats.tx_bcast_frames: 9 dev.cxl.1.stats.tx_frames: 8516945 dev.cxl.1.stats.tx_octets: 8434330861 dev.cxl.1.stats.tx_parse_error: 0 > Regards, > Navdeep > > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Strange panic at boot with vmm in loader.conf vs manually loading it
dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=55 powerspec 3 supports D0 D3 current D0 MSI supports 32 messages, 64 bit, vector masks MSI-X supports 40 messages in map 0x20 pci0:9:0:5: reprobing on driver added found-> vendor=0x1425, dev=0x5601, revid=0x00 domain=0, bus=9, slot=0, func=6 class=0c-04-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=52 powerspec 3 supports D0 D3 current D0 MSI supports 32 messages, 64 bit, vector masks MSI-X supports 40 messages in map 0x20 pci0:9:0:6: reprobing on driver added pci10: driver added pci11: driver added found-> vendor=0x1022, dev=0x145a, revid=0x00 domain=0, bus=11, slot=0, func=0 class=13-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 pci0:11:0:0: reprobing on driver added found-> vendor=0x1022, dev=0x1456, revid=0x00 domain=0, bus=11, slot=0, func=2 class=10-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=36 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x24 pci0:11:0:2: reprobing on driver added pci12: driver added found-> vendor=0x1022, dev=0x1455, revid=0x00 domain=0, bus=12, slot=0, func=0 class=13-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 pci0:12:0:0: reprobing on driver added AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 ivhd: ivhd0 already exists; skipping it ACPI: Processor \134_PR_.P00C (ACPI ID 13) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00D (ACPI ID 14) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00E (ACPI ID 15) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00F (ACPI ID 16) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ppc: ppc-1 already exists; skipping it driver bug: Unable to set devclass (class: ppc devname: (unknown)) Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ivhd0: on acpi0 ivhd0: Flag:b0 ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0 ivhd0: Extended features[31:0]:22294ada HATS = 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup = 0x2 DualEventLogSup = 0x2 ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f DevTblSegSup = 0x3 MarcSup = 0x1 ivhd0: supported paging level:7, will use only: 4 ivhd0: device range: 0x0 - 0x ivhd0: PCI cap 0x190b640f@0x40 feature:19 msi: routing MSI IRQ 305 to local APIC 12 vector 52 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
10G performance regression / difference cxl and ix RELENG11 vs HEAD
I was doing a quick iperf test with r339328 GENERIC-NODEBUG amd64, and noticed I can no longer saturate a 10G nic with iperf3. I tried first with the ix adapter, but was not sure if it was the driver or not. I tried as well with a Chelsio and got similar numbers. # iperf3 -c 192.168.242.3 Connecting to host 192.168.242.3, port 5201 [ 5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 997 MBytes 8.36 Gbits/sec 717 175 KBytes [ 5] 1.00-2.00 sec 975 MBytes 8.18 Gbits/sec 668 41.1 KBytes [ 5] 2.00-3.00 sec 880 MBytes 7.38 Gbits/sec 846 25.6 KBytes [ 5] 3.00-4.00 sec 523 MBytes 4.39 Gbits/sec 802 59.8 KBytes [ 5] 4.00-5.00 sec 520 MBytes 4.36 Gbits/sec 882 48.4 KBytes [ 5] 5.00-6.00 sec 543 MBytes 4.55 Gbits/sec 838 56.9 KBytes [ 5] 6.00-7.00 sec 556 MBytes 4.66 Gbits/sec 850 11.4 KBytes [ 5] 7.00-8.00 sec 538 MBytes 4.51 Gbits/sec 795 39.9 KBytes [ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 853 57.0 KBytes [ 5] 9.00-10.00 sec 503 MBytes 4.22 Gbits/sec 814 59.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec 8065 sender [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec receiver If I do a parallel transfer I get closer to the max. However, on RELENG11 I could do pretty close to a full 10G no problem with just a single stream. This is with a GENERIC-NODEBUG kernel using a couple of T520s back to back t5iov1@pci0:9:0:1: class=0x02 card=0x1425 chip=0x50011425 rev=0x00 hdr=0x00 vendor = 'Chelsio Communications Inc' device = 'T520-CR Unified Wire Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xf668, size 524288, enabled bar [18] = type Memory, range 64, base 0xf660, size 524288, enabled bar [20] = type Memory, range 64, base 0xf688a000, size 8192, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 8 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 512(2048) FLR RO NS link x8(x8) speed 8.0(8.0) -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Good motherboard for Ryzen (first-gen)
On 9/21/2018 10:53 PM, Eric van Gyzen wrote: > I would like to build a Ryzen desktop. Can anyone recommend a good > motherboard? I like the ASUS X370-PRO (currently BIOS 04/19/2018). igb0 for the onboard nic igb0@pci0:7:0:0:class=0x02 card=0x85f01043 chip=0x15398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I211 Gigabit Network Connection' and its been VERY stable since the various microcode updates and OS updates went in. (0x8001137) CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33226657792 (31687 MB) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/13/2018 6:35 AM, Konstantin Belousov wrote: > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. The hard lockups I was seeing on Ryzen and Epyc boxes are now gone with the microcode and script below. Not sure if its one or some combo of the settings, but all the steps below have made my 2 test systems stable on RELENG_11 anyways. This was on a Ryzen 5 1600X (ASUS PRIME X370-PRO BIOS from 04/19/2018) CPU Microcode patch level: 0x8001137 And EPYC 7281 16-Core (Supermicro H11SSL-i BIOS 04/27/2018 ) Microcode patch level: 0x8001227 Details of the issue were discussed at https://lists.freebsd.org/pipermail/freebsd-virtualization/2018-March/006187.html and https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/088174.html TL;DR : Generating traffic via iperf3 between VMs either on bhyve or VirtualBox would make the box lockup-- no crash, just a blank screen ---Mike > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200' $x > done > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas (and Epyc ?)
On 6/14/2018 11:03 AM, Konstantin Belousov wrote: > I am not sure about only microcode update. Depending on the BIOS > vendor and current BIOS, you may need all three: BIOS update, microcode > update using cpucontrol/devcpu-data, and running the script I posted. > In the best case, some of this is just redundand. OK, before and after shows the same microcode rev CPU: AMD EPYC 7281 16-Core Processor (2100.06-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f12 Family=0x17 Model=0x1 Stepping=2 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics # x86info -a | grep -i micro Microcode patch level: 0x8001227 # I then ran the fix script. I will let the box grind away over the weekend to see if it survives. Previously, a couple of hours would lock it up. I am running it now. One thing I did notice is a bunch of these showing up Jun 14 17:11:18 r11epyc kernel: fpudna: fpcurthread == curthread ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/14/2018 11:03 AM, Konstantin Belousov wrote: > I am not sure about only microcode update. Depending on the BIOS > vendor and current BIOS, you may need all three: BIOS update, microcode > update using cpucontrol/devcpu-data, and running the script I posted. > In the best case, some of this is just redundand. Thanks, I will run the tests on the Epyc system over the next few days. It took a little longer to crash the Epyc than the Ryzen. The Ryzen is still going now for 20hrs. Previously 5-10 min were enough to trigger the hard lockup. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/14/2018 9:36 AM, Eric van Gyzen wrote: > On 06/13/2018 05:35, Konstantin Belousov wrote: >> Today I noted that AMD published the public errata document for Ryzens, >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> Some of the issues listed there looks quite relevant to the potential >> hangs that some people still experience with the machines. I wrote >> a script which should apply the recommended workarounds to the erratas >> that I find interesting. >> >> To run it, kldload cpuctl, then apply the latest firmware update to your >> CPU, then run the following shell script. Comments indicate the errata >> number for the workarounds. >> >> Please report the results. If the script helps, I will code the kernel >> change to apply the workarounds. > Kostik: This thread on the -stable list has a lot of positive feedback: > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089110.html I have a couple of Epyc boxes that showed the same lockup behaviour. I will re-install FreeBSD on them and see if their microcode updates fix this issue as well... Should I run the same cpuctl commands on those CPUs ? BTW, I am happy to loan one out to you in the FreeBSD netperf cluster for a few weeks ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/13/2018 6:35 AM, Konstantin Belousov wrote: > Today I noted that AMD published the public errata document for Ryzens, > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > Some of the issues listed there looks quite relevant to the potential > hangs that some people still experience with the machines. I wrote > a script which should apply the recommended workarounds to the erratas > that I find interesting. > > To run it, kldload cpuctl, then apply the latest firmware update to your > CPU, then run the following shell script. Comments indicate the errata > number for the workarounds. Hi, tl;dr: The Microcode changes seem to fix a hard lockup I was able to reliable reproduce back in Feb. The BIOS on my AMD is pretty up to date. I think it has the same microcode as whats in the ports. x86info -a shows root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # after running the microcode update and root@ryzenbsd11:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # However, the dmesg after the microcode update adds this line AMD Extended Feature Extensions ID EBX=0x1007 CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.36-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics I ran the script root@ryzenbsd11:/home/mdtancsa # cat fix.sh #!/bin/sh # Enable workarounds for erratas listed in # https://developer.amd.com/wp-content/resources/55449_1.12.pdf # 1057, 1109 sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt for x in /dev/cpuctl*; do # 1021 cpucontrol -m '0xc0011029|=0x2000' $x # 1033 cpucontrol -m '0xc0011020|=0x10' $x # 1049 cpucontrol -m '0xc0011028|=0x10' $x # 1095 cpucontrol -m '0xc0011020|=0x200' $x echo $x done root@ryzenbsd11:/home/mdtancsa # sh ./fix.sh machdep.idle_mwait: 1 -> 0 machdep.idle: acpi -> hlt /dev/cpuctl0 /dev/cpuctl1 /dev/cpuctl10 /dev/cpuctl11 /dev/cpuctl2 /dev/cpuctl3 /dev/cpuctl4 /dev/cpuctl5 /dev/cpuctl6 /dev/cpuctl7 /dev/cpuctl8 /dev/cpuctl9 root@ryzenbsd11:/home/mdtancsa # Using a FreeBSD stable from back in Feb, I was able to crash Ryzen and Epyc based systems (https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088439.html) by generating a lot of traffic between the hypervisor and guests. The same tests on an intel based box ran just fine. e.g. start 3 guests in bhyve (amd64) and run combos of iperf3 between them. It would not take too long, but the box would hard lock-- i.e. blank screen, no crash dump etc. With the latest micro code update, I have been running the same sort of tests and so far so good. I will let them run overnight to see if things are now stable on STABLE. ---Mike > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200' $x > done > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen specific issues
On 1/31/2018 8:37 AM, Mike Tancsa wrote: > Hi folks, > I have been running into some deadlock issues on Ryzen boards. The > most easy way to trigger the problem is to compile net/samba47 from the > ports. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584 > > Varying the load sometimes allows the compile to finish, but most of the > time the compile deadlocks. I have seen this both on RELENG_11 as well > as HEAD from r328611 > > Any ideas how to possibly work around this ? sysctl kern.eventtimer.periodic=1 doesnt seem to help on HEAD First build attempt and it hangs in a similar / same way G -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 default/source4/heimdal/lib/hx509/asn1_ocsp_asn1.c -c -o default/source4/heimdal/lib/hx509/asn1_ocsp_asn1_92.o [1008/3804] Compiling source4/heimdal/lib/hcrypto/libtommath/bncore.c runner cc -pipe -g -ggdb -gdwarf-2 -gstrict-dwarf -DLIBICONV_PLUG -fno-color-diagnostics -D_FUNCTION_DEF -g -fstack-protector -DLDAP_DEPRECATED -fno-strict-aliasing -fno-omit-frame-pointer -fPIC -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTATIC_tommath_MODULES=NULL -DSTATIC_tommath_MODULES_PROTO=extern void __tommath_dummy_module_proto(void) -MD -Idefault/source4/heimdal_build -I../source4/heimdal_build -Idefault/source4/heimdal/lib/hcrypto/libtommath -I../source4/heimdal/lib/hcrypto/libtommath -Idefault/include/public -I../include/public -Idefault/source4 -I../source4 -Idefault/lib -I../lib -Idefault/source4/lib -I../source4/lib -Idefault/source4/include -I../source4/include -Idefault/include -I../include -Idefault/lib/replace -I../lib/replace -Idefault -I.. -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 ../source4/heimdal/lib/hcrypto/libtommath/bncore.c -c -o default/source4/heimdal/lib/hcrypto/libtommath/bncore_83.o ctrl+t load: 3.14 cmd: sh 94611 [wait] 490.27r 0.00u 0.00s 0% 2240k make: Working in: /usr/ports/net/samba47 make[1]: Working in: /usr/ports/net/samba47 load: 3.14 cmd: sh 94611 [wait] 490.27r 0.00u 0.00s 0% 2240k make: Working in: /usr/ports/net/samba47 make[1]: Working in: /usr/ports/net/samba47 root@amdtestr12:/tmp # procstat -kk 14062 PIDTID COMMTDNAME KSTACK 14062 100933 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101206 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_lock_umutex+0x6e3 __umtx_op_wait_umutex+0x48 amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101207 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101208 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101209 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101210 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101211 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101212 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101213 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101214 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101215 python2.7 - mi_switch+0x18c sleepq_swi
Ryzen specific issues
Hi folks, I have been running into some deadlock issues on Ryzen boards. The most easy way to trigger the problem is to compile net/samba47 from the ports. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584 Varying the load sometimes allows the compile to finish, but most of the time the compile deadlocks. I have seen this both on RELENG_11 as well as HEAD from r328611 Any ideas how to possibly work around this ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/12/2018 11:58 AM, Sean Bruno wrote: >> > > Probably, update your port of x86info. I pushed an update for this and > it might work better for you. Thanks, I tried it but still generates the error / warning. What does it mean ? (CPU0: local APIC error 0x80) It does however get rid of the "Unknown CPU family" error. root@testamd:/usr/ports/sysutils/devcpu-data # x86info -a | head x86info v1.31pre Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): AMD Zen Series Processor (ZP-B1) Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 MCG_CTL: Data cache check enabled root@testamd:/usr/ports/sysutils/devcpu-data # >> >> Also your diff is based on a previous version of the port. There was an >> update since, with new microcode from Intel that gets clobbered in your >> diffs. >> >> > > The update to Intel microcode was reverted. So, possibly the tree you > are using is out of date? Ahh, yes. I must have grabbed the ports just before you backed it out https://lists.freebsd.org/pipermail/svn-ports-all/2018-January/171209.html Thanks! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/11/2018 6:03 PM, Sean Bruno wrote: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. Hi, I am trying out on RELENG_11 on a Ryzen CPU Without kib's commits at https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/005320.html I get root@testamd:/usr/ports/sysutils/devcpu-data # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Re-evalutation of CPU flags Failed. root@testamd:/usr/ports/sysutils/devcpu-data # with r327597, root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@testamd:/home/mdtancsa # running x86info -a also generates this error / warning ? CPU0: local APIC error 0x80 root@testamd:/home/mdtancsa # x86info -a | grep -i microco Microcode patch level: 0x8001129 root@testamd:/home/mdtancsa # x86info -a | head -20 x86info v1.31pre Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 root@testamd:/home/mdtancsa # Also your diff is based on a previous version of the port. There was an update since, with new microcode from Intel that gets clobbered in your diffs. Thanks! ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI SAS 3108 RAID Controller
On 2/3/2016 9:20 AM, krad wrote: > > If zfs you probably want the reflash the card the the relevant HBA firmware > rather the the raid firmware. This will expose the disks nativly which is > best for zfs. The version of card I have allows you to expose the individual disks as JBODs out of the box. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI SAS 3108 RAID Controller
On 2/2/2016 12:06 PM, Zara Kanaeva wrote: > Dear list, > > I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI > SAS 3108 RAID Controller is supported by the mpr driver Try and attach the mrsas driver to the card. I had a similar problem with an onboard variant. Either compile the kernel without the mfi driver, or force the kernel to assign the mrsas driver to it instead of the mfi driver. hw.mfi.mrsas_enable=1 in /boot/loader.conf # pciconf -lv mrsas0 mrsas0@pci0:1:0:0: class=0x010400 card=0x080915d9 chip=0x005d1000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS-3 3108 [Invader]' class = mass storage subclass = RAID ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 3:04 PM, Garrett Cooper wrote: Hi, I just tried to upgrade my system from a Nehalem style era CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard (an E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with my LSI 9240-4i controller. In particular, it’s timing out because of issues noted similar to here: https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . I’ve done the following so far to try and diagnose the issue: - Upgraded the firmware on the card and in the BIOS Does anyone have any thoughts or hints on this issue? What firmware are you running on the card ? What does mfiutil show firmware give you ? I am running with good results so far 3 cards with on RELENG10 and RELENG9 (well, FreeNAS) mfi0 Firmware Package Version: 20.13.1-0208 mfi0 Firmware Images: Name Version Date Time Status BIOS 4.38.02.2_4.16.08.00_0x06060A05 07/23/2014 07/23/2014 active PCLI 03.02-020:#%9May 07 2012 13:21:53 active BCON 4.0-61-e_50-Rel Sep 09 2014 11:45:57 active NVDT 3.09.03-0064 Oct 06 2014 12:00:15 active APP 2.130.404-3836 Oct 16 2014 06:50:12 active BTBL 2.02.00.00-0001 Aug 18 2010 11:44:44 active -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 4:25 PM, NGie Cooper wrote: Hi Mike! That's the version I'm running too. Do you have the same model motherboard (there are a couple Z97s, I don't think it matters which one as long as it's the same family)? If so, it's probably something to do with the state of the volume, i.e. I might need to export and reimport it. Thanks for the feedback :)! Hi, All are Intel MB S1200RP_SE. Sorry :( I will take a quick look in the lab to see if there are any ASUS boards around, but I dont think so. BIOS Information Vendor: Intel Corp. Version: S1200RP.86B.02.01.0004.051320141432 Release Date: 05/13/2014 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 3:14 PM, Mike Tancsa wrote: On 4/7/2015 3:04 PM, Garrett Cooper wrote: Hi, I just tried to upgrade my system from a Nehalem style era CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard (an E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with my LSI 9240-4i controller. In particular, it’s timing out because of issues noted similar to here: https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . I’ve done the following so far to try and diagnose the issue: - Upgraded the firmware on the card and in the BIOS Probably not related to your issue, but another trick with this card that was helpful for me https://lists.freebsd.org/pipermail/freebsd-questions/2014-December/262744.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11
On 3/26/2015 2:44 AM, Wu ShuKun wrote: OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
On 1/8/2015 1:21 PM, Benjamin Kaduk wrote: I have no specific data about this specific case, but the advertised procedure for upgrading between major branches is to update to the tip of the starting branch before attempting the major version jump, i.e., update to the tip of stable/9 before attempting to go to stable/10 or head. Actually, there seems to be a new caveat to this discussed in https://lists.freebsd.org/pipermail/freebsd-stable/2015-January/081521.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bad judgement using chflags
chflags 0 will remove the flags ---Mike On 4/3/2014 4:52 PM, Joe Nosay wrote: I thought I could clear the .svn directory using chflag -R noschg /usr/src/.svn/* and.. I screwed up my system for svn checkout of CURRENT. Live and learn. Anyway, how do I fix this? Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to improve AES-NI performance
On 8/23/2013 11:16 AM, Ollivier Robert wrote: According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: I have developed a patch to improve AES-NI performance. If you took the AES-XTS algorithm into userland (no cryptodev or geli usage), these changes improve the performance over 10x in my tests (from ~150MB/sec to over 2GB/sec). In tests of geli on gnop, the performance improvement is more moderate, around 4x due to overhead in other parts of the system. Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. I'll be testing all this in the next few days on my new AES-NI enabled machine. Speeding up userland AES is very interesting to me for a couple of apps. If there is a proper way I should test on RELENG_9, please let me know as I am few boxes that I would be happy to test/deploy on. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to improve AES-NI performance
On 8/23/2013 2:05 PM, John-Mark Gurney wrote: Speeding up userland AES is very interesting to me for a couple of apps. If there is a proper way I should test on RELENG_9, please let me know as I am few boxes that I would be happy to test/deploy on. My patch would only effect userland applications that use /dev/crypto... If they do their own AES-NI work, then there isn't any improvement... For me its ssh which I think does, no ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: forwarding/ipfw/pf evolution (in pps) on -current
On 4/24/2013 6:45 AM, Olivier Cochard-Labbé wrote: # Why all these benchs ? # I've found performance regression regarding packet forwarding/ipfw/pf speed on -current comparing to 9.1 on my old server. BTW, how much of a drop in performance as compared to 9.1 ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
steady stream of ath errors
Experimenting with ath under RELENG8,9 and HEAD at home on my wifi
router, I found that with current from today (r244989) gives a steady
stream of errors. How can I debug the issue in my setup ?
input(Total) output
packets errs idrops bytespackets errs bytes colls
72 7 0 38865 78 0 76117 0
57 4 0989 32 0 2062 0
47 0 0 3369 29 0 5724 0
162511 01394179 2214 02779765 0
314620 02369588 3955 04723911 0
326914 02499654 4130 04984206 0
357019 02549189 4330 05082261 0
339915 02485682 4201 04956613 0
353022 02612967 4375 05207076 0
334016 02371278 4040 04728272 0
328114 02321800 3947 04628010 0
309215 02263990 3826 04514317 0
2905 8 02124069 3572 04235585 0
301718 02229250 3722 0773 0
270111 01709542 3064 03407885 0
224511 01918413 3038 03824605 0
342812 02508519 4251 05001890 0
342814 02473616 4180 04931945 0
322711 02264217 3886 04514416 0
322314 02403237 4016 04792172 0
331317 02402811 4048 04791158 0
ath0@pci0:2:0:0:class=0x028000 card=0x2c371a3b chip=0x002b168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR9285 Wireless Network Adapter (PCI-Express)'
class = network
bar [10] = type Memory, range 64, base 0xfe9f, size 65536, enabled
cap 01[40] = powerspec 3 supports D0 D1 D3 current D0
cap 05[50] = MSI supports 1 message
cap 10[60] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1)
speed 2.5(2.5)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1
ecap 0004[170] = Power Budgeting 1
stats etc attached.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
0{zotac}# ifconfig ath0
ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 74:2f:68:af:b9:47
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap
status: running
0{zotac}# ifconfig wlan0
wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 74:2f:68:af:b9:47
inet6 fe80::762f:68ff:feaf:b947%wlan0 prefixlen 64 tentative scopeid
0x5
inet 192.168.241.129 netmask 0xff00 broadcast 192.168.241.255
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap
status: running
ssid policevan2 channel 6 (2437 MHz 11g ht/20) bssid 74:2f:68:af:b9:47
regdomain 96 indoor ecm authmode WPA privacy MIXED deftxkey 2
TKIP 2:128-bit TKIP 3:128-bit txpower 20 scanvalid 60 protmode CTS
ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -dfs
0{zotac}#
0{zotac}# sysctl -a dev.ath
dev.ath.0.%desc: Atheros 9285
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBP1.NP1S
dev.ath.0.%pnpinfo: vendor=0x168c device=0x002b subvendor=0x1a3b
subdevice=0x2c37 class=0x028000
dev.ath.0.%parent: pci2
dev.ath.0.smoothing_rate: 75
dev.ath.0.sample_rate: 10
dev.ath.0.sample_stats: 0
dev.ath.0.countrycode: 0
dev.ath.0.regdomain: 96
dev.ath.0.slottime: 9
dev.ath.0.acktimeout: 64
dev.ath.0.ctstimeout: 48
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.hardled: 0
dev.ath.0.led_net_pin: -1
dev.ath.0.led_pwr_pin: -1
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.txagg: 0
dev.ath.0.forcebstuck: 0
dev.ath.0.intmit: 1
dev.ath.0.monpass: 24
dev.ath.0.hwq_limit: 2
dev.ath.0.tid_hwq_lo: 2
dev.ath.0.tid_hwq_hi: 4
dev.ath.0.txq_data_minfree: 10
dev.ath.0.txq_mcastq_maxdepth: 512
dev.ath.0.clear_stats: 0
dev.ath.0.stats.ast_watchdog: 0
dev.ath.0.stats.ast_hardware: 0
dev.ath.0.stats.ast_bmiss: 0
dev.ath.0.stats.ast_bmiss_phantom: 0
dev.ath.0.stats.ast_bstuck: 0
dev.ath.0.stats.ast_rxorn: 0
dev.ath.0.stats.ast_rxeol: 0
dev.ath.0
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/3/2012 5:18 PM, John Baldwin wrote:
Seems to apply to RELENG_9 just fine. Are there any stress tests you
suggest I run that might expose some bugs ? The machine is not
production yet, so its ok to crash it.
Probably pho's stress2 stuff. Thinks like dbench might be a good start as
well for initial testing.
dbench runs just fine with 20 clients. I am letting stress2's disk
stress test now. The tw_cli seems to run the same when the controller
is super busy with pho's stress
I havent looked at performance differences, but a quick eyeball shows
about the same.
0{offsite2}# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache
AVrfy
--
u0RAID-0OK - - 64K 931.521 ON
-
Port Status Unit SizeBlocksSerial
---
p0 OK u0 465.76 GB 976773168 WD-WCAYUEY18298
p1 OK u0 465.76 GB 976773168 WD-WMAYUL256317
0{offsite2}#
Operation CountAvgLatMaxLat
NTCreateX1523290 1.527 2151.921
Close1119090 0.681 2001.144
Rename 64489 3.669 748.957
Unlink307507 3.305 2075.871
Deltree 4035.922 194.337
Mkdir 20 0.014 0.113
Qpathinfo1380911 0.292 637.855
Qfileinfo 242016 0.001 0.201
Qfsinfo 253036 0.006 2.063
Sfileinfo 124125 3.539 1479.315
Find 533771 0.417 1501.775
WriteX759745 0.195 403.113
ReadX2386679 0.033 322.923
LockX 4952 0.004 0.018
UnlockX 4952 0.003 0.240
Flush 10677559.541 2081.524
Throughput 79.6165 MB/sec 20 clients 20 procs max_latency=2151.929 ms
Mon Aug 13 16:38:18 EDT 2012
run: run time 3+00:00:00, incarnations 1, load 100, verbose 1
16:38:18 Loop #1
rw: run time 0+00:02:00, incarnations 17, load 100, verbose 1
creat: run time 0+00:02:00, incarnations 64, load 80, verbose 1
mkdir: run time 0+00:02:00, incarnations 52, load 80, verbose 1
16:40:56 Loop #2
rw: run time 0+00:02:00, incarnations 98, load 100, verbose 1
creat: run time 0+00:02:00, incarnations 28, load 80, verbose 1
mkdir: run time 0+00:02:00, incarnations 34, load 80, verbose 1
16:48:39 Loop #3
rw: run time 0+00:02:00, incarnations 63, load 100, verbose 1
creat: run time 0+00:02:00, incarnations 80, load 80, verbose 1
mkdir: run time 0+00:02:00, incarnations 19, load 80, verbose 1
16:53:59 Loop #4
rw: run time 0+00:02:00, incarnations 11, load 100, verbose 1
creat: run time 0+00:02:00, incarnations 46, load 80, verbose 1
mkdir: run time 0+00:02:00, incarnations 21, load 80, verbose 1
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/10/2012 9:31 AM, John Baldwin wrote:
On 8/9/12 5:04 PM, Mike Tancsa wrote:
Start up the tw_cli client
0{offsite2}# tw_cli
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c09650SE-2LP 2 21 0 1 1 -
//offsite2 exit
0{offsite2}# ls -l /dev/tw*
crw--- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
0{offsite2}#
It then disappears ?!
Bizarre, it seems to disappear while tw_cli is running? I'm curious if
'rm -W /dev/twe0' brings it back?
nada
0{offsite2}# rm -W /dev/twe0
rm: /dev/twe0: No such file or directory
1{offsite2}# rm -W /dev/twe0
rm: /dev/twe0: No such file or directory
1{offsite2}# ls -l /dev/twe*
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
0{offsite2}#
If so, it might be interesting to see a ktrace of tw_cli.
I just ran ktrace tw_cli
File is available at
http://www.tancsa.com/misc/ktrace.out
and
http://www.tancsa.com/misc/ktrace.txt
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
/dev/twe/twevar.h2009-12-25
17:35:14.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twevar.h 2012-08-03
04:00:49.0
--
Patching file twevar.h using Plan A...
Hunk #1 succeeded at 134.
Hunk #2 succeeded at 210.
Hunk #3 succeeded at 255.
done
0{offsite2}#
Looks good!
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c08006-2LP 2 21 0 3 - -
c19650SE-2LP 2 21 0 1 1 -
//offsite2 /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache
AVrfy
--
u0RAID-0OK - - 64K 931.521 ON
-
Port Status Unit SizeBlocksSerial
---
p0 OK u0 465.76 GB 976773168 WD-WCAYUEY18298
p1 OK u0 465.76 GB 976773168 WD-WMAYUL256317
//offsite2 /c1 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache
AVrfy
--
u0RAID-1OK - - - 465.651 RiW
ON
VPort Status Unit Size Type Phy Encl-SlotModel
--
p0OK u0 465.76 GB SATA 0 -WDC
WD5002AALX-00J3
p1OK u0 465.76 GB SATA 1 -WDC
WD5002AALX-00J3
//offsite2
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/8/2012 2:39 PM, Mike Tancsa wrote: On 8/8/2012 7:27 AM, John Baldwin wrote: Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? Yes 2) If it does, does basic I/O to the drives work? yes 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. One more data point, /dev/twe0 does not exist with the patch and I think thats why the utils fail outright. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 9:16 AM, John Baldwin wrote:
One more data point, /dev/twe0 does not exist with the patch and I think
thats why the utils fail outright.
Oh, hmm. That's odd. Do you get any error messages on the console
when twe0 attaches? Also, you have INVARIANTS enabled, yes?
(make_dev() panics when it fails if INVARIANTS is enabled).
I have INVARIANTS in the kernel, sorry, do I need to do something to
make it active ?
0{offsite2}# sysctl -a | grep -i invar
kern.features.invariant_support: 1
options INVARIANT_SUPPORT
options INVARIANTS
kern.timecounter.invariant_tsc: 1
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
TSC: P-state invariant, performance statistics
0{offsite2}#
Nothing odd in dmesg
ZFS filesystem version 5
ZFS storage pool version 28
Timecounters tick every 1.000 msec
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
pci6: ACPI PCI bus on pcib6
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe
27f at device 0.0 on pci6
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
isab0: PCI-ISA bridge at device 31.0 on pci0
Patch below is causing a panic now on boot. Just going to add debugging
to the serial console to see what it is and
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x3
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x81813eb3
stack pointer = 0x28:0xff84529d33f0
frame pointer = 0x28:0xff84529d3430
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1324 (kldload)
[ thread pid 1324 tid 100146 ]
Stopped at twe_setup+0x153:movzbl 0x3(%rdx),%eax
db
Maybe try something like this (relative to the patched driver):
--- //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c2012-08-03
18:10:04.0
+++ /Users/jhb/work/p4/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03
18:10:04.0
@@ -342,9 +342,12 @@
/*
* Create the control device.
*/
+device_printf(sc-twe_dev, Calling make_dev()\n);
sc-twe_dev_t = make_dev(twe_cdevsw, device_get_unit(sc-twe_dev),
UID_ROOT, GID_OPERATOR,
S_IRUSR | S_IWUSR, twe%d,
device_get_unit(sc-twe_dev));
sc-twe_dev_t-si_drv1 = sc;
+device_printf(sc-twe_dev, make_dev() returned %p (%s)\n,
sc-twe_dev_t,
+ sc-twe_dev_t-si_name);
/*
* Schedule ourselves to bring the controller up once interrupts
are available.
* This isn't strictly necessary, since we disable interrupts while
probing the
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 1:21 PM, John Baldwin wrote:
Humm, I wonder if this module has a mix of old and new .o files somehow?
Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'?
I think you are right. I nuked all the kernel files and recompiled
again, and it no longer panics and I see the entry in /dev now!?
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0122105200 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}#
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/9/2012 3:28 PM, Mike Tancsa wrote:
On 8/9/2012 1:21 PM, John Baldwin wrote:
Humm, I wonder if this module has a mix of old and new .o files somehow?
Perhaps try rebuilding twe.ko from scratch after doing a 'make clean'?
I think you are right. I nuked all the kernel files and recompiled
again, and it no longer panics and I see the entry in /dev now!?
0{offsite2}# kldload twe
twe0: 3ware Storage Controller. Driver version 1.50.01.002 port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0122105200 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}#
OK, some more mystery.
If I load it as a kld,
I see the device. (Note, I added MDT into the version string)
0{offsite2}# twe0: 3ware Storage Controller. Driver version
1.50.01.002MDT port 0x2000-0x200f mem
0xe281-0xe281000f,0xe200-0xe27f at device 0.0 on pci6
twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048
twe0: Calling make_dev()
twe0: make_dev() returned 0xfe0026581a00 (twe0)
twed0 on twe0
twed0: 953878MB (1953542144 sectors)
0{offsite2}# ls -l /dev/tw*
crw--- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0
crw--- 1 root operator - 0, 173 Aug 9 17:00 /dev/twe0
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
Start up the tw_cli client
0{offsite2}# tw_cli
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c09650SE-2LP 2 21 0 1 1 -
//offsite2 exit
0{offsite2}# ls -l /dev/tw*
crw--- 1 root operator - 0, 37 Aug 9 16:58 /dev/twa0
crw-r- 1 root operator - 0, 174 Aug 9 17:00 /dev/twed0
0{offsite2}#
It then disappears ?!
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/8/2012 7:27 AM, John Baldwin wrote: Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? Yes 2) If it does, does basic I/O to the drives work? yes 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/3/2012 5:26 PM, John Baldwin wrote:
If there's a tool for poking at the drives/controller, I would use
that, plus camcontrol. Of course you want a data intensive workload
(iometer/iozone/xdd with async and sync mode, random reads and sequential
reads, etc), and maybe resort to manual testing like pulling drives
(power, data) if you don't mind creating failures. If you have some
failed/failing drives kicking around, that would be a good test as well (see
that all/some of the failure paths are properly stimulated).
3dm2 testing would be good for the ioctl handling, but the most critical
tests are basic I/O.
Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able
to see the 8006 controller I added.
tw_cli without the patch
0{offsite2}# tw_cli
//offsite2 /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache
AVrfy
--
u0RAID-0OK - - 64K 931.521 ON
-
Port Status Unit SizeBlocksSerial
---
p0 OK u0 465.76 GB 976773168 WD-WCAYUEY18298
p1 OK u0 465.76 GB 976773168 WD-WMAYUL256317
//offsite2
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c08006-2LP 2 21 0 3 - -
c19650SE-2LP 2 21 0 1 1 -
The boot array is c1 (the off twa controller)
with the patch (invariants and invariants_support in the kernel)
0{offsite2}# tw_cli
//offsite2 show
Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
c09650SE-2LP 2 21 0 1 1 -
//offsite2
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/3/2012 3:39 PM, John Baldwin wrote:
On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
I'll try to find time to try it later today, but I'm in the middle of
budget wrangling and I can't make any promises.
Before I try, will these patches apply to the twe driver in
9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18.
I really don't have time to install current right now.
I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9
please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for
initial testing. Thanks!
Seems to apply to RELENG_9 just fine. Are there any stress tests you
suggest I run that might expose some bugs ? The machine is not
production yet, so its ok to crash it.
{offsite2}# patch -p9 twe_locking.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe.c 2009-12-25
17:35:14.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe.c 2012-08-03
04:00:49.0
--
Patching file twe.c using Plan A...
Hunk #1 succeeded at 151.
Hunk #2 succeeded at 167.
Hunk #3 succeeded at 189.
Hunk #4 succeeded at 208.
Hunk #5 succeeded at 226.
Hunk #6 succeeded at 234.
Hunk #7 succeeded at 271.
Hunk #8 succeeded at 288.
Hunk #9 succeeded at 310.
Hunk #10 succeeded at 337.
Hunk #11 succeeded at 349.
Hunk #12 succeeded at 405.
Hunk #13 succeeded at 521.
Hunk #14 succeeded at 557.
Hunk #15 succeeded at 580.
Hunk #16 succeeded at 595.
Hunk #17 succeeded at 608.
Hunk #18 succeeded at 646.
Hunk #19 succeeded at 769.
Hunk #20 succeeded at 863.
Hunk #21 succeeded at 921.
Hunk #22 succeeded at 952.
Hunk #23 succeeded at 1038.
Hunk #24 succeeded at 1051.
Hunk #25 succeeded at 1082.
Hunk #26 succeeded at 1104.
Hunk #27 succeeded at 1140.
Hunk #28 succeeded at 1151.
Hunk #29 succeeded at 1177.
Hunk #30 succeeded at 1206.
Hunk #31 succeeded at 1309.
Hunk #32 succeeded at 1447.
Hunk #33 succeeded at 1469.
Hunk #34 succeeded at 1499.
Hunk #35 succeeded at 1513.
Hunk #36 succeeded at 1531.
Hunk #37 succeeded at 1554.
Hunk #38 succeeded at 1589.
Hunk #39 succeeded at 1618.
Hunk #40 succeeded at 1644.
Hunk #41 succeeded at 1696.
Hunk #42 succeeded at 1778.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe_compat.h
2005-05-29 04:45:51.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_compat.h 2012-08-03
03:58:12.0
--
Patching file twe_compat.h using Plan A...
Hunk #1 succeeded at 43.
Hunk #2 succeeded at 68.
Hunk #3 succeeded at 82.
Hunk #4 succeeded at 92.
Hunk #5 succeeded at 108.
Hunk #6 succeeded at 128.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe_freebsd.c
2012-03-12 08:05:24.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03
18:10:04.0
--
Patching file twe_freebsd.c using Plan A...
Hunk #1 succeeded at 69.
Hunk #2 succeeded at 83.
Hunk #3 succeeded at 101.
Hunk #4 succeeded at 180.
Hunk #5 succeeded at 188.
Hunk #6 succeeded at 211.
Hunk #7 succeeded at 241.
Hunk #8 succeeded at 292.
Hunk #9 succeeded at 414.
Hunk #10 succeeded at 425.
Hunk #11 succeeded at 461.
Hunk #12 succeeded at 496.
Hunk #13 succeeded at 518.
Hunk #14 succeeded at 533.
Hunk #15 succeeded at 566.
Hunk #16 succeeded at 585.
Hunk #17 succeeded at 604.
Hunk #18 succeeded at 680.
Hunk #19 succeeded at 729.
Hunk #20 succeeded at 834.
Hunk #21 succeeded at 857.
Hunk #22 succeeded at 876.
Hunk #23 succeeded at 1038.
Hunk #24 succeeded at 1097.
Hunk #25 succeeded at 1151.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twevar.h2009-12-25
17:35:14.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twevar.h 2012-08-03
04:00:49.0
--
Patching file twevar.h using Plan A...
Hunk #1 succeeded at 134.
Hunk #2 succeeded at 210.
Hunk #3 succeeded at 255.
done
0{offsite2}#
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on mips/mips
On 4/5/2012 3:28 PM, Doug Barton wrote: Thanks for confirming. I also forgot to mention that all the related changes were made in the same commit, so I'm not sure what the issue could have been. The logs / progress are visible at http://tinderbox.freebsd.org/ It looks like pc98 i386 built just fine recently. Not sure why the mips build keeps failing so much. des from .no would know :) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 12/15/2011 11:26 AM, Attilio Rao wrote: Hi Mike, was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE? Hi Attilio, It was the same codebase. Could you retry the bench checking CPU usage and possible thread migration around for both cases? I can, but how do I do that ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 12/15/2011 11:42 AM, Attilio Rao wrote: I'm thinking now to a better test-case for this: can you try that on a tmpfs volume? There is enough RAM in the box so that it should not touch the disk, and I was sending the output to /dev/null, so it was not writing to the disk. Also what filesystem you were using? UFS How many CPUs were in place? 4 Did you reboot before to move the steal_thresh value? No. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 12/15/2011 11:56 AM, Attilio Rao wrote: So, as very first thing, can you try the following: - Same codebase, etc. etc. - Make the test 4 times, discard the first and ministat for the other 3 - Reboot - Change the steal_thresh value - Make the test 4 times, discard the first and ministat for the other 3 Then report discarded values and the ministated one and we will have more informations I guess (also, I don't think devfs contention should play a role here, thus nevermind about it for now). Results and data at http://www.tancsa.com/ule-bsd.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 12/13/2011 7:01 PM, m...@freebsd.org wrote: Has anyone experiencing problems tried to set sysctl kern.sched.steal_thresh=1 ? I don't remember what our specific problem at $WORK was, perhaps it was just interrupt threads not getting serviced fast enough, but we've hard-coded this to 1 and removed the code that sets it in sched_initticks(). The same effect should be had by setting the sysctl after a box is up. FWIW, this does impact the performance of pbzip2 on an i7. Using a 1.1G file pbzip2 -v -c big /dev/null with burnP6 running in the background, sysctl kern.sched.steal_thresh=1 vs sysctl kern.sched.steal_thresh=3 N Min MaxMedian AvgStddev x 10 38.005022 38.42238 38.194648 38.1650520.15546188 + 9 38.695417 40.595544 39.392127 39.4353840.59814114 Difference at 95.0% confidence 1.27033 +/- 0.412636 3.32852% +/- 1.08119% (Student's t, pooled s = 0.425627) a value of 1 is *slightly* faster. -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 12/13/2011 10:54 AM, Steve Kargl wrote: I have given the WHY in previous discussions of ULE, based on what you call legacy benchmarks. I have not seen any commit to sched_ule.c that would lead me to believe that the performance issues with ULE and cpu-bound numerical codes have been addressed. Repeating the benchmark would be a waste of time. Trying a simple pbzip2 on a large file, the results are pretty consistent through iterations. pbzip2 with 4BSD is barely faster on a file thats 322MB in size. after a reboot, I did a strings bigfile /dev/null then ran pbzip2 -v xaa -c /dev/null 7 times If I do a burnP6 in the background, they perform about the same. (from sysutils/cpuburn) eg pbzip2 -v xaa -c /dev/null Parallel BZIP2 v1.1.6 - by: Jeff Gilchrist [http://compression.ca] [Oct. 30, 2011] (uses libbzip2 by Julian Seward) Major contributions: Yavor Nikolov nikolov.javor+pbz...@gmail.com # CPUs: 4 BWT Block Size: 900 KB File Block Size: 900 KB Maximum Memory: 100 MB --- File #: 1 of 1 Input Name: xaa Output Name: stdout Input Size: 352404831 bytes Compressing data... Output Size: 50630745 bytes --- Wall Clock: 18.139342 seconds ULE 18.113204 18.116896 18.123400 18.105894 18.163332 18.139342 18.082888 ULE with burnP6 23.076085 22.003666 21.162987 21.682445 21.935568 23.595781 21.601277 4BSD 17.983395 17.986218 18.009254 18.004312 18.001494 17.997032 4BSD with burnP6 22.215508 21.886459 21.595179 21.361830 21.325351 21.244793 # ministat uleP6 bsdP6 x uleP6 + bsdP6 +--+ |x+ + ++x + x x + xx| | ||__MA|M_A__| | +--+ N Min MaxMedian AvgStddev x 6 21.162987 23.595781 22.003666 22.2427550.91175566 + 6 21.244793 22.215508 21.595179 21.604853 0.3792413 No difference proven at 95.0% confidence x ule + bsd +--+ |+ + + + + + xx x xx x x| | |__A___M___| |M__A__| | +--+ N Min MaxMedian AvgStddev x 7 18.082888 18.163332 18.116896 18.120708 0.025468695 + 6 17.983395 18.009254 18.001494 17.996951 0.010248473 Difference at 95.0% confidence -0.123757 +/- 0.024538 -0.68296% +/- 0.135414% (Student's t, pooled s = 0.0200388) hardware is X3450 with 8G of memory. RELENG8 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64
On 12/12/2011 2:49 PM, Keith Simonsen wrote: I've been using 20110718-02-wbwd.diff for a few months now on a project with PC Engines Alix 1.d boards (http://pcengines.ch/alix1d.htm). They have a Winbond W83627HG chip. I don't see any probing/attach messages on boot but the driver seems to be properly configuring the chip - if I kill watchdogd with -9 the board reboots with watchdog timeout. Are you sure thats the watchdog thats doing the 'killing' so to speak ? If you have option CPU_GEODE in your kernel config, you will get the watchdog code there no ? ( /usr/src/sys/i386/i386/geode.c) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 beta2 the new bsdinstaller
On 9/12/2011 9:57 AM, Fbsd8 wrote: Here are some problems that I fell need to be addressed in the 9.0 bsdinstaller. 7. On the partition editor screen the option finish should be the first in the list (ie; left most side) so if user accepts this config, hitting enter moves to next menu screen instead of having to tab over taking more time and effort. I noticed as well, there is no way to turn off SoftUpdates with Journaling. e.g. despite unselecting that option, I ended up with a file system below. # mount /dev/ada0p3 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ada0p4 on /usr (ufs, local, journaled soft-updates) /dev/ada0p5 on /var (ufs, local, journaled soft-updates) In the partition editor, OK and Options both have the same hotkeys (O). Also if you change from the suggested partition default, it always wants to add a boot partition even if there is one already there. e.g. go to guided, delete / and the swap and add some partitions. When you create a new / it will say it needs a boot partition, but that already exists and now there will be two. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX)
On 8/31/2011 12:27 PM, Adrian Chadd wrote: Just to clarify for Edgar, His 9.0 build isn't finding any valid timers; hence why the thing panics upon boot. Since I've got a few Alix boards I'd like to use for 11n testing, i'd like to know how to make this work. Does anyone know the relevant magic to see which timers are available, and force enable something that'll work? Strange, I had just tried with a Soekris not long ago and it was happy with Beta1 and 2 csuping... updating... and it still works. dmesg.txt at http://www.tancsa.com/beta2.html What if you add option CPU_GEODE option CPU_SOEKRIS to the kernel ? I think actually only one is needed, but I forget which one. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX)
On 8/31/2011 3:25 PM, Edgar Martinez wrote: Nope..I rebuilt with both options..and just one at a time.. Strange, My kernel is not so different from GENERIC. I added it to the bottom of http://www.tancsa.com/beta2.html Perhaps its a different Alix box than mine that is causing the issue ? I tried with http://www.pcengines.ch/alix6f2.htm and http://www.pcengines.ch/alix3d2.htm ---Mike panic: No usable event timer found! KDB: stack backtrace: X_db_sym_numargs(c0758a2d) at 0xc0471f85 = X_db_sym_numargs+0x135 kdb_backtrace(c2820d38,1,fff,c2820d40,c070257a,...) at 0xc05a9c98 = kdb_backtrace+0x28 panic(c077df08,c078251c,fff,c2820d48,c0708b88,...) at 0xc0581322 = panic+0xa2 cpu_initclocks_bsp(c2820d60,c054358b,c07c8f14,c0750d2a,0,...) at 0xc070257a = cpu_initclocks_bsp+0xfa cpu_initclocks(c07c8f14,c0750d2a,0,0,c2820d78,...) at 0xc0708b88 = cpu_initclocks+0x8 hardclock_sync(0,281ec00,281e000,2825000,0,...) at 0xc054358b = hardclock_sync+0x3b mi_startup() at 0xc0541469 = mi_startup+0xa9 btext() at 0xc0447665 = btext+0x95 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at 0xc05a9aa4 = kdb_enter+0x34:movl$0,0xc07d93b4 = kdb_why Is still the result.. -Original Message- From: Mike Tancsa [mailto:m...@sentex.net] Sent: Wednesday, August 31, 2011 10:53 AM To: Adrian Chadd Cc: Edgar Martinez; freebsd-current@freebsd.org Subject: Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX) On 8/31/2011 12:27 PM, Adrian Chadd wrote: Just to clarify for Edgar, His 9.0 build isn't finding any valid timers; hence why the thing panics upon boot. Since I've got a few Alix boards I'd like to use for 11n testing, i'd like to know how to make this work. Does anyone know the relevant magic to see which timers are available, and force enable something that'll work? Strange, I had just tried with a Soekris not long ago and it was happy with Beta1 and 2 csuping... updating... and it still works. dmesg.txt at http://www.tancsa.com/beta2.html What if you add option CPU_GEODE option CPU_SOEKRIS to the kernel ? I think actually only one is needed, but I forget which one. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX)
On 8/31/2011 3:57 PM, Edgar Martinez wrote: Latest ALIX firmware? .99h? I'm using the below board... http://pcengines.ch/alix2d2.htm Thats pretty well the same board as me, except I dont have the 2 mini-pci slots. Mine comes up as Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 vs Geode LX: PC Engines ALIX.3 v0.99h tinyBIOS V1.4a (C)1997-2007 Perhaps engage the PCEngine's folks to see what the difference is and if they know what might be up. ---Mike -Original Message- From: Mike Tancsa [mailto:m...@sentex.net] Sent: Wednesday, August 31, 2011 12:57 PM To: Edgar Martinez Cc: Adrian Chadd; freebsd-current@freebsd.org Subject: Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX) On 8/31/2011 3:25 PM, Edgar Martinez wrote: Nope..I rebuilt with both options..and just one at a time.. Strange, My kernel is not so different from GENERIC. I added it to the bottom of http://www.tancsa.com/beta2.html Perhaps its a different Alix box than mine that is causing the issue ? I tried with http://www.pcengines.ch/alix6f2.htm and http://www.pcengines.ch/alix3d2.htm ---Mike panic: No usable event timer found! KDB: stack backtrace: X_db_sym_numargs(c0758a2d) at 0xc0471f85 = X_db_sym_numargs+0x135 kdb_backtrace(c2820d38,1,fff,c2820d40,c070257a,...) at 0xc05a9c98 = kdb_backtrace+0x28 panic(c077df08,c078251c,fff,c2820d48,c0708b88,...) at 0xc0581322 = panic+0xa2 cpu_initclocks_bsp(c2820d60,c054358b,c07c8f14,c0750d2a,0,...) at 0xc070257a = cpu_initclocks_bsp+0xfa cpu_initclocks(c07c8f14,c0750d2a,0,0,c2820d78,...) at 0xc0708b88 = cpu_initclocks+0x8 hardclock_sync(0,281ec00,281e000,2825000,0,...) at 0xc054358b = hardclock_sync+0x3b mi_startup() at 0xc0541469 = mi_startup+0xa9 btext() at 0xc0447665 = btext+0x95 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at 0xc05a9aa4 = kdb_enter+0x34:movl$0,0xc07d93b4 = kdb_why Is still the result.. -Original Message- From: Mike Tancsa [mailto:m...@sentex.net] Sent: Wednesday, August 31, 2011 10:53 AM To: Adrian Chadd Cc: Edgar Martinez; freebsd-current@freebsd.org Subject: Re: No valid timers found on ALIX (was Re: 9.0-BETA2 - Kernel Panic on ALIX) On 8/31/2011 12:27 PM, Adrian Chadd wrote: Just to clarify for Edgar, His 9.0 build isn't finding any valid timers; hence why the thing panics upon boot. Since I've got a few Alix boards I'd like to use for 11n testing, i'd like to know how to make this work. Does anyone know the relevant magic to see which timers are available, and force enable something that'll work? Strange, I had just tried with a Soekris not long ago and it was happy with Beta1 and 2 csuping... updating... and it still works. dmesg.txt at http://www.tancsa.com/beta2.html What if you add option CPU_GEODE option CPU_SOEKRIS to the kernel ? I think actually only one is needed, but I forget which one. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ichwd attach failure
Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: Intel Cougar Point watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Soekris] FreeBSD 9.0 beta on a Net5501?
On 8/14/2011 3:50 PM, C. P. Ghost wrote: I'm having a bunch of net4801 in production here, and I was planning to move them to 9.0 soon after RELEASE. So thanks for the heads up. I'll be holding back now, and will stay with 8.2-STABLE. I netbooted an old 4801 box and it seems fine too. Testing the watchdog as well as the hifn that was in it and both seem to work just fine. 4801# dmesg Copyright (c) 1992-2011 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 9.0-BETA1 #2: Sun Aug 14 19:15:05 EDT 2011 mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/ipsec i386 ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) module_register: module pci/xhci already exists! Module pci/xhci failed to register: 17 CPU: Geode(TM) Integrated Processor by National Semi (586-class CPU) Origin = Geode by NSC Id = 0x540 Family = 5 Model = 4 Stepping = 0 Features=0x808131FPU,TSC,MSR,CX8,CMOV,MMX real memory = 134217728 (128 MB) avail memory = 116346880 (110 MB) kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: software crypto on motherboard pcib0: Host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 sis0: NatSemi DP8381[56] 10/100BaseTX port 0xe100-0xe1ff mem 0xa000-0xafff irq 10 at device 6.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: MII bus on sis0 nsphyter0: DP83815 10/100 media interface PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c8:fa:e0 sis1: NatSemi DP8381[56] 10/100BaseTX port 0xe200-0xe2ff mem 0xa0001000-0xa0001fff irq 10 at device 7.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: MII bus on sis1 nsphyter1: DP83815 10/100 media interface PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c8:fa:e1 sis2: NatSemi DP8381[56] 10/100BaseTX port 0xe300-0xe3ff mem 0xa0002000-0xa0002fff irq 10 at device 8.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: MII bus on sis2 nsphyter2: DP83815 10/100 media interface PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c8:fa:e2 pci0: processor at device 14.0 (no driver attached) Geode Soekris net4801 comBIOS ver. 1.31 20070408 Copyright (C) 2000-2007 isab0: PCI-ISA bridge port 0x6100-0x613f,0x6200-0x623f at device 18.0 on pci0 isa0: ISA bus on isab0 pci0: bridge at device 18.1 (no driver attached) atapci0: National Geode SC1100 ATA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 18.2 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 Timecounter Geode frequency 2700 Hz quality 1000 pci0: bridge at device 18.5 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xa001-0xa0010fff irq 5 at device 19.0 on pci0 usbus0: OHCI (generic) USB controller on ohci0 cpu0 on motherboard pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc8000-0xd0fff pnpid ORM on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 ppc0: parallel port not found. uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (115200,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 0.976 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: 0x0e11 at usbus0 uhub0: 0x0e11 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 Root mount waiting for: usbus0 uhub0: 3 ports with 3 removable, self powered Trying to mount root from nfs: []... NFS ROOT: 10.255.255.1:/home/pxe9 hifn0 mem 0xa0003000-0xa0003fff,0xa0004000-0xa0005fff,0xa0008000-0xa000 irq 11 at device 14.0 on pci0 hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801ext clk, 4x mult 4801# And using /usr/src/tools/crypto/cryptostats % ssh -c 3des 10.255.255.60 /home/mdtancsa/cryptostats 241 symmetric crypto ops (0 errors, 0 times driver blocked) 0 key ops (0 errors, 0 times driver blocked) 0 crypto dispatch thread activations 0 crypto return thread activations % ssh -c 3des 10.255.255.60 /home/mdtancsa/cryptostats 271 symmetric crypto ops (0 errors, 0 times driver blocked) 0 key ops (0 errors, 0 times driver blocked) 0 crypto dispatch thread activations 0 crypto return thread activations Seems to be kicking the hifn card. -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com
Re: [Soekris] FreeBSD 9.0 beta on a Net5501?
irq 3 on isa0 Timecounters tick every 0.976 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: AMD at usbus0 uhub0: AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: AMD at usbus1 uhub1: AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 Timecounter TSC frequency 433257343 Hz quality 800 Root mount waiting for: usbus1 usbus0 uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 uhub1: 4 ports with 4 removable, self powered Trying to mount root from nfs: []... NFS ROOT: 10.255.255.1:/home/pxe9 stray irq7 soekris3# -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: High Network Perfomance
On 8/8/2011 12:21 PM, Victor Detoni wrote: Hi Slawa! Thanks for the links! That's great links! about russian, there is no problem... google translate :) Yes, excellent links indeed and google translate is awesome! One further question. Do you usually set net.isr.bindthreads=1 ---Mike thanks, Victor On Sun, Aug 7, 2011 at 9:33 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Aug 04, 2011 at 08:39:17PM -0300, Victor Detoni wrote: Hi Guys, I'm trying tunning a FreeBSD 8.2 to high perfomance network with pf. My server configuration is: Dell 1950 CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.03-MHz K8-class CPU) 4 x CPU 2 NIC (Broadcom NetXtreme II BCM5708 1000Base-T) 1 NIC (em0: Intel(R) PRO/1000 Network Connection 7.1.9) I want to reach the high processing of packets per second and use pf as synproxy and we still processor to handle others packets or flows. I know that em drivers has MULTI_QUEUE implementation that helps high performance for Intel drivers, but I couldn't see more information about. We can reached 500k pps, but no more traffic was processed by this interface. I've already enabled net.isr.direct but with Intel Drivers does not work and the most processors are in System instead of Interrupts, why? When I enable net.isr.direct the processing is balanced for on CPU in system and another in interrupt and I reached 1M pps, but the total perfomance is down, the load grow up too fast. I've changed some parameter in sysctl for intel drivers, but it doesn't have effect. Someone know what I can do to reach more packets performance? I want to use this FreeBSD as a router/firewall only. FreeBSD (and em) need some tuning for high perfomance. Next links in russian, sorry. http://dadv.livejournal.com/138951.html http://dadv.livejournal.com/139170.html http://dadv.livejournal.com/139366.html -- Slawa Olhovchenkov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sata port multiplier
On 8/4/2011 9:59 PM, Nenhum_de_Nos wrote: hail, any info on what port multiplier I could buy to make the 4 port Sil3124 at least make up to 8 ? I have used a number of PMs from http://www.addonics.com/. 8.x works great. eg. # camcontrol devlist WDC WD1001FALS-00J7B1 05.00K05 at scbus0 target 0 lun 0 (pass0,ada0) WDC WD1001FALS-00J7B1 05.00K05 at scbus0 target 1 lun 0 (pass1,ada1) WDC WD1001FALS-00J7B1 05.00K05 at scbus0 target 2 lun 0 (pass2,ada2) WDC WD1001FALS-00J7B1 05.00K05 at scbus0 target 3 lun 0 (pass3,ada3) Port Multiplier 47261095 1f06at scbus0 target 15 lun 0 (pass4,pmp0) WDC WD2001FASS-00U0B0 01.00101 at scbus1 target 0 lun 0 (pass5,ada4) WDC WD1501FASS-00W2B0 05.01D05 at scbus1 target 1 lun 0 (pass6,ada5) WDC WD1501FASS-00W2B0 05.01D05 at scbus1 target 2 lun 0 (pass7,ada6) WDC WD1501FASS-00W2B0 05.01D05 at scbus1 target 3 lun 0 (pass8,ada7) WDC WD1501FASS-00W2B0 05.01D05 at scbus1 target 4 lun 0 (pass9,ada8) Port Multiplier 47261095 1f06at scbus1 target 15 lun 0 (pass10,pmp1) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
graid fresh install
I netbooted 9.0 Beta and was going to try and install the system onto a raid1 mirror built with graid. However, neither sysinstall nor bsdinstall see it fully I have the box netbooted (Intel Matrix raid) i5# graid status -ags Intel-a5bbf622 OPTIMAL ada0 (ACTIVE (ACTIVE)) Intel-a5bbf622 OPTIMAL ada1 (ACTIVE (ACTIVE)) i5# I can newfs /dev/raid/r0 i5# ls -l /dev/raid/r0 crw-r- 1 root operator0, 98 Aug 5 10:43 /dev/raid/r0 i5# and mount it. However, speeds seem a bit slow, but I am not sure if thats to be expected. i5# dd if=/dev/zero of=/mnt/test bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 13.996080 secs (7491926 bytes/sec) i5# i5# iostat -c 1000 ada0 ada1 ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 2 204 124.47 5 0.57 124.28 5 0.57 0 0 0 0 100 0 186 128.00 60 7.49 128.00 62 7.74 0 0 0 0 100 064 128.00 55 6.87 128.00 50 6.24 0 0 0 1 99 063 128.00 60 7.49 128.00 64 7.99 0 0 0 1 99 063 128.00 40 4.99 128.00 40 4.99 0 0 0 1 99 063 126.43 61 7.52 128.00 59 7.37 0 0 0 0 99 063 128.00 45 5.62 128.00 43 5.37 0 0 0 1 99 063 128.00 50 6.24 128.00 51 6.37 0 0 0 0 100 064 128.00 50 6.24 128.00 49 6.12 0 0 0 1 99 063 128.00 80 9.99 128.00 81 10.11 0 0 0 0 100 064 128.00 70 8.74 128.00 71 8.87 0 0 0 0 99 But when I run sysintall, it does not find any disks. If I run bsdinstall, it sees ada0 and ada1, but I cannot partition and label the raid partition. Am I supposed to just write to ada0 ? What is the best way to do it Guided just shows ada0 and ada1 The partition editor does show md0 4.0 MBmalloc ada0 465 GB raid/r0 465 GB ada1 465 GB raid/r0 465 GB But I cannot label any of the r0 'disks' It comes up with Invalid argument. arg0 'Intel-a5bbf622' ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD5002AALX-00J37A0 15.01H15 ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: WDC WD5002AALX-00J37A0 15.01H15 ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ahci0: Intel ICH8 AHCI SATA controller port 0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f mem 0xb262-0xb26207ff irq 18 at device 31.2 o n pci0 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ahcich2: AHCI channel at channel 2 on ahci0 ahcich3: AHCI channel at channel 3 on ahci0 ahcich4: AHCI channel at channel 4 on ahci0 ahcich5: AHCI channel at channel 5 on ahci0 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: graid fresh install
On 8/5/2011 12:01 PM, Mike Tancsa wrote: and mount it. However, speeds seem a bit slow, but I am not sure if thats to be expected. i5# dd if=/dev/zero of=/mnt/test bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 13.996080 secs (7491926 bytes/sec) i5# One extra bit of oddness with graid, is that if I disable the RAID in the BIOS and boot up the disks just with plain old AHCI, graid still works. Is that a quirk of the BIOS, or does it generally work that way? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interrupt storm with MSI in combination with em1
On 5/6/2011 11:02 AM, Daan Vreeken wrote: One core is spending half it's time handling interrupts. /var/log/messages doesn't show any new message since the storm started. vmstat -i now shows : # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Apart from spending far too much time handling interrupts, the machine works fine, so I'll let it run in case anyone wants me to try something on it. Do you have any usb devices plugged in ? ie what does usbconfig show ? Also, what USB settings do you have in the BIOS ? I would try disabling usb legacy mode and and things like 80-64 translation. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
On 4/27/2011 2:35 PM, Olivier Smedts wrote: 2011/4/27 Jack Vogel jfvo...@gmail.com: If you get cannot setup receive structures you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Thanks for your answer. I'll try and let you know if this works, but why don't have I enough mbuf clusters ? Isn't this driver supposed to just work out of the box on a nearly GENERIC (but with network devices as modules) kernel ? Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
On 4/27/2011 2:45 PM, Olivier Smedts wrote: Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. I'm using what's in HEAD since r219753, the commit which updated the em driver from version 7.1.9 to 7.2.2 and broke it at least for me. Oh, ok. Thats from back in March. There is a newer one 7.2.3 in April. I would test with that perhaps. I am using a back ported version on RELENG8 and it works quite well for me. http://lists.freebsd.org/pipermail/svn-src-head/2011-April/026202.html Hopefully MFC'd soon ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
On 3/31/2011 11:20 AM, Olivier Smedts wrote: Hello, I've got a problem under FreeBSD 9.0-CURRENT amd64 with the em driver. It's loaded as a module. I was previously using r219710 (2011-03-17) without any problem, but with latest HEAD I can't even send a ping. Here's what appears in dmesg. I tried unloading / loading the module, did not help. At the end I loaded my old if_em.ko and it worked : I ran into a similar problem with specific types of em NICs. For some reason, if it was compiled into the kernel it worked. As a module doing a netboot, it would fail. Does it work for you if the driver is statically compiled into the kernel by chance ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About panic: bufwrite: buffer is not busy???
On 2/21/2011 4:10 PM, Kostik Belousov wrote:
Is this reproducable ?
The box seems to have a number of bugs it has been triggering.
g...@freebsd.org's netgraph patch, seems to have fixed one of them. Max seems
to have fixed two others. This one, I am not sure. I can re-enable memguard to
randomly sample again, which is what seemed to have caught / triggered it.
What system version is it ?
8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #11: Thu Feb 17 i386, 4G of RAM
Could you, please, go to frame 12 and show the output of p *p,
p *(p-p_ucred) ?
(kgdb) frame 12
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
1950crcopy(cr, oldcred);
(kgdb) list
1945PROC_UNLOCK(p);
1946crextend(cr, groups);
1947PROC_LOCK(p);
1948oldcred = p-p_ucred;
1949}
1950crcopy(cr, oldcred);
1951
1952return (oldcred);
1953}
1954
(kgdb) p *(p-p_ucred)
$1 = {cr_ref = 3373030400, cr_uid = 3460374784, cr_ruid = 3231313392, cr_svuid
= 7196, cr_ngroups = 0, cr_rgid = 503415038, cr_svgid = 0, cr_uidinfo = 0x0,
cr_ruidinfo = 0x0,
cr_prison = 0x0, cr_pspare = 0x, cr_flags = 4294967295, cr_pspare2 =
{0x0, 0x0}, cr_label = 0x, cr_audit = {ai_auid = 0, ai_mask =
{am_success = 0,
am_failure = 1298034100}, ai_termid = {at_port = 3, at_type = 1, at_addr
= {0, 64, 0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xc9e37900,
cr_agroups = 16}
(kgdb) p *p
$2 = {p_list = {le_next = 0xc93ed560, le_prev = 0xc9187ac0}, p_threads =
{tqh_first = 0xc9196b80, tqh_last = 0xc9196b88}, p_slock = {lock_object = {
lo_name = 0xc08efca2 process slock, lo_flags = 720896, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xce3ee600, p_fd = 0xc9559100,
p_fdtol = 0x0,
p_stats = 0xc90cd600, p_limit = 0xc912d600, p_limco = {c_links = {sle =
{sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg =
0x0, c_func = 0,
c_lock = 0xc90cc898, c_flags = 0, c_cpu = 0}, p_sigacts = 0xc911f000,
p_flag = 268435713, p_state = PRS_NORMAL, p_pid = 565, p_hash = {le_next = 0x0,
le_prev = 0xc8d148d4},
p_pglist = {le_next = 0x0, le_prev = 0xc90c85c8}, p_pptr = 0xc8d2b000,
p_sibling = {le_next = 0xc93ed560, le_prev = 0xc9187b3c}, p_children =
{lh_first = 0x0}, p_mtx = {
lock_object = {lo_name = 0xc08efc95 process lock, lo_flags = 21168128,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 3373886336}, p_ksi = 0xc908f9b0,
p_sigqueue = {
sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}},
sq_list = {tqh_first = 0x0, tqh_last = 0xc90cc8d0}, sq_proc = 0xc90cc810,
sq_flags = 1},
p_oppid = 0, p_vmspace = 0xc93f0e80, p_swtick = 6600, p_realtimer =
{it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec =
0}}, p_ru = {ru_utime = {
tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss
= 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0,
ru_nswap = 0,
ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals =
0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 109046064880,
rux_uticks = 1368,
rux_sticks = 5393, rux_iticks = 0, rux_uu = 10366008, rux_su = 40860399,
rux_tu = 51225136}, p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0,
rux_iticks = 0,
rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0,
p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xc95bf96c,
p_lock = 0,
p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0,
p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo =
0x0, p_aioinfo = 0x0,
p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0,
p_pendingcnt = 0, p_itimers = 0x0, p_magic = 3203398350, p_osrel = 802500,
p_comm = zebra, '\0' repeats 14 times, p_pgrp = 0xc90c85c0, p_sysent =
0xc095c800, p_args = 0xc90c8440, p_cpulimit = 9223372036854775807, p_nice = 0
'\0', p_fibnum = 0,
p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc062a990
knlist_mtx_lock, kl_unlock = 0xc062a940 knlist_mtx_unlock,
kl_assert_locked = 0xc06275f0 knlist_mtx_assert_locked,
kl_assert_unlocked = 0xc0627600 knlist_mtx_assert_unlocked, kl_lockarg =
0xc90cc898}, p_numthreads = 1, p_md = {
md_ldt = 0x0}, p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe =
{tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock
= 0x0, c_flags = 16,
c_cpu = 0}, p_acflag = 1, p_peers = 0x0, p_leader = 0xc90cc810, p_emuldata
= 0x0, p_label = 0x0, p_sched = 0xc90ccac0, p_ktr = {stqh_first = 0x0,
stqh_last = 0xc90ccaa0},
p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0, p_pwait = {cv_description =
0xc08f00ef ppwait, cv_waiters = 0}, p_dbgwait = {cv_description = 0xc08f00f6
dbgwait,
cv_waiters = 0}}
(kgdb)
--
---
Mike
Re: About panic: bufwrite: buffer is not busy???
On 2/20/2011 9:33 AM, Andrey Smagin wrote:
On week -current I have same problem, my box paniced every 2-15 min. I
resolve problem by next steps - unplug network connectors from 2 intel em
(82574L) cards. I think last time that mpd5 related panic, but mpd5 work with
another re interface interated on MB. I think it may be em related panic, or
em+mpd5.
The latest panic I saw didnt have anything to do with em. Are you sure
your crashes are because of the nic drive ?
The latest I saw was on Friday.
# kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-106856,
dummy4=0xc6b9696c ) at /usr/src/sys/ddb/db_command.c:548
#2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04a764d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at
/usr/src/sys/kern/subr_kdb.c:546
#6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at
/usr/src/sys/i386/i386/trap.c:937
#7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at
/usr/src/sys/i386/i386/trap.c:859
#8 0xc0880d4a in trap (frame=0xc6b96b94) at
/usr/src/sys/i386/i386/trap.c:532
#9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
#11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at
/usr/src/sys/kern/kern_prot.c:1873
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
#13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at
/usr/src/sys/kern/kern_prot.c:615
#14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at
/usr/src/sys/kern/subr_trap.c:315
#15 0xc0880884 in syscall (frame=0xc6b96d28) at
/usr/src/sys/i386/i386/trap.c:1061
#16 0xc08671d1 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:264
#17 0x0033 in ?? ()
(kgdb) frame 10
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
1248{
(kgdb) list
1243 * Place another refcount on a uidinfo struct.
1244 */
1245void
1246uihold(uip)
1247struct uidinfo *uip;
1248{
1249
1250refcount_acquire(uip-ui_ref);
1251}
1252
(kgdb) p *uip
Cannot access memory at address 0x0
(kgdb) p uip
$1 = (struct uidinfo *) 0x0
(kgdb)
Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer
abo...@averesystems.com:
Moving this to -current and -stable and following up...
Something is broken with coredumps on stable/8 amd64. I tried a vanilla
8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with
'sysctl
debug.kdb.panic=1'.
For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image,
installed on ad7 (a 250GB SATA drive), used the default partition map, and
set
dumpdev to AUTO.
I added enough tracing to show that the second panic is due to the syncer
process flushing buffers to the other filesystems in parallel with the dump.
I've seen this panic and a similar one 'buffer not locked' coming from
ffs_write(). One time out of about 30 the core ran to completion, but slowly
(~1MB/sec). Other times the dump just locks up completely with no other
output.
Does anyone know what might have changed to expose this problem?
I don't ever see it under 7.1.
Thanks,
Andrew
On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote:
On 02.02.2011 00:50, Gleb Smirnoff wrote:
E Uptime: 8h3m51s
E Dumping 4087 MB (3 chunks)
E chunk 0: 1MB (150 pages) ... ok
E chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not
busy???
E cpuid = 3
E Uptime: 8h3m52s
E Automatic reboot in 15 seconds - press a key on the console to abort
Can you add KDB_TRACE option to kernel? Your boxes for some reason can't
dump core, but with this option we will have at least trace.
I see Mike Tancsa's box has bufwrite: buffer is not busy??? problem too.
Has anyone a thought how to fix generation of crashdumps?
Eugene Grosbein
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Andrew Boyer abo...@averesystems.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current
Re: [head tinderbox] failure on amd64/amd64
On 1/20/2011 9:30 AM, Matthew Fleming wrote: As far as I can tell this is another cvsup / tinderbox bug. Both sysctl.h and tsc.c were modified in r217616 but somehow tsc.c is seeing the old version of sysctl.h. This happened on another of my commits a few weeks ago. Sometimes it takes a bit to get all the updates. The tinderbox syncs off my local cvsup server which gets its updates from cvsup18 once per hr. You can check its progress at http://tinderbox.freebsd.org/ It has since built amd64 ---Mike Hmm, does bumping __FreeBSD_version have anything to do with this? I belatedly realize that I should have done it for that rev since the name of a kernel interface changed. Thanks, matthew On Wed, Jan 19, 2011 at 10:18 PM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-01-20 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 03:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-20 03:55:00 - cleaning the object tree TB --- 2011-01-20 03:55:27 - cvsupping the source tree TB --- 2011-01-20 03:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-20 03:55:39 - building world TB --- 2011-01-20 03:55:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 03:55:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 03:55:39 - TARGET=amd64 TB --- 2011-01-20 03:55:39 - TARGET_ARCH=amd64 TB --- 2011-01-20 03:55:39 - TZ=UTC TB --- 2011-01-20 03:55:39 - __MAKE_CONF=/dev/null TB --- 2011-01-20 03:55:39 - cd /src TB --- 2011-01-20 03:55:39 - /usr/bin/make -B buildworld World build started on Thu Jan 20 03:55:43 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Jan 20 06:04:21 UTC 2011 TB --- 2011-01-20 06:04:21 - generating LINT kernel config TB --- 2011-01-20 06:04:21 - cd /src/sys/amd64/conf TB --- 2011-01-20 06:04:21 - /usr/bin/make -B LINT TB --- 2011-01-20 06:04:21 - building LINT kernel TB --- 2011-01-20 06:04:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 06:04:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 06:04:21 - TARGET=amd64 TB --- 2011-01-20 06:04:21 - TARGET_ARCH=amd64 TB --- 2011-01-20 06:04:21 - TZ=UTC TB --- 2011-01-20 06:04:21 - __MAKE_CONF=/dev/null TB --- 2011-01-20 06:04:21 - cd /src TB --- 2011-01-20 06:04:21 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 06:04:21 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/nexus.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/tsc.c cc1: warnings being treated as errors /src/sys/x86/x86/tsc.c: In function 'sysctl_machdep_tsc_freq': /src/sys/x86/x86/tsc.c:266: warning: implicit declaration of function 'sysctl_handle_64' /src/sys/x86/x86/tsc.c:266: warning: nested extern declaration of 'sysctl_handle_64' /src/sys/x86/x86/tsc.c: At top level: /src/sys/x86/x86/tsc.c:274: error: 'CTLTYPE_U64' undeclared here (not in a function)
Re: [Soekris] Soekris net5501 - how to use hardware watchdog?
On 1/16/2011 9:45 PM, Mike Tancsa wrote: On 1/16/2011 6:17 PM, Marek Salwerowicz wrote: Hi all, what modules to kernel should I load in order to make use of hardware watchdog installed in Soekris net5501 ? Hi, Try adding option CPU_SOEKRIS Sorry, for the 5501 thats option CPU_GEODE ---Mike to your kernel. Then just startup /usr/sbin/watchdogd ---Mike ___ Soekris-tech mailing list soekris-t...@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Soekris] Soekris net5501 - how to use hardware watchdog?
On 1/17/2011 11:07 AM, Marek Salwerowicz wrote: Hi, Try adding option CPU_SOEKRIS Sorry, for the 5501 thats option CPU_GEODE ---Mike I have added both. Is there any possible test to check if watchdog really does reboot ? Just start /usr/sbin/watchdogd and then kill the process? Yes, but make sure you do kill -9, not just kill ---Mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Soekris net5501 - how to use hardware watchdog?
On 1/16/2011 6:17 PM, Marek Salwerowicz wrote: Hi all, what modules to kernel should I load in order to make use of hardware watchdog installed in Soekris net5501 ? Hi, Try adding option CPU_SOEKRIS to your kernel. Then just startup /usr/sbin/watchdogd ---Mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on powerpc64/powerpc
On 12/21/2010 5:49 PM, Matthew Fleming wrote: /src/sys/kern/kern_fail.c:557: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c:557: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c:557: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c:557: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c:557: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c: In function 'clear_entries': /src/sys/kern/kern_fail.c:569: error: dereferencing pointer to incomplete type /src/sys/kern/kern_fail.c:569: warning: left-hand operand of comma expression has no effect *** Error code 1 I think Tinderbox has a bad source tree. Lines 557 and 569 make sense from the old version of kern_fail.c before either of my commits. So is Tinderbox somehow building with an old kern_fail.c but an updated sys/fail.h? That would explain the build error, but I have no idea how it could have gotten into such a situation. It updates from my local mirror which updates from cvsup18. The last update was CVSup update ends at 2010-12-21 16:44:39 CVSup update begins at 2010-12-21 17:43:00 Updating from cvsup18.freebsd.org Connected to cvsup18.freebsd.org Updating collection cvs-all/cvs Append to CVSROOT-ports/commitlogs/ports Append to CVSROOT-src/commitlogs/sys Edit ports/devel/p5-DateTime-Format-Strptime/Makefile,v Edit ports/devel/p5-DateTime-Format-Strptime/distinfo,v Edit ports/multimedia/playd/Makefile,v Edit ports/multimedia/playd/distinfo,v Edit src/sys/nfsserver/nfs_srvsubs.c,v src/sys/nfsserver/nfs_srvsubs.c,v: Checksum mismatch -- will transfer entire file Edit src/sys/sparc64/include/cpufunc.h,v src/sys/sparc64/include/cpufunc.h,v: Checksum mismatch -- will transfer entire file Edit src/sys/sparc64/include/vmparam.h,v src/sys/sparc64/include/vmparam.h,v: Checksum mismatch -- will transfer entire file Edit src/sys/sparc64/sparc64/tick.c,v src/sys/sparc64/sparc64/tick.c,v: Checksum mismatch -- will transfer entire file Edit src/sys/sys/mount.h,v src/sys/sys/mount.h,v: Checksum mismatch -- will transfer entire file Skipping collection gnats/current Skipping collection www/current Skipping collection mail-archive/current Updating collection distrib/self Applying fixups for collection cvs-all/cvs Fixup src/sys/nfsserver/nfs_srvsubs.c,v Fixup src/sys/sparc64/include/cpufunc.h,v Fixup src/sys/sparc64/include/vmparam.h,v Fixup src/sys/sparc64/sparc64/tick.c,v Fixup src/sys/sys/mount.h,v Finished successfully CVSup update ends at 2010-12-21 17:45:11 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On 12/7/2010 6:07 AM, Bjoern A. Zeeb wrote: On Tue, 7 Dec 2010, Alexander Motin wrote: Does mpd work in -current ? Last tried I, netgraph had problems with mpd. Sure it does! What is the problem? There have been several reports (incl. panics) on various lists like net, stable, ... during the last months for mostly 8.x (and HEAD). None of which was really followed up to to my memory. From a kernel from Sept2, I would get this panic / crash after a week of running mpd with ipv6 enabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc5ef3e15 stack pointer = 0x28:0xc4fe4838 frame pointer = 0x28:0xc4fe484c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1000 (ng_queue1) trap number = 12 panic: page fault cpuid = 1 Uptime: 6d4h9m42s Physical memory: 2036 MB Dumping 240 MB: 225 209 193 177panic: bufwrite: buffer is not busy??? cpuid = 1 161 145 129 113 97 81 65 49 33 17 1 (kgdb) #0 doadump () at pcpu.h:231 #1 0xc0681233 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0681499 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc08ea3ec in trap_fatal (frame=0xc4fe47f8, eva=36) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc08ea650 in trap_pfault (frame=0xc4fe47f8, usermode=0, eva=36) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc08eaf19 in trap (frame=0xc4fe47f8) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc08cd4bc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5ef3e15 in ng_address_hook (here=0x0, item=0xc5f03c40, hook=0xcb685980, retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3504 #8 0xc5f7ebfb in ng_tcpmss_rcvdata (hook=0xc6618300, item=0xc5f03c40) at /usr/src/sys/modules/netgraph/tcpmss/../../../netgraph/ng_tcpmss.c:347 #9 0xc5ef57c4 in ng_apply_item (node=0xca955b00, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #10 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable flags is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #11 0xc5f6dd30 in ng_ppp_proto_recv (node=0xc6431300, item=0xc5f03c40, proto=Variable proto is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:949 #12 0xc5f6ea25 in ng_ppp_rcvdata (hook=0xcb228a80, item=0xc5f03c40) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1524 #13 0xc5ef57c4 in ng_apply_item (node=0xc6431300, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #14 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable flags is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #15 0xc5ef57c4 in ng_apply_item (node=0xcb375c80, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #16 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable flags is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #17 0xc5ef57c4 in ng_apply_item (node=0xc6330100, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable flags is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #19 0xc5f4db1c in ng_ksocket_incoming2 (node=0xc6431e00, hook=0x0, arg1=0xc63479a8, arg2=0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1153 #20 0xc5ef58f9 in ng_apply_item (node=0xc6431e00, item=0xc5f02780, rw=1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #21 0xc5ef6a46 in ngthread (arg=0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3351 #22 0xc0656cd1 in fork_exit (callout=0xc5ef68e0 ngthread, arg=0x0, frame=0xc4fe4d38) at /usr/src/sys/kern/kern_fork.c:844 #23 0xc08cd534 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 (kgdb) Since there were a number of ipv6 patches, I thought I would try again with a kernel from today as well as the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=148857 Still get the WITNESS warning below. Not sure if its a bad thing or has anything to do with the above panic. uma_zalloc_arg: zone 1024 with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0b67144) locked @ /usr/src/sys/net/if.c:434 KDB: stack backtrace: db_trace_self_wrapper(c0928b5a,c2d0,2e,0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(1b2,2,,c0b399d4,e7cda8f4,...) at
Re: [head tinderbox] failure on sparc64/sparc64
Sorry for the tinderbox breakagage again. Our main cvsup server seems to be triggering a bug in the em driver :( I will point it to an outside mirror for now... ---Mike At 12:38 PM 9/19/2010, FreeBSD Tinderbox wrote: TB --- 2010-09-19 16:01:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-19 16:01:48 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-09-19 16:01:48 - cleaning the object tree TB --- 2010-09-19 16:02:24 - cvsupping the source tree TB --- 2010-09-19 16:02:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-09-19 16:38:13 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-19 16:38:13 - ERROR: unable to cvsup the source tree TB --- 2010-09-19 16:38:13 - 0.77 user 25.64 system 2184.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
At 06:57 PM 9/9/2010, Doug Barton wrote: Normally they are pointed to a local mirror here at Sentex. However, that server was having hardware problems which I think we have isolated and resolved now. I will repoint this tinderbox to the local site again. The best way to handle this would be to have messages about csup failing to be directed only to those who are actually able to fix the problem. Assuming that the cvsup server is always going to work is contrary to both history and good system administration practices. :) Perhaps as an interim measure a local procmail rule to filter out cvsup failures from going to the list ? That's a particularly unhelpful response. Not only is it borderline rude to attempt to shift the responsibility for this to the users, it's a violation of the robustness principle. I meant local procmail rule as in local to the tinderboxes so that des and myself and others who admin the boxes only get such messages. I didnt want to make such changes without des' approval and was waiting for his input... ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
At 02:02 PM 9/10/2010, Doug Barton wrote: In that case I apologize for the misunderstanding. I've used procmail for many years on the receiving end but was not aware of the ability to use it in the manner you suggested. Have the tinderbox send just one email to a local account, then use procmailrc to figure out where to send copies. ---Mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
At 09:07 AM 9/8/2010, Denny Lin wrote: On Wed, Sep 08, 2010 at 04:55:14AM -0700, Rob Farmer wrote: TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit code  1 TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real Is it possible to either have the tinderbox try multiple cvsup servers or just not send a message if cvsup fails? Counting all branches and all archs, there have been around 50 ERROR: unable to cvsup the source tree mails in the last week. I don't think Tinderbox supports multiple CVSup servers at the moment. It seems like a desirable feature. Normally they are pointed to a local mirror here at Sentex. However, that server was having hardware problems which I think we have isolated and resolved now. I will repoint this tinderbox to the local site again. Perhaps as an interim measure a local procmail rule to filter out cvsup failures from going to the list ? ---Mike -- Denny Lin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
re: svn commit: r211908 - head/sys/dev/ichwd
Hi Jack, I was trying to see if your recent commits for the ichwd IDs now work with the integrated watchdog for my i5 boards, but no luck. ichsmb0: Intel PCH SMBus controller port 0x3000-0x301f mem 0xb1b23000-0xb1b230ff irq 18 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: System Management Bus on ichsmb0 ichwd0: Intel 3420 watchdog timer on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r211908 - head/sys/dev/ichwd
At 12:51 PM 8/30/2010, Olivier Smedts wrote: By any chance, is it disabled in BIOS ? Hi, There are a couple of options in the BIOS. There is a reboot the box if the bios does not post within 6min as well as Fire the watchdog if the dog has not been patted after 5,10 or 15min after the BIOS post. I tried all combinations without luck. If I have the reboot after x min post post, the box will reboot on its own. ---Mike Cheers, Olivier This is an actual Intel server MB (INTEL S3420GPC) and the WD is enabled in the bios. Are you able to actually get it to work on this board ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r211908 - head/sys/dev/ichwd
At 02:47 PM 8/30/2010, Xin LI wrote: My guess is that your motherboard provided another watchdog (like Winbond based super I/O chips) which requires a driver, you can try this one if you wish: http://people.freebsd.org/~delphij/for_review/winbondwd/ I've no idea about your ichwd issue though. Hi, Thanks for the link! I had a look on Intel's site and didnt find anything specifically mentioning the type of watchdog. This is an actual intel branded board and not supermicro. No luck with the driver. However, I will give it a try on some of the MBs that do have Winbond WDs. A long time ago I hacked together one for the 83697 http://www.tancsa.com/watchdog/itxwd-1.0/ ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on powerpc64/powerpc
At 07:29 PM 8/29/2010, Nathan Whitehorn wrote: Is something wrong with cvsup? This bug was fixed two days ago in SVN. Hi, There was a problem with the crontab entry on the local cvsup mirror that the tinder box syncs from for weekend runs / updates. I have fixed the ctab entry and kicked cvsup to start its updates now. ---Mike -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on em in HEAD ( was Re: em driver regression
-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 est2: Enhanced SpeedStep Frequency Control on cpu2 p4tcc2: CPU Frequency Thermal Control on cpu2 est3: Enhanced SpeedStep Frequency Control on cpu3 p4tcc3: CPU Frequency Thermal Control on cpu3 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: Intel at usbus0 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST3250318AS CC35 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich3 bus 0 scbus3 target 0 lun 0 ada1: ST3250318AS CC35 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: vendor 0x8087 at usbus0 ugen1.2: vendor 0x8087 at usbus1 uhub2: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2 on usbus0 uhub3: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2 on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen1.3: American Megatrends Inc. at usbus1 ukbd0: Keyboard Interface on usbus1 kbd0 at ukbd0 ums0: Mouse Interface on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 Root mount waiting for: usbus1 ugen1.4: GASIA at usbus1 ukbd1: GASIA PS2toUSB Adapter, class 0/0, rev 1.10/1.00, addr 4 on usbus1 kbd2 at ukbd1 ums1: GASIA PS2toUSB Adapter, class 0/0, rev 1.10/1.00, addr 4 on usbus1 ums1: 5 buttons and [XYZ] coordinates ID=1 Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db Jack On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa mailto:m...@sentex.netm...@sentex.net wrote: At 04:13 PM 4/9/2010, Pyun YongHyeon wrote: On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: Someone else also pointed this out. I'm dubious about its claim. I can't reproduce the LOR with latest em(4)(r206429). I still get it for some reason 1st 0xc5dc7610 em1:rx(1) (em1:rx(1)) @ /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4087 2nd 0xc0f7df0c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 KDB: stack backtrace: db_trace_self_wrapper(c0cb4313,c5b72a64,c08e4305,c08d467b,c0cb7338,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d467b,c0cb7338,c5d31a98,c5d2cb60,c5b72ac0,...) at kdb_backtrace+0x29 _witness_debugger(c0cb7338,c0f7df0c,c0c9c4eb,c5d2cb60,c0ccfaf7,...) at _witness_debugger+0x25 witness_checkorder(c0f7df0c,1,c0ccfaf7,1c6,0,...) at witness_checkorder+0x839 _rw_rlock(c0f7df0c,c0ccfaf7,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c udp_input(c6905900,14,0,c5e8bd80,c0df9ee0,...) at udp_input+0x246 ip_input(c6905900,c5f39240,c5b72bdc,c0745956,c0df9ee0,...) at ip_input+0x606 netisr_dispatch_src(1,0,c6905900,c5b72c14,c0954161,...) at netisr_dispatch_src+0xcd netisr_dispatch(1,c6905900,c6018c00,c6018c00,c6925800,...) at netisr_dispatch+0x20 ether_demux(c6018c00,c6905900,3,0,3,...) at ether_demux+0x1a1 ether_input(c6018c00,c6905900,c119f2d7,ff7,63,...) at ether_input+0x365 em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x133 em_msix_rx(c5dc7600,c5b72cc8,c088e0b4
Re: LOR on em in HEAD ( was Re: em driver regression
At 03:29 PM 4/10/2010, Jack Vogel wrote: Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Looks good for me now. BTW, I thought the multi-queue was supposed to be disabled on the em nic ? em0: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x3040-0x305f mem 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 em1: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x1000-0x101f mem 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 0(i5b)% vmstat -i interrupt total rate irq4: uart0 6285 13 irq21: ehci0 728 1 irq23: ehci11078 2 cpu0: timer 924321 1992 irq256: em0 9375 20 irq257: em1 127 0 irq258: em17 0 irq261: em12 0 irq262: ahci0 69 0 cpu3: timer 923686 1990 cpu1: timer 923651 1990 cpu2: timer 923597 1990 Total3712926 8001 0(i5b)% e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb mailto:bzeeb-li...@lists.zabbadoz.netbzeeb-li...@lists.zabbadoz.net wrote: On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup ... Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.htmlhttp://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR on em in HEAD ( was Re: em driver regression
While testing an i5 box with HEAD checked out from this morning, bringing up the second NIC generated this LOR on the console em1: link state changed to UP lock order reversal: 1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @ /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089 2nd 0xc0f7e88c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 KDB: stack backtrace: db_trace_self_wrapper(c0cb4d33,c5b72a70,c08e4d65,c08d50db,c0cb7d58,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d50db,c0cb7d58,c5d31a98,c5d2cb60,c5b72acc,...) at kdb_backtrace+0x29 _witness_debugger(c0cb7d58,c0f7e88c,c0c9cf0b,c5d2cb60,c0cd04ca,...) at _witness_debugger+0x25 witness_checkorder(c0f7e88c,1,c0cd04ca,1c6,0,...) at witness_checkorder+0x839 _rw_rlock(c0f7e88c,c0cd04ca,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c udp_input(c67faa00,14,0,c5e8bd80,c0dfa860,...) at udp_input+0x246 ip_input(c67faa00,c5f2f380,c5b72be8,c07463b6,c0dfa860,...) at ip_input+0x606 netisr_dispatch_src(1,0,c67faa00,c5b72c20,c0954bc1,...) at netisr_dispatch_src+0xcd netisr_dispatch(1,c67faa00,c6018c00,c6018c00,c6852800,...) at netisr_dispatch+0x20 ether_demux(c6018c00,c67faa00,3,0,3,...) at ether_demux+0x1a1 ether_input(c6018c00,c67faa00,c11a0e17,ff9,64,...) at ether_input+0x365 em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x13c em_msix_rx(c5dc7c00,c5b72cc8,c088eb14,c0e133c0,c60342b8,...) at em_msix_rx+0x25 intr_event_execute_handlers(c5d807f8,c6034280,c0cacd7e,533,c60342f0,...) at intr_event_execute_handlers+0x125 ithread_loop(c603b4a0,c5b72d38,c0cacaed,343,c5d807f8,...) at ithread_loop+0x9f fork_exit(c0877800,c603b4a0,c5b72d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- 0(i5b)# uname -a FreeBSD i5b.sentex.ca 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Apr 9 11:56:25 EDT 2010 mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/GENERIC i386 0(i5b)# e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled 0(i5b)# vmstat -i interrupt total rate irq4: uart0 6156 3 irq8: rtc 224879127 irq21: ehci02662 1 irq23: ehci13674 2 cpu0: timer 1754210998 irq256: em010778 6 irq257: em1 331 0 irq258: em14 0 irq260: em14 0 irq261: em18 0 irq262: ahci0 69 0 cpu3: timer 1753938998 cpu2: timer 1753932998 cpu1: timer 1753886998 Total7264531 4134 0(i5b)# CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x2810NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 2577711104 (2458 MB) ACPI APIC Table: INTEL S3420GPC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
