Re: ggate + gmirror write performance woes
Hi!
On Thu, Apr 05, 2007 at 04:15:35PM -0400, Sven Willenberger wrote:
I have tried both the settings ideas suggested above but I cannot even
get out of the gate with those. Setting net.inet.tcp.{send,recv}space to
setting net.inet.tcp.{send,recv}space to 131072 allows me to start
Now you have good chance to check differences with other recommended
sysctl's. :)
WBR
Dmitriy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Repeatable crash with mkdir causing a divide by zero error
Hi,
I have seen some problems with a new file system that I created
yesterday in that I could repeatedly get the system to crash in with a
mkdir.
Here is the disk information
mfid1: MFI Logical Disk on mfi1
mfid1: 5716992MB (11708399616 sectors) RAID volume 'Images' is optimal
I created a new file system tuned for 64k blocks, an average file size
of 1Mb, and 2500 files per directory.
newfs -b 65535 -g 1048576 -h 2500 /dev/mfid1p1
mount /dev/mfid1p1 /compere
mkdir /compere/images
mkdir /compere/images/1999
(Also tested with mkdir test; mkdir test/1998)
The system is and amd64 system running 6.2-RELEASE and the pmap.c patch.
I have 3 cores cause by 3 different apps (rsync, gmkdir, mkdir) and
can provide any more information if required. I have attached a back
trace, unfortunatly I cannot do any testing as the system is now in
testing (newfs -b 65535 -g 1048576 /dev/mfid1p1 was used and seems not
to cause the bug).
kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug /var/crash/vmcore.2
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x8:0x80391347
stack pointer = 0x10:0xa78736f0
frame pointer = 0x10:0xff0001d7a600
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 = 1206 (mkdir)
trap number = 18
panic: integer divide fault
cpuid = 0
Uptime: 4m29s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 1023MB (261800 pages) 1007 991 975 959 943 927 911 895 879
863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591
575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x8029a557 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x8029abf1 in panic (fmt=0xff0029753000 X?/) at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x803f62ff in trap_fatal (frame=0xff0029753000,
eva=18446742974994109272) at /usr/src/sys/amd64/amd64/trap.c:660
#5 0x803f67a2 in trap (frame=
{tf_rdi = 0, tf_rsi = 0, tf_rdx = 0, tf_rcx = 1951858688, tf_r8 =
2500, tf_r9 = 2975, tf_rax = 1951858688, tf_rbx = -2050457600, tf_rbp =
-1099480717824, tf_r10 = 246016, tf_r11 = 184512, tf_r12 =
-1098707543808, tf_r13 = 246015, tf_r14 = -2050457600, tf_r15 = 255,
tf_trapno = 18, tf_addr = 0, tf_flags = 2147483648012, tf_err = 0,
tf_rip = -2143743161, tf_cs = 8, tf_rflags = 66182, tf_rsp =
-1484310784, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469
#6 0x803e1a6b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0,
mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56
#8 0x803b8a5e in ufs_mkdir (ap=0xa78739a0) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1386
#9 0x8043b355 in VOP_MKDIR_APV (vop=0x7457,
a=0xa78739a0) at vnode_if.c:1251
#10 0x80310e19 in kern_mkdir (td=0xff002f24d7c0,
path=0xff003dabe400 , segflg=4, mode=511) at vnode_if.h:653
#11 0x803f7151 in syscall (frame=
{tf_rdi = 140737488348678, tf_rsi = 511, tf_rdx = 4294967295,
tf_rcx = 1, tf_r8 = 0, tf_r9 = 140737488347272, tf_rax = 136, tf_rbx =
2, tf_rbp = 140737488348024, tf_r10 = 4294967295, tf_r11 = 582, tf_r12 =
140737488348678, tf_r13 = 140737488348008, tf_r14 = 0, tf_r15 = 0,
tf_trapno = 12, tf_addr = 34367037072, tf_flags = 0, tf_err = 2, tf_rip
= 34367037084, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488347720,
tf_ss = 35})
at /usr/src/sys/amd64/amd64/trap.c:792
#12 0x803e1c08 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:270
#13 0x0008006f5e9c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0,
mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56
56 static __inline u_int min(u_int a, u_int b) { return (a b ? a
: b); }
(kgdb) list
51 static __inline int imax(int a, int b) { return (a b ? a : b); }
52 static
Re: Do we need this junk?
Dag-Erling Smørgrav wrote: Nikolas Britton [EMAIL PROTECTED] writes: Can anything in the list below be removed from CURRENT? No. Modern i386 and amd64 still have an ISA bus, and devices connected to that bus, even if they don't have ISA slots. Some mainboards for industrial use even have them today... And the main CPU is a Pentium 4 or AMD 64 ;) Philipp -- www.familie-ost.info/~pj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggate + gmirror write performance woes
Sven Willenberger wrote:
On Thu, 2007-04-05 at 17:38 +0100, Tom Judge wrote:
Dmitriy Kirhlarov wrote:
On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote:
I am trying to set up a HA type system involving two identical boxes and
have gone through the following to set up the systems:
Slave server:
ggated -R 196608 -S 196608
(exporting /dev/amrd1 )
net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 131072
Try
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
Also, try increase this sysctls with
net.inet.tcp.rfc1323=1
I use it on FreeBSD 5.x with:
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
ggated -R 1048576 -S 1048576
ggatec -R 1048576 -S 1048576
WBR.
Dmitriy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
I have seen sustained writes of 30Mb/s using the following configuration:
cat /boot/loader.conf
kern.ipc.nmbclusters=32768
cat /etc/sysctl.conf
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576
Server:
/sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports
Client:
/sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18
/dev/amrd0s2
The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with
adaptive read ahead and write back caching.
Tom
I have tried both the settings ideas suggested above but I cannot even
get out of the gate with those. Setting net.inet.tcp.{send,recv}space to
anything higher that 131072 results in ggated bailing with the error:
# ggated -v -a 10.10.0.19
info: Reading exports file (/etc/gg.exports).
debug: Added 10.10.0.0/24 /dev/amrd1 RW to exports list.
debug: Added 10.10.0.0/24 /dev/amrd3 RW to exports list.
info: Exporting 2 object(s).
error: Cannot open stream socket: No buffer space available.
error: Exiting.
setting net.inet.tcp.{send,recv}space to 131072 allows me to start
ggated with the default R and S values of 131072; anything higher
results in no buffer space errors. At 131072 ggated starts but then I
cannot even open a new connection (like ssh) to the server as the ssh
client bails with no buffer space available.
Did you also set kern.ipc.nmbclusters=32768 in /boot/loader.conf and
reboot? It sounds like you did not as this is the exact same problem I
came across before adjusting that value.
SNIP
This is on a FreeBSD 6.2-RELENG box i386 SMP using the amr driver (SATA
Raid using LSiMegaRaid.
Do you have the cache BBU fitted (Batery Backup Unit) and the array
caching set to write back? Also have you tested writing to the array
locally without ggate to test the write speed?
The odd thing is that even after I set the send and recvspace down to
values like 65536, I continue to get the no buffer error when trying to
connect to it remotely again.
I found that the easyest way to fix this was to reboot the system with
good values for net.inet.tcp.{send,recv}space.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On Friday 06 April 2007 02:43, Kevin Oberman wrote: I always run a 2000 line scrollback buffer. 200 won't make it to the start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you refer to as 'slideshow like teleporting', though. in case someone want colourful console options SC_HISTORY_SIZE=1000 options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
re(4) can't receive some multicast ?
Hi, I have ASUS P5B, running FreeBSD 6.2-STABLE. It has on-board re(4) as follows, re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xa800-0xa8ff mem 0xfe9ff000-0xfe9f irq 19 at device 0.0 on pci3 miibus1: MII bus on re0 rgephy0: RTL8169S/8110S media interface on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:6e:f2:a5 re0: [FAST] pciconf -lv [EMAIL PROTECTED]:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class = network subclass = ethernet # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX full-duplex) status: active # sysctl net.inet6.ip6.accept_rtadv net.inet6.ip6.accept_rtadv: 1 # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 send RS on re0, whose state is 2 send RS on re0, whose state is 2 No answer after sending 3 RSs stop timer for re0 there is no timer It seems re0 can't receive IPv6 RA message. But in promisc mode(running tcpdump on another terminal), it receives RA. # ifconfig re0 re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX full-duplex) status: active # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 received RA from fe80::230:48ff:fe81:e3fd on re0, state is 2 stop timer for re0 there is no timer # ifconfig re0 re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 inet6 2001:240:c4:1:21a:92ff:fe6e:f2a5 prefixlen 64 autoconf ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX full-duplex) status: active Any suggestions? Regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Hi list, All those things work only under i386 right ? There is no option VESA in amd64 ? Andrei Kolu wrote: On Friday 06 April 2007 02:43, Kevin Oberman wrote: I always run a 2000 line scrollback buffer. 200 won't make it to the start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you refer to as 'slideshow like teleporting', though. in case someone want colourful console options SC_HISTORY_SIZE=1000 options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggate + gmirror write performance woes
On Thursday, 5 April 2007 at 16:15:35 -0400, Sven Willenberger wrote:
On Thu, 2007-04-05 at 17:38 +0100, Tom Judge wrote:
Dmitriy Kirhlarov wrote:
On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote:
I am trying to set up a HA type system involving two identical boxes and
have gone through the following to set up the systems:
Slave server:
ggated -R 196608 -S 196608
(exporting /dev/amrd1 )
net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 131072
Try
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
Also, try increase this sysctls with
net.inet.tcp.rfc1323=1
I use it on FreeBSD 5.x with:
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
ggated -R 1048576 -S 1048576
ggatec -R 1048576 -S 1048576
WBR.
Dmitriy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
I have seen sustained writes of 30Mb/s using the following configuration:
cat /boot/loader.conf
kern.ipc.nmbclusters=32768
cat /etc/sysctl.conf
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576
Server:
/sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports
Client:
/sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18
/dev/amrd0s2
The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with
adaptive read ahead and write back caching.
Tom
I have tried both the settings ideas suggested above but I cannot even
get out of the gate with those. Setting net.inet.tcp.{send,recv}space to
anything higher that 131072 results in ggated bailing with the error:
# ggated -v -a 10.10.0.19
info: Reading exports file (/etc/gg.exports).
debug: Added 10.10.0.0/24 /dev/amrd1 RW to exports list.
debug: Added 10.10.0.0/24 /dev/amrd3 RW to exports list.
info: Exporting 2 object(s).
error: Cannot open stream socket: No buffer space available.
error: Exiting.
For values of net.inet.tcp.{send,recv}space more than
524288 you also need to adjust kern.ipc.maxsockbuf
Try this configuration for example:
kern.ipc.maxsockbuf=2049152
net.inet.tcp.recvspace=1024576
net.inet.tcp.sendspace=1024576
setting net.inet.tcp.{send,recv}space to 131072 allows me to start
ggated with the default R and S values of 131072; anything higher
results in no buffer space errors. At 131072 ggated starts but then I
cannot even open a new connection (like ssh) to the server as the ssh
client bails with no buffer space available.
more information:
# netstat -m
514/641/1155 mbufs in use (current/cache/total)
512/284/796/32768 mbuf clusters in use (current/cache/total/max)
512/256 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
1152K/728K/1880K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
This is on a FreeBSD 6.2-RELENG box i386 SMP using the amr driver (SATA
Raid using LSiMegaRaid.
The odd thing is that even after I set the send and recvspace down to
values like 65536, I continue to get the no buffer error when trying to
connect to it remotely again.
Sven
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
==
- Best regards, Nikolay Pavlov. ---
==
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re(4) can't receive some multicast ?
From: FUJITA Kazutoshi [EMAIL PROTECTED] Subject: re(4) can't receive some multicast ? Date: Fri, 06 Apr 2007 20:01:05 +0900 (JST) I have ASUS P5B, running FreeBSD 6.2-STABLE. It has on-board re(4) as follows, It seems re0 can't receive IPv6 RA message. But in promisc mode(running tcpdump on another terminal), it receives RA. Sorry, this is known problem. -CURRENT re(4) handles variant and it works fine for me. Regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 watchdog timeout with nfs
Hi, Jack, Jack Vogel wrote: [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [...] The driver in 6.2 RELEASE fixed all known problems with watchdogs, other than REAL issues with the network/hardware. Have you tried installing that? A friend of mine has reported similar problem, with different em(4) hardware. The server runs lighttpd on ufs, and the watchdog timeout occurs no matter whether there is heavy traffic. Here is some pciconf -l output which can be interesting. [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 rev=0x05 hdr=0x00 Should more debugging aid / information is needed to narrow down the issue please let us know, thanks! Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: em0 watchdog timeout with nfs
LI Xin wrote: Hi, Jack, Jack Vogel wrote: [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [...] The driver in 6.2 RELEASE fixed all known problems with watchdogs, other than REAL issues with the network/hardware. Have you tried installing that? A friend of mine has reported similar problem, with different em(4) hardware. The server runs lighttpd on ufs, and the watchdog timeout occurs no matter whether there is heavy traffic. Here is some pciconf -l output which can be interesting. [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 rev=0x05 hdr=0x00 Should more debugging aid / information is needed to narrow down the issue please let us know, thanks! Forgot to mention, the em0 (which have watchdog issue) has device polling turned on. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: em0 watchdog timeout with nfs
LI Xin wrote: Hi, Jack, Jack Vogel wrote: [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [...] The driver in 6.2 RELEASE fixed all known problems with watchdogs, other than REAL issues with the network/hardware. Have you tried installing that? A friend of mine has reported similar problem, with different em(4) hardware. The server runs lighttpd on ufs, and the watchdog timeout occurs no matter whether there is heavy traffic. Here is some pciconf -l output which can be interesting. [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 rev=0x05 hdr=0x00 Should more debugging aid / information is needed to narrow down the issue please let us know, thanks! I've reported similar problems multiple times w/o any response. My nic is onboard (no msi involved, no polling used): [EMAIL PROTECTED]:1:0: class=0x02 card=0x80f71043 chip=0x10198086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller (LOM)' class = network subclass = ethernet trouble% ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:11:2f:9e:c0:e5 inet 10.0.0.248 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active When I boot I also see massive #'s of link state transitions while dhclient fetches a lease. I've swapped cables, switch ports, etc. I can believe it might be a h/w failure but was hoping I could isolate the issue to be certain (don't like discarding the onboard nic). This is a very current HEAD and has been a problem for several months (all against HEAD). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for Testers: ncurses 5.6 update
Hi list,
Rong-en Fan wrote:
On 3/13/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hello,
Rong-en Fan wrote:
On 3/12/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Rong-en Fan wrote:
Hi folks,
ncurses in 6.x is pretty old. We have update-to-date ncurses in 7.x
with wide character support now. The patch at
http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070310.diff.gz
gives you ncurses 5.6 and wide character support in 6.x. Please
apply with 'patch -p0' under /usr/src.
For more information, please visit
http://people.freebsd.org/~rafan/ncurses/
You can also find individual patches, say ncurses update and wide
character support, there.
Feedbacks and suggestions are welcome.
P.S. Due to some lib32 issues, the patch above contains changes
made by ru@ recently for src/Makefile.inc1.
make installworld failed:
cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1
install32
mkdir -p /usr/lib32 # XXX add to mtree
[...]
Sorry about this. I messed up the lib32 changes in the all-in-one
patch.
Could you please use this one instead?
http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070312.diff.gz
This patch doesn't seems to work anymore on 6.2-stable i386 (my previous
test was on amd64)
It seems that part of this patch is already in -stable :)
If I'm right the patch for src/Makefile.inc1 should be replaced by :
--- Makefile.inc1 Fri Apr 6 20:03:35 2007
+++ /root/Makefile.inc1.origFri Apr 6 20:03:17 2007
@@ -894,8 +894,7 @@
bin/csh \
bin/sh \
${_rescue} \
-lib/ncurses/ncurses \
-lib/ncurses/ncursesw \
+lib/libncurses \
${_share} \
${_aicasm} \
usr.bin/awk \
@@ -1000,8 +999,7 @@
_prebuild_libs+= lib/libbz2 lib/libcom_err lib/libcrypt lib/libexpat \
lib/libkvm lib/libmd \
- lib/ncurses/ncurses lib/ncurses/ncursesw \
- lib/libnetgraph lib/libopie lib/libpam \
+ lib/libncurses lib/libnetgraph lib/libopie lib/libpam \
lib/libradius \
lib/libsbuf lib/libtacplus lib/libutil \
lib/libz lib/msun
I'm still compiling and will let you know if things still works.
This works for me (at least make buildworld make installworld
finished without problems).
Thanks for testing.
Should I recompile and the kernel again or the patch is only in
contrib ? :)
No you don't.
Regards,
Rong-En Fan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for Testers: ncurses 5.6 update
On 4/7/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hi list,
Rong-en Fan wrote:
On 3/13/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Hello,
Rong-en Fan wrote:
On 3/12/07, Stefan Lambrev [EMAIL PROTECTED] wrote:
Rong-en Fan wrote:
Hi folks,
ncurses in 6.x is pretty old. We have update-to-date ncurses in 7.x
with wide character support now. The patch at
http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070310.diff.gz
gives you ncurses 5.6 and wide character support in 6.x. Please
apply with 'patch -p0' under /usr/src.
For more information, please visit
http://people.freebsd.org/~rafan/ncurses/
You can also find individual patches, say ncurses update and wide
character support, there.
Feedbacks and suggestions are welcome.
P.S. Due to some lib32 issues, the patch above contains changes
made by ru@ recently for src/Makefile.inc1.
make installworld failed:
cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1
install32
mkdir -p /usr/lib32 # XXX add to mtree
[...]
Sorry about this. I messed up the lib32 changes in the all-in-one
patch.
Could you please use this one instead?
http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070312.diff.gz
This patch doesn't seems to work anymore on 6.2-stable i386 (my previous
test was on amd64)
It seems that part of this patch is already in -stable :)
If I'm right the patch for src/Makefile.inc1 should be replaced by :
--- Makefile.inc1 Fri Apr 6 20:03:35 2007
+++ /root/Makefile.inc1.origFri Apr 6 20:03:17 2007
@@ -894,8 +894,7 @@
bin/csh \
bin/sh \
${_rescue} \
-lib/ncurses/ncurses \
-lib/ncurses/ncursesw \
+lib/libncurses \
${_share} \
${_aicasm} \
usr.bin/awk \
@@ -1000,8 +999,7 @@
_prebuild_libs+= lib/libbz2 lib/libcom_err lib/libcrypt lib/libexpat \
lib/libkvm lib/libmd \
- lib/ncurses/ncurses lib/ncurses/ncursesw \
- lib/libnetgraph lib/libopie lib/libpam \
+ lib/libncurses lib/libnetgraph lib/libopie lib/libpam \
lib/libradius \
lib/libsbuf lib/libtacplus lib/libutil \
lib/libz lib/msun
I'm still compiling and will let you know if things still works.
Yes, you are right. I merged Makefile.inc1 changes two days ago. I'm
going to merge the whole changes later.
Enjoy!
Regards,
Rong-En Fan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Date: Fri, 06 Apr 2007 15:13:33 +0300 From: Stefan Lambrev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi list, All those things work only under i386 right ? There is no option VESA in amd64 ? Andrei Kolu wrote: On Friday 06 April 2007 02:43, Kevin Oberman wrote: I always run a 2000 line scrollback buffer. 200 won't make it to the start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you refer to as 'slideshow like teleporting', though. in case someone want colourful console options SC_HISTORY_SIZE=1000 options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) Please don't top post! I don't think you need VESA for any of these...certainly not the SC_HISTORY_SIZE. You do need it for SC_PIXEL_MODE to get more modes on systems that lack that capability (like my T43 laptop). If you can set it to a mode that makes you happy, those commands should work, but some systems offer very few modes without VESA. The T43 offers four...all 80 characters wide from 25 to 60 lines. :-( -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpPMLSLFdx1M.pgp Description: PGP signature
HEADS UP: ncurses is updated
Hi all, I just merged ncurses 5.6 and wide character support from HEAD to 6.x. That means ncurses in 6.x is now up-to-date and has wide character support, i.e., ncursesw library. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, April 06, 2007 06:17:04 +0100 Chris [EMAIL PROTECTED] wrote: I am seeing the no buffer space error on a machine running 6.2 STABLE feb 24 code, the machine isn't using gmirror. I had to recude recvspace and sendspace to lower values then I want to get round the problem. 67/1163/1230 mbufs in use (current/cache/total) 65/275/340/65536 mbuf clusters in use (current/cache/total/max) 65/255 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 146K/840K/987K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/56/8704 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 20233 requests for I/O initiated by sendfile 7740 calls to protocol drain routines What ethernet driver are you using? In my case, its an fxp device ... trying to see if there is *some* sort of common denominator here :( I just upgraded to the latest kernel last night, to see if maybe a recent commit had a side-effect of fixing it, but won't know anything for another 48 hours or so ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGFpJ44QvfyHIvDvMRAny4AKCOVStyCBOi5Pwt5uyelgze3ML/kQCgxqCp 6VZ/f9U4ibx/zahMLWu+Fs0= =U8Y1 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Repeatable crash with mkdir causing a divide by zero error
On Fri, Apr 06, 2007 at 11:05:22AM +0100, Tom Judge wrote:
Hi,
I have seen some problems with a new file system that I created
yesterday in that I could repeatedly get the system to crash in with a
mkdir.
Here is the disk information
mfid1: MFI Logical Disk on mfi1
mfid1: 5716992MB (11708399616 sectors) RAID volume 'Images' is optimal
I created a new file system tuned for 64k blocks, an average file size
of 1Mb, and 2500 files per directory.
newfs -b 65535 -g 1048576 -h 2500 /dev/mfid1p1
mount /dev/mfid1p1 /compere
mkdir /compere/images
mkdir /compere/images/1999
(Also tested with mkdir test; mkdir test/1998)
The system is and amd64 system running 6.2-RELEASE and the pmap.c patch.
I have 3 cores cause by 3 different apps (rsync, gmkdir, mkdir) and
can provide any more information if required. I have attached a back
trace, unfortunatly I cannot do any testing as the system is now in
testing (newfs -b 65535 -g 1048576 /dev/mfid1p1 was used and seems not
to cause the bug).
This might be simple to fix, but please file a PR if it does not get
picked up by someone on this list.
Kris
kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug /var/crash/vmcore.2
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x8:0x80391347
stack pointer = 0x10:0xa78736f0
frame pointer = 0x10:0xff0001d7a600
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 = 1206 (mkdir)
trap number = 18
panic: integer divide fault
cpuid = 0
Uptime: 4m29s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 1023MB (261800 pages) 1007 991 975 959 943 927 911 895 879
863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591
575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x8029a557 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x8029abf1 in panic (fmt=0xff0029753000 X?/) at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x803f62ff in trap_fatal (frame=0xff0029753000,
eva=18446742974994109272) at /usr/src/sys/amd64/amd64/trap.c:660
#5 0x803f67a2 in trap (frame=
{tf_rdi = 0, tf_rsi = 0, tf_rdx = 0, tf_rcx = 1951858688, tf_r8 =
2500, tf_r9 = 2975, tf_rax = 1951858688, tf_rbx = -2050457600, tf_rbp =
-1099480717824, tf_r10 = 246016, tf_r11 = 184512, tf_r12 =
-1098707543808, tf_r13 = 246015, tf_r14 = -2050457600, tf_r15 = 255,
tf_trapno = 18, tf_addr = 0, tf_flags = 2147483648012, tf_err = 0,
tf_rip = -2143743161, tf_cs = 8, tf_rflags = 66182, tf_rsp =
-1484310784, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469
#6 0x803e1a6b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0,
mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56
#8 0x803b8a5e in ufs_mkdir (ap=0xa78739a0) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1386
#9 0x8043b355 in VOP_MKDIR_APV (vop=0x7457,
a=0xa78739a0) at vnode_if.c:1251
#10 0x80310e19 in kern_mkdir (td=0xff002f24d7c0,
path=0xff003dabe400 , segflg=4, mode=511) at vnode_if.h:653
#11 0x803f7151 in syscall (frame=
{tf_rdi = 140737488348678, tf_rsi = 511, tf_rdx = 4294967295,
tf_rcx = 1, tf_r8 = 0, tf_r9 = 140737488347272, tf_rax = 136, tf_rbx =
2, tf_rbp = 140737488348024, tf_r10 = 4294967295, tf_r11 = 582, tf_r12 =
140737488348678, tf_r13 = 140737488348008, tf_r14 = 0, tf_r15 = 0,
tf_trapno = 12, tf_addr = 34367037072, tf_flags = 0, tf_err = 2, tf_rip
= 34367037084, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488347720,
tf_ss = 35})
at /usr/src/sys/amd64/amd64/trap.c:792
#12 0x803e1c08 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:270
#13 0x0008006f5e9c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0x80391347 in ffs_valloc
Re: Changing Console Resolution - Vidcontrol
On Thu, Apr 05, 2007 at 04:27:46PM +0200, Oliver Fromme wrote: I think 800x600x4 would be even quicker, because no VESA calls are required at all for screen output. Oops, I was mistaken. 800x600x4 (MODE_258) is what I'm using. 800x600x8 returns Operation not supported when trying to switch to it, as do both 4 and 8 bit 1024x768 modes. 16-bit and 32-bit modes work at the higher resolution but they're slow as molasses so I don't use them(1). I'd rather use 4-bit anyway as IMO there's very few reasons to have more than 16 colors in console mode. elinks is the only program I know of that claims to be able to use more and syscons may not even support the control codes it's using. (All x4 modes use a planar layout. If such a bitplane is larger than 64K, so-called bank switching is required to access all of the video memory, because the VGA address space allows only a 64K window for access at once. VESA calls are required to perform the bank switching. As yes, I'm having flashbacks to the good ol' days right now :) I mostly stuck to tweaking the VGA registers at the lower resolution modes as VESA support was pretty spotty on most hardware at the time. I do remember using bank switching on occasion though. I think FreeBSD's syscons supports it via flags 0x80 for the sc device in the kernel config file. See the section Driver Flags in the sc(4) manual page. Thanks for the tip, but this doesn't work for me. Setting that flag in device.hints results in a blank screen and only a single virtual terminal (ALT+F? just beep). I _am_ able to log in blind and issue commands however. Checking dmesg over ssh didn't show any errors or clues. In any case, allscreens_flags works acceptably for my needs. Strange that it works but the 0x80 flag doesn't. (1) Interesting data point, syscons apparently doesn't use VESA very efficiently. 1024x768x16 mode is very slow -- I can see the screen redrawing line by line in something like top. However, I'm currently using the VESA driver for X at the moment as the trident driver has some problems with the chip in this laptop. 1024x768x16 mode using VESA is fast in X, almost as fast as the accelerated driver. So I know the hardware is capable of it. Unfortunately X has some other issues on this machine, like a weird kkeybooardd ssstutteringg problem when Xkb is enabled, so I tend to use the console a lot. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stack panic with em driver unload
On Thu, 5 Apr 2007, Jack Vogel wrote: Our test group uses a script that does 100 iterations of a module load, then bring up all interfaces, and then unload driver. Depending on the system in anything from just a few iterations to 20 or more, the system will panic. Just a me too here. :p Its doing an em_detach() which calls ether_ifdetach() which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, and finally if_delmulti(). The panic is always happening on a cmpxchgq instruction so I assume its the LOCK macro, whats odd is that its not always the same reason, sometimes one register is 0 so its a page fault trap, but on other iterations its a general protection fault because the register is some big invalid number :) I run into this panic regularly. Apparently the result and condition to trigger the panic are the same as yours: running while true; do ifconfig xxx up; kldunload if_xxx; done and ending up with panicking at the cmpxchgq instruction. I am hardpressed to see this as a driver problem, but I'm willing to be proven wrong, does someone who knows the stack code better than me have any insights or ideas? It also appears system dependent, I have a couple machines I've tried to reproduce in on and have been unable. I also am told it happens on both amd64 and i386, but it seems easier to reproduce on the former. Dunno about amd64 since I only have i386 around; however, I'm sure the panic I observed is reproducible on my -CURRENT driver development box. Lastly, from evidence so far I think this doesnt happen on CURRENT, but the test group hasnt checked that only I have and I dont have as much hardware :) FWIW, I usually run into this panic after upgrading to a newer HEAD. Sometimes I can make the aforementioned ifconfig/kldunload script to survive longer by doing a clean rebuild on my driver. -- Cheers, Tai-hwa Liang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
