Re: Inconsistent utx.active?
On Friday, February 24, 2012 at 10:40 PM, Ed Schouten wrote: Hi Vlad, * Vlad Galu d...@dudu.ro (mailto:d...@dudu.ro), 20120224 23:35: Yes, sorry about that. I'm seeing stale (which sometimes turn into duplicate) entries when I log off and on again. The symptom seems to be exacerbated by unclean logouts (such as when my stateful corporate firewall kills my SSH sessions - I don't have keepalives active at either end). In the example below, I'm actually logged on from IP address X.Y.Z.T, the first two entries belong to earlier sessions that have been long gone. The pts is the same, and the command displayed under WHAT is mirrored for all 3 entries. Would you mind pasting the output of `getent utmpx active'? Not at all, here it is: -- cut here -- [1330014380.652067 -- Thu Feb 23 17:26:20 2012] user process: id=4f86d023f250d3c9 pid=39012 user=dudu line=pts/0 host=A.B.C.D [1330014398.177818 -- Thu Feb 23 17:26:38 2012] user process: id=269d75b37f295346 pid=39221 user=dudu line=pts/1 host=A.B.C.D [1330085459.796787 -- Fri Feb 24 13:10:59 2012] user process: id=d026e8e5c0648ec2 pid=38093 user=dudu line=pts/0 host=A.B.C.D [1330122640.813570 -- Fri Feb 24 23:30:40 2012] user process: id=dd8d3dff2f3002a0 pid=82959 user=dudu line=pts/0 host=X.Y.Z.T [1330122493.638088 -- Fri Feb 24 23:28:13 2012] user process: id=92b73279a543d99f pid=73085 user=dudu line=pts/1 host=X.Y.Z.T [1330122498.444614 -- Fri Feb 24 23:28:18 2012] user process: id=c0f3c404a3ca8565 pid=73573 user=dudu line=pts/2 host=X.Y.Z.T [1330122634.538515 -- Fri Feb 24 23:30:34 2012] dead process: id=fea56df5dde26e4d pid=76338 -- and here -- The local time is UTC+1. The current (and only) bash PID (82986) is not even on that list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent utx.active?
On Friday, February 24, 2012 at 10:15 PM, Ed Schouten wrote: Hi Vlad, Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9? Would you mind explaining to me what you're seeing? It's hard for me to fix bugs if I don't get proper reports. -- Ed Schouten e...@80386.nl (mailto:e...@80386.nl) WWW: http://80386.nl/ Hi Ed, Yes, sorry about that. I'm seeing stale (which sometimes turn into duplicate) entries when I log off and on again. The symptom seems to be exacerbated by unclean logouts (such as when my stateful corporate firewall kills my SSH sessions - I don't have keepalives active at either end). In the example below, I'm actually logged on from IP address X.Y.Z.T, the first two entries belong to earlier sessions that have been long gone. The pts is the same, and the command displayed under WHAT is mirrored for all 3 entries. -- cut here -- dudu@joint ~ $ w 11:30PM up 2 days, 6:17, 3 users, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT dudu pts/0 A.B.C.D Thu05PM - w dudu pts/0 A.B.C.D 1:10PM - w dudu pts/0 X.Y.Z.T 11:30PM - w dudu@joint ~ $ ps ax PID TT STAT TIME COMMAND 82986 0 SJ 0:00.00 -bash (bash) 83323 0 R+J 0:00.00 ps ax dudu@joint ~ $ -- and here -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent utx.active?
On Friday, February 24, 2012 at 11:00 PM, Ed Schouten wrote: Hello Vlad, * Vlad Galu d...@dudu.ro (mailto:d...@dudu.ro), 20120224 23:54: [1330014380.652067 -- Thu Feb 23 17:26:20 2012] user process: id=4f86d023f250d3c9 pid=39012 user=dudu line=pts/0 host=A.B.C.D [1330014398.177818 -- Thu Feb 23 17:26:38 2012] user process: id=269d75b37f295346 pid=39221 user=dudu line=pts/1 host=A.B.C.D [1330085459.796787 -- Fri Feb 24 13:10:59 2012] user process: id=d026e8e5c0648ec2 pid=38093 user=dudu line=pts/0 host=A.B.C.D [1330122640.813570 -- Fri Feb 24 23:30:40 2012] user process: id=dd8d3dff2f3002a0 pid=82959 user=dudu line=pts/0 host=X.Y.Z.T [1330122493.638088 -- Fri Feb 24 23:28:13 2012] user process: id=92b73279a543d99f pid=73085 user=dudu line=pts/1 host=X.Y.Z.T [1330122498.444614 -- Fri Feb 24 23:28:18 2012] user process: id=c0f3c404a3ca8565 pid=73573 user=dudu line=pts/2 host=X.Y.Z.T [1330122634.538515 -- Fri Feb 24 23:30:34 2012] dead process: id=fea56df5dde26e4d pid=76338 You mentioned in a previous email that these entries belong to SSH sessions. Are you sure about this? The identifiers seem to contain randomly generated data, just like pam_lastlog(8) does. OpenSSH uses identifiers based on the TTY name, like so: [1330124273.955165 -- Fri Feb 24 23:57:53 2012] user process: id=7074732f3000 pid=15880 user=ed line=pts/0 host=m.fxq.nl (http://m.fxq.nl) 0x7074732f30 is equal to pts/0. Maybe they're generated by some different login service or you've configured PAM/OpenSSH/etc. in a non-default way? Sigh, you are right. I had UseLogin set to yes in sshd_config. Sorry for the noise and thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Inconsistent utx.active?
Hi, Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9? Thanks, Vlad -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: serious packet routing issue causing ntpd high load?
Hi Qing, Any luck with this? Thanks Vlad On Thu, Nov 3, 2011 at 2:05 PM, Li, Qing qing...@bluecoat.com wrote: This endless route lookup miss message problem is reproducible without FLOWTABLE. The problem is with the multiple FIBs. I cannot reproduce this problem in my home network but the problem is easily seen at work. The route lookup miss itself in multi-FIBs configuration may be normal depending on the actual system configuration. It's the flooding of RTM_MISS messages that is abnormal. For example, if the route to the DNS servers is not configured in all FIBs, then the RTM_MISS message will be generated when an userland application sends to an explicit IP address in a specific FIB. In any case, I can reproduce the issue consistently and just trying to get a few uninterrupted hours to get it done. --Qing From: Alexander V. Chernikov [melif...@freebsd.org] Sent: Thursday, November 03, 2011 6:43 AM To: Steven Hartland Cc: Li, Qing; freebsd-stable@FreeBSD.org; li...@multiplay.co.uk Subject: Re: serious packet routing issue causing ntpd high load? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.10.2011 13:50, Steven Hartland wrote: - Original Message - From: Li, Qing qing...@bluecoat.com RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST ::A.B.C.D I'm unable to reproduce an issue on (nearly) GENERIC 8-S, but I see nearly the same situation on 8.1-S box with FLOWTABLE enabled. Do you have FLOWTABLE option in your kernel config ? Would it be possible for you to email me what exactly does ::A.B.C.D map into WRT your system or infrastructure ? Sorry for the slow reply been out of the country. All the hosts are local machines same /24 connecting to the server for mysql. It seems to be that every packet either to or from for the mysql server is generating an RTM_MISS. And are you able to share your ifconfig -a and netstat -rn output with me privately ? On its way. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org - -- WBR, Alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ymoMACgkQwcJ4iSZ1q2meiACeKq4lhzw6scqCKzEyTNEeycxo 31QAn2q5KIRBwJpcF7yOpTe3wOcP3Aak =jfKN -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: serious packet routing issue causing ntpd high load?
On Thu, Oct 6, 2011 at 1:32 AM, Li, Qing qing...@bluecoat.com wrote: [...] I'm seeing this as well. It's very easy to reproduce: 1. Start listening for routing messages on a non-default FIB, e.g. setfib 2 route monitor 2. Add any static route within that FIB. 3. The machine I run the test on is a heavy DNS client, it generates a few dozen requests per second. The monitor process starts getting RTM_MISS messages for each outgoing DNS request (the dst sockaddr is the same as my first resolv.conf entry, seq is always 0). -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.0-BETA3 Available...
On Tue, Oct 4, 2011 at 10:38 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Oct 4, 2011 at 5:30 PM, Joshua Boyd boy...@jbip.net wrote: On Tue, Oct 4, 2011 at 4:56 PM, Arnaud Lacombe lacom...@gmail.com wrote: Had you loved so much to have this information, you would have given me credential. I may have filled in all the date from publicly available material, might it be from mailing list, or from FTP server's timestamp, or SVN revision date. If I had not been able to determine a date, I may just have left it blank and asked for details, eventually. Unfortunately, we will never know. It's nice that you want to help, but could you be less of a jerk about it to the people who devote a huge amount of time to the project? Which ones: - those who do not upgrade release information in release cycle ? - those who commit broken stuff ? - those who knowingly misdocument interfaces ? - those who ignore obvious fixes ? - those who ignore users request ? - those who ignore users bugs ? - those who refuses to share their work-in-progress ? - those who tell you you're wrong for months to finally acknowledge you are right, and commit your fixes ? Arnaud, everybody is doing their best. If members or groups within the FreeBSD project are under contractual obligation to meet your expectations, please feel free to take this off-list. Otherwise, if you feel there are similar projects with better management, perhaps they're better suited for you. -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: doscmd under 8-stable, anyone?
Hi Joerg,
Flip security.bsd**.map_at_zero to 1.
On Wed, Jun 15, 2011 at 3:57 PM, Joerg Wunsch
freebsd-sta...@uriah.heep.sax.de wrote:
When trying to use doscmd on 8-stable, all I get is:
Error mapping HMA, HMA disabled: : Invalid argument
Segmentation fault (core dumped)
The segfault happens at the end of mem_init(), when the allocated DOS
memory (which is located at virtual address 0) is attempted to be
written to. Apparently, the mmap() failure that causes the HMA
disabled message is actually a fatal error rather than a benign one
the could be ignored, as it results in no valid DOS memory allocation
at all.
Right now, the only older system I could test it against uses FreeBSD
5.x, where the mmap() works as expected. So does anyone have an idea
why this mmap() call:
if (mmap((caddr_t)0x00, 0x10,
PROT_EXEC | PROT_READ | PROT_WRITE,
MAP_ANON | MAP_FIXED | MAP_SHARED,
-1, 0) == MAP_FAILED) {
perror(Error mapping HMA, HMA disabled: );
HMA_a20 = -1;
close(HMA_fd_off);
close(HMA_fd_on);
return;
}
yields an EINVAL now under 8-stable?
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Good, fast cheap. Pick any two.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 pf stack issue (state count spiraling out of control)
On Tue, May 3, 2011 at 8:01 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: On Tue, May 03, 2011 at 07:22:10AM +0200, Vlad Galu wrote: On Tue, May 3, 2011 at 3:58 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: (Please keep me CC'd as I'm not subscribed to freebsd-pf. And apologies for cross-posting, but the issue is severe enough that I wanted to make it known on -stable) The below issue I'm describing is from a machine running 8.2-PRERELEASE (RELENG_8) using src dated Tue Feb 15 05:46:02 PST 2011. Please read the story in full, as I have taken the time to describe everything I did, plus log output, as well as induce a panic via call doadump from ddb so I have a capture of the system at the time. I also have a theory as to what caused the problem, but how to trigger it is unknown; it may be a rare race condition. This morning I woke up to find a report from one of our users that he could not connect to a specific TCP port (not SSH) on one of our servers. I also found that I couldn't SSH into the same box. Serial console was working fine, and the serial console log showed no sign of any problems. I started to debug the issue of me not being able to SSH into the machine and within a few minutes became immediately concerned: pfctl indicated we had reached the maximum number permitted state table entries (10,000). # pfctl -s info Status: Enabled for 76 days 06:49:10 Debug: Urgent Interface Stats for em0 IPv4 IPv6 Bytes In 89697488400 Bytes Out 82961354770 Packets In Passed 1282117630 Blocked 6213790 Packets Out Passed 1384838680 Blocked 25790 State Table Total Rate current entries1 searches 267316807 40.6/s inserts 44405530.7/s removals 44305530.7/s Counters match50674740.8/s bad-offset 00.0/s fragment 3240.0/s short 00.0/s normalize 320.0/s memory3369460.1/s bad-timestamp 00.0/s congestion 00.0/s ip-option 00.0/s proto-cksum 16110.0/s state-mismatch 5090.0/s state-insert 00.0/s state-limit00.0/s src-limit 00.0/s synproxy 00.0/s # pfctl -s memory stateshard limit1 src-nodes hard limit1 frags hard limit 5000 tableshard limit 1000 table-entries hard limit 10 The above is mainly for em0 (our WAN interface); our LAN interface (em1) was not impacted because we use set skip on em1. And it's a good thing too: we have lots of LAN-based services that this machine provides that would have been impacted. We also use set skip on lo0. I immediately went to look at our monitoring graphs, which monitor pf state (specifically state table entries), polled via bsnmpd(8). This data is even more frightening: http://jdc.parodius.com/freebsd/pf-issue/pf_states-day.png http://jdc.parodius.com/freebsd/pf-issue/pf_states-week.png Literally something was spiraling out of control, starting at approx. 2011/05/01 (Sun) at 12:30 PDT. The situation became dire at approx. 19:45 PDT the same day, but I wasn't aware of it until said user brought an issue to my attention. You can see from the network I/O graphs (taken from SNMP polling our switch, NOT from the host/box itself) that there was no DoS attack or anything like that occurring -- this was something within FreeBSD itself. More evidence of that will become apparent. http://jdc.parodius.com/freebsd/pf-issue/port_03-day.png http://jdc.parodius.com/freebsd/pf-issue/port_03-week.png The first thing I did was /etc/rc.d/pf reload. This command hung. Any attempt to send Ctrl-C/SIGINT did nothing. I was able to Ctrl-Z/SIGSTOP it, then use kill %1
Re: RELENG_8 pf stack issue (state count spiraling out of control)
On Tue, May 3, 2011 at 11:31 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 03/05/2011 10:16, Jeremy Chadwick wrote: snip lots of data relevant to the discussion but not my answer Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt usage, etc. otherwise I'd be graphing that. The more monitoring the better; at least then I could say wow, interrupts really did shoot through the roof -- the box went crazy! and RMA the thing. :-) you could use net-mgmt/bsnmp-regex although I dont know what the overhead for that is like. I use munin for graphing, as it allows easy scripting without using SNMP. My case is a bit different from Jeremy's. Every once in a while there is a sudden traffic spike which impacts pf performance as well. However, the graphed figures are nowhere near what I'd consider alarming levels (this box has withstood more in the past). I was able to coincidentally log in after such a spike and noticed the pfpurge thread eating up about 30% of the CPU while using the normal optimization policy. In my case, it could be related to another issue I'm seeing on this box - mbuma allocation failures. Here are my graphs: http://dl.dropbox.com/u/14650083/PF/bge_bits_1-week.png http://dl.dropbox.com/u/14650083/PF/bge_packets_1-week.png http://dl.dropbox.com/u/14650083/PF/bge_stats_1-week.png http://dl.dropbox.com/u/14650083/PF/load-week.png http://dl.dropbox.com/u/14650083/PF/mbuf_errors-week.png http://dl.dropbox.com/u/14650083/PF/mbuf_usage-week.png http://dl.dropbox.com/u/14650083/PF/pf_inserts-week.png http://dl.dropbox.com/u/14650083/PF/pf_matches-week.png http://dl.dropbox.com/u/14650083/PF/pf_removals-week.png http://dl.dropbox.com/u/14650083/PF/pf_searches-week.png http://dl.dropbox.com/u/14650083/PF/pf_src_limit-week.png http://dl.dropbox.com/u/14650083/PF/pf_states-week.png http://dl.dropbox.com/u/14650083/PF/pf_synproxy-week.png I'll wait for the next time the symptom occurs to switch to a stateless configuration. -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 pf stack issue (state count spiraling out of control)
On Tue, May 3, 2011 at 12:12 PM, Vlad Galu d...@dudu.ro wrote: On Tue, May 3, 2011 at 11:31 AM, Vincent Hoffman vi...@unsane.co.ukwrote: On 03/05/2011 10:16, Jeremy Chadwick wrote: snip lots of data relevant to the discussion but not my answer Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt usage, etc. otherwise I'd be graphing that. The more monitoring the better; at least then I could say wow, interrupts really did shoot through the roof -- the box went crazy! and RMA the thing. :-) you could use net-mgmt/bsnmp-regex although I dont know what the overhead for that is like. I use munin for graphing, as it allows easy scripting without using SNMP. My case is a bit different from Jeremy's. Every once in a while there is a sudden traffic spike which impacts pf performance as well. However, the graphed figures are nowhere near what I'd consider alarming levels (this box has withstood more in the past). I was able to coincidentally log in after such a spike and noticed the pfpurge thread eating up about 30% of the CPU while using the normal optimization policy. In my case, it could be related to another issue I'm seeing on this box - mbuma allocation failures. Here are my graphs: http://dl.dropbox.com/u/14650083/PF/bge_bits_1-week.png http://dl.dropbox.com/u/14650083/PF/bge_packets_1-week.png http://dl.dropbox.com/u/14650083/PF/bge_stats_1-week.png http://dl.dropbox.com/u/14650083/PF/load-week.png http://dl.dropbox.com/u/14650083/PF/mbuf_errors-week.png http://dl.dropbox.com/u/14650083/PF/mbuf_usage-week.png http://dl.dropbox.com/u/14650083/PF/pf_inserts-week.png http://dl.dropbox.com/u/14650083/PF/pf_matches-week.png http://dl.dropbox.com/u/14650083/PF/pf_removals-week.png http://dl.dropbox.com/u/14650083/PF/pf_searches-week.png http://dl.dropbox.com/u/14650083/PF/pf_src_limit-week.png http://dl.dropbox.com/u/14650083/PF/pf_states-week.png http://dl.dropbox.com/u/14650083/PF/pf_synproxy-week.png I'll wait for the next time the symptom occurs to switch to a stateless configuration. I forgot to mention this is a UP box using TSC for timekeeping and running ntpd. -- /boot/loader.conf -- hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 debug.acpi.disabled=timer -- /boot/loader.conf -- -- sysctl output -- kern.timecounter.choice: TSC(800) i8254(0) dummy(-100) kern.timecounter.hardware: TSC -- sysctl output -- -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 pf stack issue (state count spiraling out of control)
On Tue, May 3, 2011 at 3:58 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: (Please keep me CC'd as I'm not subscribed to freebsd-pf. And apologies for cross-posting, but the issue is severe enough that I wanted to make it known on -stable) The below issue I'm describing is from a machine running 8.2-PRERELEASE (RELENG_8) using src dated Tue Feb 15 05:46:02 PST 2011. Please read the story in full, as I have taken the time to describe everything I did, plus log output, as well as induce a panic via call doadump from ddb so I have a capture of the system at the time. I also have a theory as to what caused the problem, but how to trigger it is unknown; it may be a rare race condition. This morning I woke up to find a report from one of our users that he could not connect to a specific TCP port (not SSH) on one of our servers. I also found that I couldn't SSH into the same box. Serial console was working fine, and the serial console log showed no sign of any problems. I started to debug the issue of me not being able to SSH into the machine and within a few minutes became immediately concerned: pfctl indicated we had reached the maximum number permitted state table entries (10,000). # pfctl -s info Status: Enabled for 76 days 06:49:10 Debug: Urgent Interface Stats for em0 IPv4 IPv6 Bytes In 89697488400 Bytes Out 82961354770 Packets In Passed 1282117630 Blocked 6213790 Packets Out Passed 1384838680 Blocked 25790 State Table Total Rate current entries1 searches 267316807 40.6/s inserts 44405530.7/s removals 44305530.7/s Counters match50674740.8/s bad-offset 00.0/s fragment 3240.0/s short 00.0/s normalize 320.0/s memory3369460.1/s bad-timestamp 00.0/s congestion 00.0/s ip-option 00.0/s proto-cksum 16110.0/s state-mismatch 5090.0/s state-insert 00.0/s state-limit00.0/s src-limit 00.0/s synproxy 00.0/s # pfctl -s memory stateshard limit1 src-nodes hard limit1 frags hard limit 5000 tableshard limit 1000 table-entries hard limit 10 The above is mainly for em0 (our WAN interface); our LAN interface (em1) was not impacted because we use set skip on em1. And it's a good thing too: we have lots of LAN-based services that this machine provides that would have been impacted. We also use set skip on lo0. I immediately went to look at our monitoring graphs, which monitor pf state (specifically state table entries), polled via bsnmpd(8). This data is even more frightening: http://jdc.parodius.com/freebsd/pf-issue/pf_states-day.png http://jdc.parodius.com/freebsd/pf-issue/pf_states-week.png Literally something was spiraling out of control, starting at approx. 2011/05/01 (Sun) at 12:30 PDT. The situation became dire at approx. 19:45 PDT the same day, but I wasn't aware of it until said user brought an issue to my attention. You can see from the network I/O graphs (taken from SNMP polling our switch, NOT from the host/box itself) that there was no DoS attack or anything like that occurring -- this was something within FreeBSD itself. More evidence of that will become apparent. http://jdc.parodius.com/freebsd/pf-issue/port_03-day.png http://jdc.parodius.com/freebsd/pf-issue/port_03-week.png The first thing I did was /etc/rc.d/pf reload. This command hung. Any attempt to send Ctrl-C/SIGINT did nothing. I was able to Ctrl-Z/SIGSTOP it, then use kill %1, but the actual reload process did not truly die (despite csh stating Terminated). The only way to kill it was to kill -9. Attempts to shut down any daemons which utilised the network -- including things that only used em1 -- would not shut down. This included things like postfix, mysqld, and some inet-based services. I was forced to kill -9
Re: ipfw: Too many dynamic rules
2010/9/9 Marat N.Afanasyev ama...@ksu.ru: I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_rtdel: error 47 (netgraph or mpd issue?)
On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa m...@sentex.net wrote: [...] FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No Netgraph on that box. Unfortunately, the stack was too corrupted to be able to see the outer frames. -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sudden mbuf demand increase and shortage under the load
On Tue, Feb 16, 2010 at 7:23 PM, Maxim Sobolev sobo...@freebsd.org wrote: Miroslav Lachman wrote: Can it be related to this issue somehow? http://lists.freebsd.org/pipermail/freebsd-current/2009-August/011013.html http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010740.html It was tested on FreeBSD 8 and high UDP traffic on igb interfaces emits messages GET BUF: dmamap load failure - 12 and later results in kernel panic. We have not received any response to this report. Could be the issue, however in our case there is no panic, just that all userland activity in the system ceases for 2 minutes after it reaches certain network load level. Sorry for digging into this old thread, but I'm seeing similar symptoms with today's RELENG_8 and bge(4) attached to BCM5721, on an UP system. kern.ipc.nmbclusters is 65536, but what strikes me odd is this: 0/115446003/57722999 requests for mbufs denied (mbufs/clusters/mbuf+clusters) vmstat -i shows a rate of 1100 for the adapter. The machine runs a fairly small PF configuration, but I've already ruled it out, the symptoms appear when PF is disabled as well. I'll happily provide more info. Regards, Vlad -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel panic: vm_page_unwire
On Mon, May 31, 2010 at 5:20 PM, Konstantin Doulepov kdu...@gmail.com wrote: [...] Hello Konstantin, Remove ZERO_COPY_SOCKETS and retry. It's been known to cause VM panics for quite a while. Regards, Vlad -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic: vm_fault_copy_wired: page missing
On Thu, Apr 15, 2010 at 9:22 AM, Daniel Braniss da...@cs.huji.ac.il wrote: Hi, I'm getting this with FreeBSD-8-stable, it usually happens when starting apache: alc@ made some VM MFCs yesterday, could you try a 13th of April kernel and see if it works out for you? -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Crash in pf(4) with a fairly recent RELENG_8
Luckily I could find this coredump: -- cut here -- #0 doadump () at pcpu.h:223 #1 0x802f4ace in boot (howto=260) at ../../../kern/kern_shutdown.c:416 #2 0x802f4eab in panic (fmt=Variable fmt is not available. ) at ../../../kern/kern_shutdown.c:579 #3 0x805064d2 in trap_fatal (frame=0xff8345c0, eva=0) at ../../../amd64/amd64/trap.c:857 #4 0x80506e8c in trap (frame=0xff8345c0) at ../../../amd64/amd64/trap.c:644 #5 0x804eec93 in calltrap () at ../../../amd64/amd64/exception.S:224 #6 0x801a1140 in pf_state_tree_id_RB_MINMAX () at ../../../contrib/pf/net/pf.c:401 #7 0x801a1210 in pf_src_tree_RB_FIND (head=Variable head is not available. ) at ../../../contrib/pf/net/pf.c:396 #8 0x801a3594 in pf_insert_src_node (sn=0xff834868, rule=0xff0001694000, src=0xff000d75701c, af=2 '\002') at ../../../contrib/pf/net/pf.c:850 #9 0x801acd6e in pf_test_tcp (rm=0xff834978, sm=0xff834970, direction=1, kif=0xff000132ab00, m=0xff001e052b00, off=20, h=0xff000d757010, pd=0xff834990, am=0xff834980, rsm=0xff834968, ifq=0x0, inp=0x0) at ../../../contrib/pf/net/pf.c:3500 #10 0x801ae7a6 in pf_test (dir=1, ifp=0xff0001201000, m0=0xff834ac8, eh=Variable eh is not available. ) at ../../../contrib/pf/net/pf.c:7066 #11 0x801b33a9 in pf_check_in (arg=Variable arg is not available. ) at ../../../contrib/pf/net/pf_ioctl.c:3646 -- and here -- -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Crash in pf(4) with a fairly recent RELENG_8
On Thu, Mar 18, 2010 at 12:38 AM, Vlad Galu d...@dudu.ro wrote:
Luckily I could find this coredump:
-- cut here --
#0 doadump () at pcpu.h:223
#1 0x802f4ace in boot (howto=260) at
../../../kern/kern_shutdown.c:416
#2 0x802f4eab in panic (fmt=Variable fmt is not available.
) at ../../../kern/kern_shutdown.c:579
#3 0x805064d2 in trap_fatal (frame=0xff8345c0, eva=0)
at ../../../amd64/amd64/trap.c:857
#4 0x80506e8c in trap (frame=0xff8345c0)
at ../../../amd64/amd64/trap.c:644
#5 0x804eec93 in calltrap () at ../../../amd64/amd64/exception.S:224
#6 0x801a1140 in pf_state_tree_id_RB_MINMAX ()
at ../../../contrib/pf/net/pf.c:401
#7 0x801a1210 in pf_src_tree_RB_FIND (head=Variable head is
not available.
)
at ../../../contrib/pf/net/pf.c:396
#8 0x801a3594 in pf_insert_src_node (sn=0xff834868,
rule=0xff0001694000, src=0xff000d75701c, af=2 '\002')
at ../../../contrib/pf/net/pf.c:850
#9 0x801acd6e in pf_test_tcp (rm=0xff834978,
sm=0xff834970, direction=1, kif=0xff000132ab00,
m=0xff001e052b00, off=20, h=0xff000d757010, pd=0xff834990,
am=0xff834980, rsm=0xff834968, ifq=0x0, inp=0x0)
at ../../../contrib/pf/net/pf.c:3500
#10 0x801ae7a6 in pf_test (dir=1, ifp=0xff0001201000,
m0=0xff834ac8, eh=Variable eh is not available.
) at ../../../contrib/pf/net/pf.c:7066
#11 0x801b33a9 in pf_check_in (arg=Variable arg is not available.
)
at ../../../contrib/pf/net/pf_ioctl.c:3646
-- and here --
The pf_src_node struct in frame #8 is this:
-- cut here--
(kgdb) p k
$1 = {entry = {rbe_left = 0x0, rbe_right = 0x0,
rbe_parent = 0x, rbe_color = 0}, addr = {pfa = {v4 = {
s_addr = 1684237067}, v6 = {__u6_addr = {
__u6_addr8 = \vkcd\200???\001\000\000\000\000\000\000,
__u6_addr16 = {27403, 25699, 65408, 65535, 1, 0, 0, 0},
__u6_addr32 = {1684237067, 4294967168, 1, 0}}},
addr8 = \vkcd\200???\001\000\000\000\000\000\000, addr16 = {27403,
25699, 65408, 65535, 1, 0, 0, 0}, addr32 = {1684237067, 4294967168, 1,
0}}}, raddr = {pfa = {v4 = {s_addr = 12}, v6 = {__u6_addr = {
__u6_addr8 = \f\000\000\000\000\000\000\000\000?2\001\000???,
__u6_addr16 = {12, 0, 0, 0, 43776, 306, 65280, 65535},
__u6_addr32 = {12, 0, 20097792, 4294967040}}},
addr8 = \f\000\000\000\000\000\000\000\000?2\001\000???, addr16 = {12,
0, 0, 0, 43776, 306, 65280, 65535}, addr32 = {12, 0, 20097792,
4294967040}}}, rule = {ptr = 0xff0001694000, nr = 23674880},
kif = 0x801a9858, bytes = {18446743523953737740,
18446742974423724064}, packets = {3354, 17179869187}, states = 23510160,
conn = 4294967040, conn_rate = {limit = 23403040, seconds = 4294967040,
count = 20097792, last = 4294967040}, creation = 2, expire = 0,
af = 2 '\002', ruletype = 0 '\0'}
-- and here--
The byte count looks weird...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt threads CPU usage in FreeBSD 8.0
2009/10/21 Igor Sysoev i...@rambler-co.ru: [...] /metoo, 8.0-RC2 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
pw groupadd/useradd fail when the nscd cache is used for name/group resolution
I've stumbled upon this while installing postgres. In /etc/nsswitch.conf I had group: cache files compat and passwd: cache files compat. Once I commented them out things started working again. Before the change, this is how it looked like: -- cut here -- [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g 70 pw: group disappeared during update [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g 70 pw: group 'pgsql' already exists [r...@vgalu /usr/ports/databases/postgresql84-server]# -- and here -- Shouldn't 'files' be used upon a cache miss? If this is a PEBKAC, sorry for the noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 3, 2009 at 9:42 PM, Bruce Evansb...@optusnet.com.au wrote: [...] Hello Bruce, Kostik, Oliver. Was any consensus reached on how to tackle this issue? The RELENG_7 code looks slightly different so I haven't (yet) tried adapting the provided patches. As for the interface behavior, I think the nicest way would be to signal EOF by POLLHUP alone, without POLLIN. Regards, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Mon, Jun 8, 2009 at 3:57 PM, Ivan Vorasivo...@freebsd.org wrote: On a completely unrelated subject I was reading about PHP APC cache where they have the same need - cross-process locking with locks embedded in data structures and they have adopted userland spinlock code from PostgreSQL: http://www.scribd.com/doc/3288293/brian-shireapc-facebook (spin)locks are not the same as sempahores but maybe it will help the OP or anyone else trying to implement this feature: http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4view=markup http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3view=markup Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
poll()-ing a pipe descriptor, watching for POLLHUP
Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad poll.cpp Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: poll()-ing a pipe descriptor, watching for POLLHUP
Hm, according to the code at http://www.greenend.org.uk/rjk/2001/06/poll.html, it seems to work as expected (returning both POLLIN and POLLHUP), when closing the write end of the pipe from within the same process. On Wed, Jun 3, 2009 at 3:15 PM, Vlad Galu d...@dudu.ro wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov kostik...@gmail.com wrote: On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. Aaarhg! You're right! Sorry for the noise! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 3, 2009 at 3:35 PM, Vlad Galu d...@dudu.ro wrote: On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov kostik...@gmail.com wrote: On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. Aaarhg! You're right! Sorry for the noise! Hm, I was having an issue with an internal piece of software, but never checked what kind of pipe caused the problem. Turns out it was a FIFO, and I got bitten by the same bug described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html The problem is that the reader process isn't notified when the writer process exits or closes the FIFO fd... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Tue, Jun 2, 2009 at 12:30 AM, Daniel Eischen deisc...@freebsd.org wrote: [...] Thank you all for your swift replies. It seems to indeed work for forked processes. The app at $work (written on and for Linux) transported an unnamed semaphore over a POSIX shared memory object. I'll probably make it a named semaphore and only send its name over the shared memory space. Regards, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Unnamed POSIX shared semaphores
Hello, According to sem_init(3), we can't have shared unnamed semaphores. However, the following code snippet seems to work just fine: -- cut here -- sem_t semaphore; if (sem_init(semaphore, 1, 10) 0) std::cout Couldn't init semaphore: strerror(errno) std::endl; if (sem_wait(semaphore) 0) std::cout Couldn't decrement semaphore: strerror(errno) std::endl; int val; sem_getvalue(semaphore, val); std::cout Value is val std::endl; -- and here -- Is this a case where sem_init() silently reports success, or should be the man page get an update? Thanks, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS on top of GELI / Intel Atom 330 system
On Fri, May 29, 2009 at 2:49 PM, Ivan Voras ivo...@freebsd.org wrote: Hi, What is the meaning of counts? Number of calls made or time? The former. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ld-elf.so.1 isn't overwritten upon making installworld
All in subject. I could see the particular line where install is called on the newly built copy, but even though the system copy's file flags are cleared (noschg), the overwriting fails. I managed to overwrite it by (cp -f)-ing) the fresh copy over the old one. Regards, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ld-elf.so.1 isn't overwritten upon making installworld
On Fri, May 15, 2009 at 9:49 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-15 18:42, Vlad GALU wrote: All in subject. I could see the particular line where install is called on the newly built copy, but even though the system copy's file flags are cleared (noschg), the overwriting fails. I managed to overwrite it by (cp -f)-ing) the fresh copy over the old one. Are you running in single-user mode during installworld? Yep. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ld-elf.so.1 isn't overwritten upon making installworld
On Fri, May 15, 2009 at 11:37 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-15 22:25, Vlad GALU wrote: called on the newly built copy, but even though the system copy's file flags are cleared (noschg), the overwriting fails. I managed to overwrite it by (cp -f)-ing) the fresh copy over the old one. Are you running in single-user mode during installworld? Alright, just checking. :) What is the exact error that you're getting? It might also be the binary isn't changed at all, and in that case it will *not* be updated (its Makefile uses INSTALLFLAGS=-C -b). There's no error, I just happened to notice that the mtime of my ld-elf.so.1 was from about 2 months ago (that's about when I made the last update). The size of the fresh one from /usr/obj/... is different. Not to mention that there were even some recent changes in rtld.c :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
bce(4) and rx errors
Hello. Sorry for crossposting, but I wasn't sure which mailing list was the most appropriate for this email. I have an application pulling about 220Kpps from a bce(4) card (details below). At what seems to be random times, errors start showing up on that interface (I'm watching it with netstat -w1 -I), so about 10% of the initial 220Kpps is reported as errors. Bringing the interface down and then back up clears the errors, but they do reappear at a later time. Before they reappear, the systems manages to pull the full 220Kpps as before. This is a temporary setup, we'll very soon use an Intel fiber card, but I thought this issue was worth mentioning, as I don't think it's a hardware problem (the switch also reports no errors). The system is running a fresh (yesterday's) RELENG_7. The card is onboard, on a HP DL380 G5. Here's the pciconf output: -- cut here -- [EMAIL PROTECTED]:2:0:0: class=0x060400 card=0x chip=0x01031166 rev=0xc3 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5715 Broadcom dual gigabit, pci bridge' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:3:0:0:class=0x02 card=0x7038103c chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet -- and here -- Regards, Vlad -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bce(4) and rx errors
On 12/10/08, Mike Jakubik [EMAIL PROTECTED] wrote: On Wed, December 10, 2008 11:03 am, Jeff Blank wrote: On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: I have an application pulling about 220Kpps from a bce(4) card (details below). At what seems to be random times, errors start showing up on that interface (I'm watching it with netstat -w1 -I), so about 10% of the initial 220Kpps is reported as errors. I'm also seeing a pretty steady stream of errors on both bce interfaces in a Dell PowerEdge 2950 III. In my case, the source is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not seem to be affected. sysctl -a | egrep -i 'bce.*err' yields all zeroes, for whatever that's worth. See the RELENG_7_1: bce driver change generating too much interrupts ? thread. This problem as surfaced since the recent bce driver changes. Thanks Mike, I'll give it a shot. -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bce(4) and rx errors
On 12/10/08, Vlad GALU [EMAIL PROTECTED] wrote: On 12/10/08, Mike Jakubik [EMAIL PROTECTED] wrote: On Wed, December 10, 2008 11:03 am, Jeff Blank wrote: On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: I have an application pulling about 220Kpps from a bce(4) card (details below). At what seems to be random times, errors start showing up on that interface (I'm watching it with netstat -w1 -I), so about 10% of the initial 220Kpps is reported as errors. I'm also seeing a pretty steady stream of errors on both bce interfaces in a Dell PowerEdge 2950 III. In my case, the source is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not seem to be affected. sysctl -a | egrep -i 'bce.*err' yields all zeroes, for whatever that's worth. See the RELENG_7_1: bce driver change generating too much interrupts ? thread. This problem as surfaced since the recent bce driver changes. Thanks Mike, I'll give it a shot. Indeed, the errors seem to have gone away after rolling back the driver, as Xin Li suggested in another thread. Sorry for the noise! -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird truss output
On Thu, Dec 4, 2008 at 12:55 AM, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Dec 03), Vlad GALU said: On Wed, Dec 3, 2008 at 8:56 PM, Dan Nelson [EMAIL PROTECTED] wrote: [...] Am I doing something wrong? I've applied the full diff, rebuilt truss, now I get this: -- cut here -- [EMAIL PROTECTED] / # truss -p 52731 SIGNAL 17 (SIGSTOP) -- UNKNOWN SYSCALL 1048535 -- -- UNKNOWN SYSCALL 1048496 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 527 -- /100084: read(1074283119,\M-|\M^WP\^A,7356800) = 4 (0x4) -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 7385248 -- -- and here -- Perhaps I should mention that I block all signals from all threads, except for one, where I do all the handling/cleanup. So you're back to your original behaviour basically? Not sure what's wrong; it all works great on my machine... Are you on a 64-bit system? I only have a Pentium-III here, so the big patch isn't guaranteed to work on anything except i386. The little patch inlined in my previous email is for i386-fbsd.c, but you should be able to make similar changes to amd64-fbsd.c (most of the diff just replaces fsc. with fsc- ). Duh, I'm dumb, I didn't take a moment to check whether there was a 64-bit specific implementation. My initial thought was that the i386 in the i386-fbsd.c referred to the CPU arch :) I'll try patching the other file today and get back with the results. And next time I'll make sure I've had my daily coffee before posting to the list :) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird truss output
Hello, I'm running a statically linked binary, which I've built inside a jail. The jail's libc co are in sync with the host's. Truss then shows this: -- cut here -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048524 -- -- UNKNOWN SYSCALL 1048516 -- -- UNKNOWN SYSCALL 1048572 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048556 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048524 -- -- UNKNOWN SYSCALL 1048564 -- -- UNKNOWN SYSCALL 1048548 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048564 -- -- and here -- Is this a bug or a feature? -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird truss output
On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Dec 03), Vlad GALU said:
I'm running a statically linked binary, which I've built inside a
jail. The jail's libc co are in sync with the host's. Truss then
shows this:
-- cut here --
-- UNKNOWN SYSCALL 1048532 --
-- UNKNOWN SYSCALL 1048532 --
Is this a threaded app that you attached truss to after it was started?
The method that truss uses to catch syscall enter/exit events doesn't
indicate whether the event is an enter or an exit, so if you attach
while a syscall is active, truss handles the exit event as if it were a
syscall entry event, and never gets back in synch. It gets worse with
threaded apps because each thread is another chance to get out of
synch. Try this patch:
Index: i386-fbsd.c
===
RCS file: /home/ncvs/src/usr.bin/truss/i386-fbsd.c,v
retrieving revision 1.29
diff -u -p -r1.29 i386-fbsd.c
--- i386-fbsd.c 28 Jul 2007 23:15:04 - 1.29
+++ i386-fbsd.c 3 Dec 2008 15:20:09 -
@@ -149,7 +149,14 @@ i386_syscall_entry(struct trussinfo *tru
fsc.name =
(syscall_num 0 || syscall_num nsyscalls) ? NULL :
syscallnames[syscall_num];
if (!fsc.name) {
-fprintf(trussinfo-outfile, -- UNKNOWN SYSCALL %d --\n, syscall_num);
+fprintf(trussinfo-outfile, -- UNKNOWN SYSCALL %u (0x%08x) --\n,
syscall_num, syscall_num);
+if ((unsigned int)syscall_num 0x1000) {
+ /* When attaching to a running process, we have a 50-50 chance
+ of attaching to a process waiting in a syscall, which means
+ our first trap is an exit instead of an entry and we're out
+ of synch. Reset our flag */
+ trussinfo-curthread-in_syscall = 0;
+}
}
if (fsc.name (trussinfo-flags FOLLOWFORKS)
--
Dan Nelson
[EMAIL PROTECTED]
Hi Dan,
You were right, this application was indeed threaded. The messages
still occur, although at a slightly lower rate. One other thing that's
not particularly helpful is this:
-- cut here--
read(1074283119,\M-Ry\^A\0,7356800)= 4 (0x4)
-- and here --
I obviously don't have that many descriptors in my process. I can live
with the malformed message, but it's a PITA not to know which fd the
read was actually made from :(
--
~/.signature: no such file or directory
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird truss output
On Wed, Dec 3, 2008 at 7:08 PM, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Dec 03), Vlad GALU said: On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Dec 03), Vlad GALU said: I'm running a statically linked binary, which I've built inside a jail. The jail's libc co are in sync with the host's. Truss then shows this: -- cut here -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- Is this a threaded app that you attached truss to after it was started? The method that truss uses to catch syscall enter/exit events doesn't indicate whether the event is an enter or an exit, so if you attach while a syscall is active, truss handles the exit event as if it were a syscall entry event, and never gets back in synch. It gets worse with threaded apps because each thread is another chance to get out of synch. Try this patch: You were right, this application was indeed threaded. The messages still occur, although at a slightly lower rate. One other thing that's not particularly helpful is this: -- cut here-- read(1074283119,\M-Ry\^A\0,7356800)= 4 (0x4) -- and here -- I obviously don't have that many descriptors in my process. I can live with the malformed message, but it's a PITA not to know which fd the read was actually made from :( It looks like there's some other problem where truss either drops a syscall event, or puts some status fields into the wrong thread's structure. It seems to happen when two threads call blocking syscalls, and when they return, truss gets confused as to which thread called which syscall. The read syscall is probably still pending, and you're getting the arguments of the syscall that returned, printed as if it was the read syscall. When the read call completes, you'll probably get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output line. An alternative it to use ktrace/kdump to trace the process; it's more cumbersome to use, but doesn't have problems with threaded processes. Now why didn't I think of that? :/ Thanks for the suggestion! -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird truss output
On Wed, Dec 3, 2008 at 8:56 PM, Dan Nelson [EMAIL PROTECTED] wrote: [...] Am I doing something wrong? I've applied the full diff, rebuilt truss, now I get this: -- cut here -- [EMAIL PROTECTED] / # truss -p 52731 SIGNAL 17 (SIGSTOP) -- UNKNOWN SYSCALL 1048535 -- -- UNKNOWN SYSCALL 1048496 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 527 -- /100084: read(1074283119,\M-|\M^WP\^A,7356800) = 4 (0x4) -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 7385248 -- -- and here -- Perhaps I should mention that I block all signals from all threads, except for one, where I do all the handling/cleanup. -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDP LOR with the latest RELENG_7
On Sun, Oct 12, 2008 at 1:40 PM, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 10 Oct 2008, Robert Watson wrote: On Fri, 10 Oct 2008, Jeremy Chadwick wrote: I'll see whether the system still locks up or not though.. Okay, I'm bringing rwatson@ into the thread since this is specific to UDP. I've now fixed the bug leading to the lock order reversal; I'd be interested in knowing if it also corrects the stability issue. This was r183753 in svn; I'm not sure it's hit CVS/cvsup yet but should do in a few minutes. Dear Vlad: Could you confirm that with udp_usrreq.c:1.218.2.7 (or newer), the problem has gone away? CVS log excerpt below. Hello Robert all, Yes, the LOR seems to have gone away now, even with net.inet.udp.soreceive_dgram_enabled=1. However, I started seeing another one: -- cut here -- lock order reversal: 1st 0x805a62a0 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/ pf.c:6773 2nd 0xff00011e3cf0 radix node head (radix node head) @ /usr/src/sys/net/rou te.c:293 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_flags() at _mtx_lock_flags+0x2f rtalloc1_fib() at rtalloc1_fib+0x85 rtalloc_ign_fib() at rtalloc_ign_fib+0xaa pf_calc_mss() at pf_calc_mss+0x89 pf_test_tcp() at pf_test_tcp+0xce2 pf_test() at pf_test+0xcdb pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x2dd ether_demux() at ether_demux+0x1b4 ether_input() at ether_input+0x1c6 bge_intr() at bge_intr+0x3d0 ithread_loop() at ithread_loop+0xe9 fork_exit() at fork_exit+0x110 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xa044dd30, rbp = 0 --- -- and here -- This one looks somewhat familiar (from the top of my head), but it's probably a subject for another thread :) -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDP LOR with the latest RELENG_7
On Fri, Oct 10, 2008 at 5:42 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 03:40:26PM +0300, Vlad GALU wrote: As my kernel had started to lock up periodically and I don't have hands-on access to that machine, I enabled WITNESS. So these started to pop up: -- cut here -- --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- uma_zalloc_arg: zone 16 with the following non-sleepable locks held: exclusive rw udp r = 0 (0x8064c928) locked @ /usr/src/sys/netinet/udp_usrreq.c:1125 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x241 uma_zalloc_arg() at uma_zalloc_arg+0x290 malloc() at malloc+0x5c getenv() at getenv+0x93 getenv_quad() at getenv_quad+0x13 getenv_int() at getenv_int+0x15 udp_inpcb_init() at udp_inpcb_init+0x1f slab_zalloc() at slab_zalloc+0x1ad uma_zone_slab() at uma_zone_slab+0xb4 uma_zalloc_arg() at uma_zalloc_arg+0x31d in_pcballoc() at in_pcballoc+0x38 udp_attach() at udp_attach+0x57 socreate() at socreate+0x14f socket() at socket+0x8a syscall() at syscall+0x1a9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- -- and here -- I tried to see whether bz@ had this one on his page, but his website is currently being migrated and the list of LORs was unavailable. Therefore, sorry if this mail is just noise... Your mail says latest RELENG_7. What is latest? When did you csup? rwatson@ made some UDP-related changes recently which were very important. The kernel had been updated 3 hours before writing the mail :) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDP LOR with the latest RELENG_7
On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa [EMAIL PROTECTED] wrote: At 08:40 AM 10/10/2008, Vlad GALU wrote: As my kernel had started to lock up periodically and I don't have hands-on access to that machine, I enabled WITNESS. So these started to pop up: Is this with a stock kernel and sysctl settings ? Or do you have any custom kernel options ? Jeremy pointed to a possible culprit - running csup again brought uipc_usrreq.c to version 1.206.2.5. I'm rebuilding a new kernel with this revision as I type and I'll see how it goes. I'm attaching the sysctl.conf below just to be safe: -- cut here -- kern.ipc.maxsockets=32768 kern.ipc.nmbclusters=65536 kern.ipc.shmall=134217728 kern.ipc.shmmax=134217728 kern.logsigexit=0 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.randompid=100 kern.random.sys.harvest.swi=1 kern.securelevel=-1 net.bpf.bufsize=1048576 net.bpf.maxbufsize=1048576 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=20 net.inet.icmp.icmplim_output=0 net.inet.icmp.maskrepl=0 net.inet.icmp.reply_from_interface=1 net.inet.ip.check_interface=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.process_options=0 net.inet.ip.random_id=0 # scrubbing with pf net.inet.ip.redirect=0 net.inet.ip.stealth=1 net.inet.tcp.always_keepalive=1 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=1 net.inet.tcp.drop_synfin=1 net.inet.tcp.log_in_vain=0 net.inet.tcp.recvspace=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.rfc3042=1 net.inet.tcp.rfc3390=1 net.inet.tcp.sack.enable=1 net.inet.tcp.sendspace=32768 net.inet.tcp.syncookies=0 net.inet.udp.blackhole=1 net.inet.udp.log_in_vain=0 net.link.ether.inet.max_age=1200 security.bsd.conservative_signals=1 security.bsd.hardlink_check_gid=0 security.bsd.hardlink_check_uid=1 security.bsd.see_other_gids=0 security.bsd.see_other_uids=0 security.bsd.suser_enabled=1 security.bsd.unprivileged_get_quota=0 security.bsd.unprivileged_proc_debug=0 security.bsd.unprivileged_read_msgbuf=0 security.jail.allow_raw_sockets=0 security.jail.set_hostname_allowed=0 security.jail.socket_unixiproute_only=1 security.jail.sysvipc_allowed=0 security.mac.seeotheruids.enabled=1 security.mac.seeotheruids.specificgid_enabled=1 security.mac.seeotheruids.specificgid=0 vfs.hirunningspace=33554432 vfs.read_max=16 vfs.ufs.dirhash_maxmem=8388608 -- and here -- ---Mike -- cut here -- --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- uma_zalloc_arg: zone 16 with the following non-sleepable locks held: exclusive rw udp r = 0 (0x8064c928) locked @ /usr/src/sys/netinet/udp_usrreq.c:1125 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x241 uma_zalloc_arg() at uma_zalloc_arg+0x290 malloc() at malloc+0x5c getenv() at getenv+0x93 getenv_quad() at getenv_quad+0x13 getenv_int() at getenv_int+0x15 udp_inpcb_init() at udp_inpcb_init+0x1f slab_zalloc() at slab_zalloc+0x1ad uma_zone_slab() at uma_zone_slab+0xb4 uma_zalloc_arg() at uma_zalloc_arg+0x31d in_pcballoc() at in_pcballoc+0x38 udp_attach() at udp_attach+0x57 socreate() at socreate+0x14f socket() at socket+0x8a syscall() at syscall+0x1a9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- -- and here -- I tried to see whether bz@ had this one on his page, but his website is currently being migrated and the list of LORs was unavailable. Therefore, sorry if this mail is just noise... -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UDP LOR with the latest RELENG_7
As my kernel had started to lock up periodically and I don't have hands-on access to that machine, I enabled WITNESS. So these started to pop up: -- cut here -- --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- uma_zalloc_arg: zone 16 with the following non-sleepable locks held: exclusive rw udp r = 0 (0x8064c928) locked @ /usr/src/sys/netinet/udp_usrreq.c:1125 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x241 uma_zalloc_arg() at uma_zalloc_arg+0x290 malloc() at malloc+0x5c getenv() at getenv+0x93 getenv_quad() at getenv_quad+0x13 getenv_int() at getenv_int+0x15 udp_inpcb_init() at udp_inpcb_init+0x1f slab_zalloc() at slab_zalloc+0x1ad uma_zone_slab() at uma_zone_slab+0xb4 uma_zalloc_arg() at uma_zalloc_arg+0x31d in_pcballoc() at in_pcballoc+0x38 udp_attach() at udp_attach+0x57 socreate() at socreate+0x14f socket() at socket+0x8a syscall() at syscall+0x1a9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x516348 --- -- and here -- I tried to see whether bz@ had this one on his page, but his website is currently being migrated and the list of LORs was unavailable. Therefore, sorry if this mail is just noise... -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDP LOR with the latest RELENG_7
On Fri, Oct 10, 2008 at 6:21 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 06:11:25PM +0300, Vlad GALU wrote: On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa [EMAIL PROTECTED] wrote: At 08:40 AM 10/10/2008, Vlad GALU wrote: As my kernel had started to lock up periodically and I don't have hands-on access to that machine, I enabled WITNESS. So these started to pop up: Is this with a stock kernel and sysctl settings ? Or do you have any custom kernel options ? Jeremy pointed to a possible culprit - running csup again brought uipc_usrreq.c to version 1.206.2.5. I'm rebuilding a new kernel with this revision as I type and I'll see how it goes. I'm attaching the sysctl.conf below just to be safe: I remember LORs pertaining to UDP being discussed recently. Possibly relevant threads: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45020 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45109 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45193 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45231 The last one is rwatson's fix, and confirmation from a couple people that it fixes their issues. I've rebuilt the kernel, the LORs are still there :( -- cut here -- --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x5269c8 --- uma_zalloc_arg: zone 16 with the following non-sleepable locks held: exclusive rw udp r = 0 (0x8064c928) locked @ /usr/src/sys/netinet/udp_usrreq.c:1125 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x241 uma_zalloc_arg() at uma_zalloc_arg+0x290 malloc() at malloc+0x5c getenv() at getenv+0x93 getenv_quad() at getenv_quad+0x13 getenv_int() at getenv_int+0x15 udp_inpcb_init() at udp_inpcb_init+0x1f slab_zalloc() at slab_zalloc+0x1ad uma_zone_slab() at uma_zone_slab+0xb4 uma_zalloc_arg() at uma_zalloc_arg+0x31d in_pcballoc() at in_pcballoc+0x38 udp_attach() at udp_attach+0x57 socreate() at socreate+0x14f socket() at socket+0x8a syscall() at syscall+0x1a9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffe8c8, rbp = 0x5269c8 --- -- and here -- I'll see whether the system still locks up or not though.. -- cut here -- kern.ipc.maxsockets=32768 kern.ipc.nmbclusters=65536 kern.ipc.shmall=134217728 kern.ipc.shmmax=134217728 kern.logsigexit=0 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.randompid=100 kern.random.sys.harvest.swi=1 kern.securelevel=-1 net.bpf.bufsize=1048576 net.bpf.maxbufsize=1048576 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=20 net.inet.icmp.icmplim_output=0 net.inet.icmp.maskrepl=0 net.inet.icmp.reply_from_interface=1 net.inet.ip.check_interface=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.process_options=0 net.inet.ip.random_id=0 # scrubbing with pf net.inet.ip.redirect=0 net.inet.ip.stealth=1 net.inet.tcp.always_keepalive=1 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=1 net.inet.tcp.drop_synfin=1 net.inet.tcp.log_in_vain=0 net.inet.tcp.recvspace=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.rfc3042=1 net.inet.tcp.rfc3390=1 net.inet.tcp.sack.enable=1 net.inet.tcp.sendspace=32768 net.inet.tcp.syncookies=0 net.inet.udp.blackhole=1 net.inet.udp.log_in_vain=0 net.link.ether.inet.max_age=1200 security.bsd.conservative_signals=1 security.bsd.hardlink_check_gid=0 security.bsd.hardlink_check_uid=1 security.bsd.see_other_gids=0 security.bsd.see_other_uids=0 security.bsd.suser_enabled=1 security.bsd.unprivileged_get_quota=0 security.bsd.unprivileged_proc_debug=0 security.bsd.unprivileged_read_msgbuf=0 security.jail.allow_raw_sockets=0 security.jail.set_hostname_allowed=0 security.jail.socket_unixiproute_only=1 security.jail.sysvipc_allowed=0 security.mac.seeotheruids.enabled=1 security.mac.seeotheruids.specificgid_enabled=1 security.mac.seeotheruids.specificgid=0 vfs.hirunningspace=33554432 vfs.read_max=16 vfs.ufs.dirhash_maxmem=8388608 -- and here -- Good grief, we could spend 2 years debugging just the sysctl.conf pieces... :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BPF plans for 7.1
On Sun, Sep 21, 2008 at 1:22 PM, Robert Watson [EMAIL PROTECTED] wrote: On Sat, 20 Sep 2008, Vlad GALU wrote: Will the zero-copy bpf(4) changes be merged to the stable branch before the release? Dear Vlad: Unfortunately, no. The code seems stable in 8-CURRENT, but I don't feel it's had enough actual testing exposure to go into 7.x yet. Also, the libpcap changes to support it have only just gone back into the tcpdump.org distribution of libpcap, and there is non-trivial reworking of that code, so we'd like to let that settle as well. We've had a number of queries so I suspect we'll start maintaining a 7.x MFC candidate patch fairly soon (next couple of months). Robert N M Watson Computer Laboratory University of Cambridge Thanks for your quick reply! I'll start experimenting with HEAD. -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
BPF plans for 7.1
Hi, Will the zero-copy bpf(4) changes be merged to the stable branch before the release? Thanks, Vlad -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
On 7/30/08, David Southwell [EMAIL PROTECTED] wrote: On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: Normally the FreeBSD Project tries very hard to avoid ABI breakage in Stable Branches. However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules that are not part of the baseline system (those will be patched by the MFC) which deal with advisory locks. As such the impact should not cause many people problems. The work that will be MFCed fixes issues with filesystem advisory locks, and moves the advisory locks list from filesystem-private data structures into the vnode structure. The MFC will be done by Kostantin Belousov some time this coming Friday (August 1st, 2008) if you have concerns and want to watch for it. Thanks. Sometimes information gets posted to this list on the assumption that everyone understand what the writer means. This is one of those occasions!! For those of us who are not as well informed and experienced as others could someone please explain what is meant by an ABI breakage, its implications and how to deal with them. ABI breakage occurs when internal data structures change (for instance, when members of the structure are removed or added). Kernel modules which expect those structures to look in a certain way will need to be recompiled. Also, depending on what data structures suffer the changes, ioctl() operations may fail, requiring a rebuild of the userland programs which issue the ioctl()s. And I'm sure that there are many other examples that I can't think of right now :) -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm_page_unwire: invalid wire count: 0
On Mon, Mar 31, 2008 at 7:47 PM, Volodymyr Kostyrko [EMAIL PROTECTED] wrote: Got a coredump each time when playing FLAC files through xmms2 with pulseaudio output plugin. cairn# kgdb /boot/kernel.old/kernel vmcore.9 [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 i386-marcel-freebsd. There is no member named pathname. (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0513f47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc05141d3 in panic (fmt=Variable fmt is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc068c742 in vm_page_unwire (m=0xc151e2d0, activate=0) at /usr/src/sys/vm/vm_page.c:1410 #4 0xc056d4da in vfs_vmio_release (bp=0xccec9228) at /usr/src/sys/kern/vfs_bio.c:1539 #5 0xc056db96 in brelse (bp=0xccec9228) at /usr/src/sys/kern/vfs_bio.c:1331 #6 0xc0582c59 in vtruncbuf (vp=0xc3d09dd0, cred=0x0, td=0xc3496000, length=0, blksize=16384) at /usr/src/sys/kern/vfs_subr.c:1257 #7 0xc0651ec7 in ffs_truncate (vp=0xc3d09dd0, length=0, flags=Variable flags is not available.) at /usr/src/sys/ufs/ffs/ffs_inode.c:405 #8 0xc066df0b in ufs_inactive (ap=0xd642cbbc) at /usr/src/sys/ufs/ufs/ufs_inode.c:132 #9 0xc06cdcfe in VOP_INACTIVE_APV (vop=0xc0735120, a=0xd642cbbc) at vnode_if.c:1513 #10 0xc057d449 in vinactive (vp=0xc3d09dd0, td=0xc3496000) at vnode_if.h:796 #11 0xc0580593 in vput (vp=0xc3d09dd0) at /usr/src/sys/kern/vfs_subr.c:2224 #12 0xc0586256 in kern_unlink (td=0xc3496000, path=0xbf7fbd7c Address 0xbf7fbd7c out of bounds, pathseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:1713 #13 0xc05862d2 in unlink (td=0xc3496000, uap=0xd642ccfc) at /usr/src/sys/kern/vfs_syscalls.c:1649 #14 0xc06c3e0e in syscall (frame=0xd642cd38) at /usr/src/sys/i386/i386/trap.c:1035 #15 0xc06ad830 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #16 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) uname -a: FreeBSD cairn.ints.net 7.0-STABLE FreeBSD 7.0-STABLE #77: Fri Mar 28 09:32:43 EET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CAIRN i386 -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Just a wild guess: do you have ZERO_COPY_SOCKETS in your kernel config file? If so, remove retry. -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Unionfs on RELENG_6
Now that the 6.3 release notes advertise its reimplementation, isn't it safe to remove the warning at the end of the mount_unionfs(8) ? -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog notifications?
On 1/21/08, Ivan Voras [EMAIL PROTECTED] wrote: Hi, Before I try to reinvent the wheel, I'd like to hear are there commonly used utilities that process syslog logs (e.g. /var/log/messages), grep them for some regex and notify configured e-mail addresses, in real time (as messages arrive)? I imagine something like that would either do a tail -f on log files or listen as a syslog filter. http://www.vanheusden.com/multitail/examples.html -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog notifications?
On 1/21/08, Ivan Voras [EMAIL PROTECTED] wrote: Vlad GALU wrote: On 1/21/08, Ivan Voras [EMAIL PROTECTED] wrote: Hi, Before I try to reinvent the wheel, I'd like to hear are there commonly used utilities that process syslog logs (e.g. /var/log/messages), grep them for some regex and notify configured e-mail addresses, in real time (as messages arrive)? I imagine something like that would either do a tail -f on log files or listen as a syslog filter. http://www.vanheusden.com/multitail/examples.html I'm not an expert in multitail but isn't it only for agregating log files? I'd like something that performs an action (like sending an e-mail) if it encounters a regex-described event in log file(s). http://www.vanheusden.com/multitail/features.html An external tool can be executed when a regular expression matches. It's all there, Luke. -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't attach to running processes with GDB
-- cut here -- (gdb) attach 58621 Attaching to process 58621 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) -- and here -- Any idea what corner to grab this from? -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Questions about building the world
On 1/19/08, Vlad GALU [EMAIL PROTECTED] wrote: 1. I noticed the WITHOUT_SSP switch in src.conf(5). Does this mean that Propolice is currently used by default? 2. For debugging purposes, I'd like to rebuild my whole world with debugging symbols. Adding -g to the flags in make.conf seemed to do the trink until right before the installation of the new files. Doing a nm on libc.so.7 yielded all the symbols, as expected. However, after performing the installworld, the library was stripped. Is there a switch to prevent stripping too? Seems that DEBUG_FLAGS=-g in src.conf did the trick. I should have RTFM. -- Mahnahmahnah! -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Questions about building the world
1. I noticed the WITHOUT_SSP switch in src.conf(5). Does this mean that Propolice is currently used by default? 2. For debugging purposes, I'd like to rebuild my whole world with debugging symbols. Adding -g to the flags in make.conf seemed to do the trink until right before the installation of the new files. Doing a nm on libc.so.7 yielded all the symbols, as expected. However, after performing the installworld, the library was stripped. Is there a switch to prevent stripping too? -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC6?
On 1/17/08, Ferdinand Goldmann [EMAIL PROTECTED] wrote: Hi! I am in the process of buying new Dell hardware, mainly the 2950 III. According to various postings I found, the PERC6/i Controller _should_ work with FreeBSD 6.3. Does anyone successfully use a 2950 III with PERC6/i controller and can confirm this? Sorry if the question sounds stupid, but as I cannot find any references to the PERC6 in either documentation or source code I am a bit confused, and I wanted to make sure it works before shelling out my employers money. :-) Many thanks for any enlightenment on this subject, kind regards, Ferdinand Don't know if this is useful to you, but I'm using 7.0 on the same Dell platform, and hence on the same controller, with very good results. I think the mfi(4) manpage should be updated too :) -- Ferdinand Goldmann Johannes Kepler University Linz - Server Systems/ZID Mail: [EMAIL PROTECTED] Phone: 00437024689398 Fax: 00437024689397 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What current Dell Systems are supported/work
On 1/8/08, Richard Bates [EMAIL PROTECTED] wrote: Sorry for the repost... I don't think the first one posted.. posted to freebsd.stable, freebsd-current, Freebsd-hardware I checked the hardware in the online documentation manual/hardware It only lists the bits and peices of the machine say the hard drive controller and so forth. but doesn't give you a particular system to look at as a working machine with FreeBSD 6.2 does anybody know if a Dell PowerEdge 1950 • Quad-Core Intel Xeon Processors 5400 series 3.16GHz • 4GB Ram I am looking to attach 2 machines to a SAN to make a constantly up system. Is there a Dell San and San Switch that will work with this version of BSD? I'm using a newer version of the PE2950, which has the PERC 6/i controller. Older ones use the PERC 5/i, which is supported by 6.2. Dell machines are pretty well supported. Thank you for your help ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reboot after panic: vm_page_unwire: invalid wire count: 0
On 11/13/07, Vivek Khera [EMAIL PROTECTED] wrote: I've got a Dell 1750 box that was rock-solid stable running 4.11 for a couple of years now operating a pretty busy website backend. A month or so ago we wiped it clean and repurposed it to run a different website running Drupal with a Varnish front-end cache using FreeBSD 6.2-RELEASE-p5. The system is i386 and has 1Gb of RAM. Uname output: FreeBSD mb.kcilink.com 6.2-RELEASE-p5 FreeBSD 6.2- RELEASE-p5 #0: Wed Jun 27 10:47:15 EDT 2007 [EMAIL PROTECTED]:/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/ KCI32SMP i386 The last week or so, it has been crashing regularly. Sometimes twice per day, and sometimes it runs for two days without a problem. I finally managed to make it dump a crashlog and core, and discovered that the panic was: reboot after panic: vm_page_unwire: invalid wire count: 0 I google around and found one old PR #33637 which had a patch but that was for FreeBSD 4.5. I have also found two other mentions of this panic, one on the mailing lists with no responses, and another for a PR from 6.1-PRERELEASE, PR #94578, which has no comments on it. According to the http and varnish logs, we're not being particularly hit very hard when the panic happens, but I don't know if we lose some log data during the panic. I have the core and the kernel.debug. I'm not sure what info to extract from it beyond the backtrace. The watchdog timer fired and dropped me to DDB, so I just typed watchdog and c and let it finish dumping. Here's the backtrace, and bt full output. # kgdb kernel.debug /var/crash/vmcore.0 [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 i386-marcel-freebsd. Unread portion of the kernel message buffer: panic: vm_page_unwire: invalid wire count: 0 cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c5a76000,c0e88ab0,0,d90d82c8,...) at kdb_backtrace +0x29 panic(c06b011f,0,c0e88ab0,efe80900,c057b96a,...) at panic+0x114 vm_page_unwire(c0e88ab0,0) at vm_page_unwire+0x68 vfs_vmio_release(d90d82c8) at vfs_vmio_release+0xa2 getnewbuf(0,0,4000,4000) at getnewbuf+0x2bc getblk(c6f81550,4f5,0,4000,0,...) at getblk+0x360 ffs_balloc_ufs2(c6f81550,13d4000,0,fa,c4f32780,...) at ffs_balloc_ufs2+0x1606 ffs_write(efe80bec) at ffs_write+0x2ec VOP_WRITE_APV(c06e06a0,efe80bec) at VOP_WRITE_APV+0xce vn_write(c59c8000,efe80cbc,c51cf400,0,c5a76000) at vn_write+0x1ee dofilewrite(c5a76000,c,c59c8000,efe80cbc,,...) at dofilewrite +0x77 kern_writev(c5a76000,c,efe80cbc,821bba3,fa,...) at kern_writev+0x3b write(c5a76000,efe80d04) at write+0x45 syscall(3b,809003b,bfbf003b,0,bfbfeaa4,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x483d732f, esp = 0xbfbfe9dc, ebp = 0xbfbfea08 --- Uptime: 1d20h51m58s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261872 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 95interrupt total irq4: sio0 21758 irq15: ata11 irq16: bge0 4544565 irq17: bge1 17684238 irq18: amr0 588223 cpu0: timer323148326 cpu2: timer323148294 cpu1: timer323148331 cpu3: timer323148344 Total 1315432158 KDB: stack backtrace: kdb_backtrace(c069ec5d,4e67e6de,0,c06ea170,c06e9818,...) at kdb_backtrace+0x29 watchdog_fire(c07120e0,c8,efe80634,c065c821,efe8063c,...) at watchdog_fire+0x9d hardclock(efe8063c) at hardclock+0x115 lapic_handle_timer(0) at lapic_handle_timer+0x51 Xtimerint(c4fe6000,1,efe806a8,c066d57b,c4fe6000,...) at Xtimerint+0x30 getit(c4fe6000,c4fe6000,4,efe806c0,c0496f97,...) at getit+0x88 DELAY(1) at DELAY+0x3b amr_quartz_poll_command1(c4fe6000,c51fbff0,0,0,1000,...) at amr_quartz_poll_command1+0x1af amr_setup_polled_dmamap(c51fbff0,c4fef800,1,0) at amr_setup_polled_dmamap+0x94 bus_dmamap_load(c4ffe380,0,c0c22000,1,c0496cd4,c51fbff0,1) at bus_dmamap_load+0x4b5 amr_quartz_poll_command(c51fbff0) at amr_quartz_poll_command+0x51 amr_dump_blocks(c4fe6000,0,4cb25e,c0c22000,80) at amr_dump_blocks+0x5f amrd_dump(c515b700,c0c22000,0,9964bc00,0,1) at amrd_dump+0x7c cb_dumpdata(c0711a48,1,c06f44a0) at
Re: reboot after panic: vm_page_unwire: invalid wire count: 0
On 11/13/07, Vivek Khera [EMAIL PROTECTED] wrote: On Nov 13, 2007, at 4:50 PM, Vlad GALU wrote: vmio = 1 offset = Unhandled dwarf expression opcode 0x93 (kgdb) Do you happen to have ZERO_COPY_SOCKETS in your kernel config? Yes, I do. Are they known to be bad under certain loads or just in general. I don't have this issue with any other web server running the same kernel config but those are amd64 boxes mostly. Remove, retry :) This thing bit me hard in the past too, see the freebsd-fs@ archives. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( Which? I can look into it. This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. I tested by setting kern.pts.max to an appropriately small value, such as 20-30, then opening many ptys from within screen. Even after closing all of them and exiting screen, the cleanup wasn't done. Thanks once again for your attention! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openpty() and jail in RELENG_7
On 11/7/07, Tom Evans [EMAIL PROTECTED] wrote: On Tue, 2007-11-06 at 22:19 +0200, Dan Epure wrote: Hi All, I'm using on the host system (7.0-BETA2): #sysctl kern.pts.enable kern.pts.enable: 1 I have no problem at all. The jail is also 7.0-BETA2 The problem is inside the jail openpty() can not allocate the pty: === cut here === debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 openpty: No such file or directory session_pty_req: session 0 alloc failed debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell === and here === the ssh session just hangs. (no pty ?) I did not forget to mount devfs inside the jail. The jail is configured in rc.conf: === cut here === jail_enable=YES jail_list=test jail_test_hostname=test.mydomain.org jail_test_rootdir=/jails/test jail_test_interface=bge0 jail_test_devfs_enable=YES jail_test_ip=192.168.10.2 jail_set_hostname_allow=NO jail_sysvipc_allow=NO jail_socket_unixiproute_only=YES === and here === I think the problem is related to restrictions imposed by the jail. Please advise. Gepu This is because you haven't been allocated a pty inside your jail. Enable sshd inside your jail, ssh to your jail (which will allocate you a pty). Then from inside your jail, you can use any pty-using application you wish. I am presuming you are doing something like 'jexec 1 /bin/csh' or similar, and I'm only really repeating Xin Li's advice to me[1]. Cheers Tom [1] http://lists.freebsd.org/pipermail/freebsd-jail/2007-October/000106.html I'm chiming in to signal a possibly related problem. Logging in and out via sshd behaves normally (ie: the ptys are cleaned up accordingly) but opening virtual consoles in screen and then closing them does not, thus leading to starvation. -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldxref: file isn't dynamically-linked -- expected behaviour?
On 10/18/07, Philipp Ost [EMAIL PROTECTED] wrote: Hi list, I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I did the following after csup'ing my sources: # make kernel-toolchain # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL The last thing 'installkernel' reports is: [...] kldxref /boot/kernel kldxref: file isn't dynamically-linked [...] This message is repeated 514 times... ;-) Is this expected behaviour? Before I do a reboot I would like to make sure everything works as I rely on that particular machine. If needed I can provide full logs; MYKERNEL is a cut down version of GENERIC with atapicam, drm, radeondrm, sound added ;-) Thanks in advance for any hint/help! It's harmless. Once you boot with your new RELENG_7 they will disappear on the next kernel build/install. Regards, 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] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/4/07, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-10-02 15:41, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Sm?rgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. There was an old bug, which caused pts consumers to get stuck in devdrn. This has been fixed, AFAICT, a long time ago. At least, I can't reproduce it any more with the usual tests: * Closing xterm windows. * Closing telnet sessions. * Exiting from screen(1) windows. Weird. 3 people on this thread already saw the symptoms :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Steven Hartland [EMAIL PROTECTED] writes:
Any one got any pointers on this, the machine we running this app on is over
90% idle so I really don't want to have to install a second machine just to
workaround a limit on the number of pty's, surely there's a way to increase
this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
Looks like it hasn't been. A friend who tried to set up an access
server for his company stumbled upon it.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. However, I see that, if I use pts/0-7, for instance, then log off pts/7, the next assigned pts will be pts/8. Is this expected? I tried lowering kern.pts.max to 20. If I open 20 of them and close them afterwards, on the next try I get no more ptys from my screen. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. Wouldn't get deallocated right away, or wouldn't get deallocated at all? Apparently, it is not unusual for pts reclamation to be delayed a bit by a non-zero refcnt. As per my other mail, they wouldn't get deallocated at all. They still show up in /dev/pts/ even after closing, and the next integer index is picked up upon the next terminal creation. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_nullfs in jail?
On 4/19/07, Anton - Valqk [EMAIL PROTECTED] wrote: Hi Guys, Is there any way to have mount_nullfs working inside the jail? I mount nullfs from the host, that's how I share the ports directory across jails. Please gime me any idea on that topic. Thank you. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openvpn tap uses 99% cpu time
On 3/14/07, Emile Coetzee [EMAIL PROTECTED] wrote: Since the latest updates to sys/net/if_tap.c (I suspect) in 6.2-STABLE my openvpn tap server is using up all available CPU time (99%) effectively killing the box. I replicated this on a second machine which was about 3 weeks behind with a cvsup to the latest from RELENG_6 and after rebuilding the kernel it does the same thing. I have portupgraded openvpn to the latest release (openvpn-2.0.6_7), but this had not made any difference. Is anyone else experiencing similar problems? It usually happens when OpenVPN is told to retry connecting to the remote endpoint and the remote endpoint isn't accessible due to network conditions. It happens the same even on Windows. Regards Emile ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java 1.5 diablo binaries from freebsd foundation
On 2/12/07, Jeffrey Williams [EMAIL PROTECTED] wrote: Has anyone tried loading the java 1.5 diablo binaries from the freebsd foundation on 6.2 yet? Yes, and it works OK. I also happen to run the java/jdk15 port and it runs just as smoothly. You can ask the port maintainer about the differences between the two. Given that I'm a total Java illiterate, I can't say I notice any difference. I have a friend though, who's an avid Java developer, that says he's very pleased with the stability and speed of both. Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loosing spam fight
On 1/24/07, Gustavo Feijó [EMAIL PROTECTED] wrote:
Hi there,
I know it's not the right list to write to, but I'll still try a shot.
There is freebsd-isp@, as well :)
I'm running sendmail in my FreeBSD box and wish to block mails comming
from domains with no ptr configs.
Am I missing something?
My sendmail-rx.mc is like this
FEATURE(`access_db',`hash -TTMPF -o /etc/mail/access.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`ALIAS_FILE', `/etc/mail/aliases')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`use_client_ptr')dnl
FEATURE(`delay_checks')dnl
dnl #
dnl # configuracoes de lista de spammers
dnl #
FEATURE(`dnsbl', `dul.dnsbl.sorbs.net', `550 Mail from
$`'{client_addr} refused - see http://www.dul.dnsbl.sorbs.net/;')
FEATURE(`dnsbl', `sbl.spamhaus.org', `550 Mail from
$`'{client_addr} refused - see http://www.spamhaus.org/sbl/;')
FEATURE(`dnsbl', `list.dsbl.org', `550 Mail from $`'{client_addr}
refused - see http://dsbl.org/;')
FEATURE(`dnsbl', `bl.spamcop.net', `450 Mail from $`'{client_addr}
refused - see http://spamcop.net/bl.shtml;')
dnl #
--
[]'s
chmod000
Microsoft butterfly is their way of telling you their system has a
lot of @#$ bugs!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keyboard
On 1/8/07, Cristian Fatu [EMAIL PROTECTED] wrote: Hello to all ! I want to disable keyboard port ... can somebody help me ? hint.atkbdc.0.disable=1 or hint.atkbd.0.disable=1 in /boot/device.hints. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun not working on [EMAIL PROTECTED]
On 12/12/06, Divacky Roman [EMAIL PROTECTED] wrote: hi can anyone confirm that he has working tunnel over if_tun device on 6.2 and amd64? Yes, I have OpenVPN using tun(4) running smoothly on a machine running RELENG_6 on amd64. I cannot get it work (using vtund). The configuration is correct, it sets up but no packets go through. any ideas? thnx roman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 11/1/06, Vlad Galu [EMAIL PROTECTED] wrote: On 10/31/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote: Yes, but for objective reasons I can't publish it :( The only debugging option that I didn't use was INVARIANTS. Which is coincidentally the most useful one ;-) Also turn on DEBUG_LOCKS and DEBUG_VFS_LOCKS then report the output of 'show lockedvnods' at the time of crash, as well. Upon Tor Egge's suggestion, I removed ZERO_COPY_SOCKETS from my kernel and the machine has been running nicely ever since. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR with today's RELENG_6
-- cut here -- lock order reversal: 1st 0x80501ba0 cdev (cdev) @ kern/kern_conf.c:61 2nd 0x858d20f8 sleep mtxpool (sleep mtxpool) @ kern/kern_prot.c:1877 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x4d2 _mtx_lock_flags() at _mtx_lock_flags+0x5c crhold() at crhold+0x26 make_dev_credv() at make_dev_credv+0xb0 make_dev_cred() at make_dev_cred+0x8e pty_clone() at pty_clone+0xcd devfs_lookup() at devfs_lookup+0x55e VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x7e lookup() at lookup+0x351 namei() at namei+0x399 vn_open_cred() at vn_open_cred+0x1e0 kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x4a1 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open), rip = 0x2168fe1c, rsp = 0x7fffde58, rbp = 0x40 --- -- and here -- -STABLE hasn't been that stable lately :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with today's RELENG_6
On 11/9/06, Vlad Galu [EMAIL PROTECTED] wrote: -- cut here -- lock order reversal: 1st 0x80501ba0 cdev (cdev) @ kern/kern_conf.c:61 2nd 0x858d20f8 sleep mtxpool (sleep mtxpool) @ kern/kern_prot.c:1877 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x4d2 _mtx_lock_flags() at _mtx_lock_flags+0x5c crhold() at crhold+0x26 make_dev_credv() at make_dev_credv+0xb0 make_dev_cred() at make_dev_cred+0x8e pty_clone() at pty_clone+0xcd devfs_lookup() at devfs_lookup+0x55e VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x7e lookup() at lookup+0x351 namei() at namei+0x399 vn_open_cred() at vn_open_cred+0x1e0 kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x4a1 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open), rip = 0x2168fe1c, rsp = 0x7fffde58, rbp = 0x40 --- -- and here -- -STABLE hasn't been that stable lately :( Ahm, it's on the list already, at position #187. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with today's RELENG_6
On 11/9/06, Vlad Galu [EMAIL PROTECTED] wrote: On 11/9/06, Vlad Galu [EMAIL PROTECTED] wrote: -- cut here -- lock order reversal: 1st 0x80501ba0 cdev (cdev) @ kern/kern_conf.c:61 2nd 0x858d20f8 sleep mtxpool (sleep mtxpool) @ kern/kern_prot.c:1877 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x4d2 _mtx_lock_flags() at _mtx_lock_flags+0x5c crhold() at crhold+0x26 make_dev_credv() at make_dev_credv+0xb0 make_dev_cred() at make_dev_cred+0x8e pty_clone() at pty_clone+0xcd devfs_lookup() at devfs_lookup+0x55e VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x7e lookup() at lookup+0x351 namei() at namei+0x399 vn_open_cred() at vn_open_cred+0x1e0 kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x4a1 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open), rip = 0x2168fe1c, rsp = 0x7fffde58, rbp = 0x40 --- -- and here -- -STABLE hasn't been that stable lately :( Ahm, it's on the list already, at position #187. Reported by yours truly, even. I need some sleep :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when portupgrade in jail (devfs related?)
On 11/5/06, Rong-en Fan [EMAIL PROTECTED] wrote: [...] I get these too. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 10/31/06, Kris Kennaway [EMAIL PROTECTED] wrote: It now crashes in a different place. Unfortunately I don't have physical access to the machine. A bt full is available at http://night.rdslink.ro/dudu/freebsd/03_11_2006.txt. The stack was corrupted though :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 10/1/06, Cy Schubert [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Vlad GALU writes: On 9/30/06, Martin Blapp [EMAIL PROTECTED] wrote: Hi, 1.) Bad ram ? Have you run some memory tester ? Yes, memtest86 didn't show anything weird. 2.) Have you background fsck running on this disk ? If so try to boot into single user and do a full fsck on this disk. I have background_fsck=NO in rc.conf and I checked the whole disk several times. Something I forgot to mention earlier: the crash is easier to reproduce when running rtorrent. The machine did crash without running it as well, but far more seldom. I've been experiencing the same problem as well. I discovered that the disk on which the filesystem was had some bad sectors causing dump -0Lauf to fail while taking snapshot causing the system to panic. Running smartctl on the device indicated that there were bad sectors 40% within the surface scan being performed by SMART. The drive, an 80 GB Maxtor, was replaced with a 250 GB Western Digital (for a very good price, so good a price I purchased two of them). It was 906 days old, having only been powered off maybe a dozen times over the last three years. During the last 2 weeks I ran the same system with WITNESS turned on. The fact that the purpose of this machine is not I/O dependant allowed me to run bonnie++ and iozone every second day for the whole 24 hours. At the same time I ran several instances of rtorrent. This morning I rebooted to a non-WITNESS kernel (the same sources from 2 weeks ago) and the exact same crash occured within a few hours from bootup. In all this time, smartd didn't report anything suspicious. WITNESS only reported a LOR related to kqueue that is already known. Any ideas for further stresstesting would be welcome. I am familiar with a few parts of the kernel, but VFS is a total stranger to me. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 10/31/06, Eric Anderson [EMAIL PROTECTED] wrote: On 10/31/06 08:03, Vlad Galu wrote: On 10/1/06, Cy Schubert [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Vlad GALU writes: On 9/30/06, Martin Blapp [EMAIL PROTECTED] wrote: Hi, 1.) Bad ram ? Have you run some memory tester ? Yes, memtest86 didn't show anything weird. 2.) Have you background fsck running on this disk ? If so try to boot into single user and do a full fsck on this disk. I have background_fsck=NO in rc.conf and I checked the whole disk several times. Something I forgot to mention earlier: the crash is easier to reproduce when running rtorrent. The machine did crash without running it as well, but far more seldom. I've been experiencing the same problem as well. I discovered that the disk on which the filesystem was had some bad sectors causing dump -0Lauf to fail while taking snapshot causing the system to panic. Running smartctl on the device indicated that there were bad sectors 40% within the surface scan being performed by SMART. The drive, an 80 GB Maxtor, was replaced with a 250 GB Western Digital (for a very good price, so good a price I purchased two of them). It was 906 days old, having only been powered off maybe a dozen times over the last three years. During the last 2 weeks I ran the same system with WITNESS turned on. The fact that the purpose of this machine is not I/O dependant allowed me to run bonnie++ and iozone every second day for the whole 24 hours. At the same time I ran several instances of rtorrent. This morning I rebooted to a non-WITNESS kernel (the same sources from 2 weeks ago) and the exact same crash occured within a few hours from bootup. In all this time, smartd didn't report anything suspicious. WITNESS only reported a LOR related to kqueue that is already known. Any ideas for further stresstesting would be welcome. I am familiar with a few parts of the kernel, but VFS is a total stranger to me. Did you get a crash dump? If not, you might want to start with adding all the debugger options into the kernel. Yes, but for objective reasons I can't publish it :( The only debugging option that I didn't use was INVARIANTS. However, I issued an output of bt full during the beginning of this thread. See http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028985.html. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 10/31/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote: Yes, but for objective reasons I can't publish it :( The only debugging option that I didn't use was INVARIANTS. Which is coincidentally the most useful one ;-) Also turn on DEBUG_LOCKS and DEBUG_VFS_LOCKS then report the output of 'show lockedvnods' at the time of crash, as well. I've applied a patch suggested by Eric and I'll see how it goes with it. If it crashes again, I'll add the things you mentioned to my kernel configuration and get back to the list with further details. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance 4.x vs. 6.x (was: e: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon)
On 10/12/06, Dan Lukes [EMAIL PROTECTED] wrote: Danial Thom wrote: The right thing to do is to port the SATA support and new NIC support back to 4.x and support both. 4.x is far superior on a Uniprocessor system and FreeBSD-5+ may be an entire re-write away from ever being any good at MP. Come to terms with it, PLEASE, because it is the case and saying otherwise won't change it. Despite I'm initiator of this way of discussion (in security list), I can't agree with you. No way. You are not allowed to tell to someone working as volunteer several months on something that the best way is rollback all work and start from scratch. Despite of your complaints are competent or not. You totally miss the right time for this type of complain. It's too late now. 6.x is not crap in any way. It has some problem, even after many months of development, but it can be resolved if volunteers decide to use it's power to polish previously implemented code. Current 6.x is better in many parameters than 4.x. Well, some important parameters are worse, but correct decision is improve them, not rollback all work. I voted against premature EOLing of 4.x, but returning to FreeBSD 4.x is not acceptable way in any way - at least because it's the DragonBSD's nest now. Dan Don't go with the flow, he's a known troll. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Is jemalloc going to make its way into RELENG_6?
Judging from my tests (allocating numerous small objects, then freeing the memory) it looks like the bottleneck is in free(). I've built a different libc library with the malloc.c and tree.h taken from HEAD and it now behaves nicely. I haven't seen any bad side effects on this machine (it's the lappie I do most of my work on, I run KDE, seamonkey, mplayer, openoffice, the like) since I switched to the new libc. Another nice solution would be to ship the modified libc in base so the people who really need jemalloc can relink to it via libmap.conf. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Frequent VFS crashes with RELENG_6
I've been getting random crashes like the one below, once or twice a
week, always in the same code path. The system is a RELENG_6 as of Wed
Sep 27 11:42:57 EEST 2006, running on amd64.
-- cut here --
#0 doadump () at pcpu.h:172
No locals.
#1 0x8022d033 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0x8022d687 in panic (fmt=0xff002bb6e260 °ö¾\) at
../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xa7995790, reg_save_area = 0xa79956b0}}
buf = vm_page_unwire: invalid wire count: 0, '\0' repeats 218 times
#3 0x8036980b in vm_page_unwire (m=0xff003e5c79e8,
activate=0) at ../../../vm/vm_page.c:1265
No locals.
#4 0x80282c15 in vfs_vmio_release (bp=0x9a6c2430) at
../../../kern/vfs_bio.c:1470
i = 1
m = 0xff003e5c79e8
#5 0x80285f78 in getnewbuf (slpflag=0, slptimeo=0, size=0,
maxsize=16384) at ../../../kern/vfs_bio.c:1779
addr = 18446744072226429136
bp = (struct buf *) 0x9a6c2430
nbp = (struct buf *) 0x9a69ac48
defrag = 0
nqindex = 1
flushingbufs = 0
#6 0x802863c0 in getblk (vp=0xff001015c5d0, blkno=0,
size=2048, slpflag=0, slptimeo=0, flags=0) at
../../../kern/vfs_bio.c:2486
bsize = 0
maxsize = 0
vmio = 1
offset = 0
bp = (struct buf *) 0x0
bo = (struct bufobj *) 0xff001015c720
#7 0x802880ec in breadn (vp=0xff001015c5d0, blkno=0,
size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at
../../../kern/vfs_bio.c:738
bp = (struct buf *) 0xa79958f0
rabp = (struct buf *) 0x344
i = -1
rv = 0
readwait = 0
#8 0x8028850e in bread (vp=0x0, blkno=0, size=0, cred=0x0,
bpp=0x0) at ../../../kern/vfs_bio.c:719
No locals.
#9 0x803427a5 in ffs_read (ap=0x0) at ../../../ufs/ffs/ffs_vnops.c:523
vp = (struct vnode *) 0xff001015c5d0
ip = (struct inode *) 0xff0017978780
uio = (struct uio *) 0xa7995b50
fs = (struct fs *) 0xff0012347000
bp = (struct buf *) 0x0
lbn = 0
nextlbn = 1
bytesinfile = 0
size = 2048
xfersize = 836
blkoffset = 0
error = 0
orig_resid = 4096
seqcount = 2
ioflag = 131072
#10 0x803b374a in VOP_READ_APV (vop=0x0, a=0x0) at vnode_if.c:643
rc = 0
#11 0x802a74e0 in vn_read (fp=0xff001e5f8078,
uio=0xa7995b50, active_cred=0x0, flags=0,
td=0xff002bb6e260) at vnode_if.h:343
vp = (struct vnode *) 0xff001015c5d0
error = 0
ioflag = 131072
#12 0x80257b64 in dofileread (td=0xff002bb6e260, fd=5,
fp=0xff001e5f8078, auio=0xa7995b50, offset=0, flags=0) at
file.h:240
cnt = 4096
error = 509575288
ktruio = (struct uio *) 0x0
#13 0x80257de0 in kern_readv (td=0xff002bb6e260, fd=5,
auio=0xa7995b50) at ../../../kern/sys_generic.c:192
fp = (struct file *) 0xff001e5f8078
error = 0
#14 0x80257eda in read (td=0x0, uap=0x0) at
../../../kern/sys_generic.c:116
auio = {uio_iov = 0xa7995b40, uio_iovcnt = 1,
uio_offset = 0, uio_resid = 4096, uio_segflg = UIO_USERSPACE, uio_rw =
UIO_READ, uio_td = 0xff002bb6e260}
aiov = {iov_base = 0x666000, iov_len = 4096}
#15 0x8038b2d8 in syscall (frame=
{tf_rdi = 5, tf_rsi = 6709248, tf_rdx = 4096, tf_rcx =
542953472, tf_r8 = 1, tf_r9 = 0, tf_rax = 3, tf_rbx = 6151168, tf_rbp
= 4294967295, tf_r10 = 3260, tf_r11 = 518, tf_r12 = 0, tf_r13 =
140737488327200, tf_r14 = 140737488327328, tf_r15 = 5, tf_trapno = 12,
tf_addr = 9093168, tf_flags = 0, tf_err = 2, tf_rip = 550694412, tf_cs
= 43, tf_rflags = 518, tf_rsp = 140737488327160, tf_ss = 35}) at
../../../amd64/amd64/trap.c:792
params = 0x7fff9200 Address 0x7fff9200 out of bounds
callp = (struct sysent *) 0x80502ae8
p = (struct proc *) 0xff0022bef6b0
orig_tf_rflags = 518
sticks = 116
error = 0
narg = 3
args = {5, 6709248, 4096, 542953472, 1, 0, 140737488327328, 5}
argp = (register_t *) 0x0
code = 3
reg = 48
regcnt = 6
#16 0x80377bc8 in Xfast_syscall () at
../../../amd64/amd64/exception.S:270
-- and here --
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
On 9/30/06, Martin Blapp [EMAIL PROTECTED] wrote:
Hi,
1.) Bad ram ? Have you run some memory tester ?
Yes, memtest86 didn't show anything weird.
2.) Have you background fsck running on this disk ? If
so try to boot into single user and do a full fsck on this
disk.
I have background_fsck=NO in rc.conf and I checked the whole disk
several times.
Something I forgot to mention earlier: the crash is easier to
reproduce when running rtorrent. The machine did crash without running
it as well, but far more seldom.
Martin
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
On Sat, 30 Sep 2006, Vlad GALU wrote:
I've been getting random crashes like the one below, once or twice a
week, always in the same code path. The system is a RELENG_6 as of Wed
Sep 27 11:42:57 EEST 2006, running on amd64.
-- cut here --
#0 doadump () at pcpu.h:172
No locals.
#1 0x8022d033 in boot (howto=260) at
../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0x8022d687 in panic (fmt=0xff002bb6e260 °ö¾\) at
../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xa7995790, reg_save_area = 0xa79956b0}}
buf = vm_page_unwire: invalid wire count: 0, '\0' repeats 218
times
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Professional sound card
On 8/7/06, Andrew Reilly [EMAIL PROTECTED] wrote: Yet another M-Audio (Audiophile 192) + 4Front + FreeBSD happy user :) -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On 7/12/06, Bartosz Fabianowski [EMAIL PROTECTED] wrote: Since the iwi driver has been MFC'd, I cannot build a kernel any more. I csupped my src/sys to RELENG_6 a couple of hours ago. Everything compiles fine, but when linking the kernel, make barfs: linking kernel if_iwi.o(.text+0x29c4): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x29d3): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': : undefined reference to `firmware_put' if_iwi.o(.text+0x49a5): In function `iwi_init_locked': : undefined reference to `firmware_get' I have device iwi in my kernel configuration. Should I remove it and use a module instead? Or is this supposed to work? You need to add device firmware to your kernel configuration file as well. This driver uses the new firmware(9) framework. - Bartosz -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
iwi(4) in RELENG_6
Is the iwi driver going to be synced with rev. 1.3x of HEAD? I'm using 1.36 along with a RELENG_6 tree, since it works better (read: it works). From the HEAD commit messages I understand that some MFCs would've been in order by now. Are there any show-stoppers that push that schedule ahead ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On 7/10/06, Max Laier [EMAIL PROTECTED] wrote: On Monday 10 July 2006 16:40, Vlad GALU wrote: Is the iwi driver going to be synced with rev. 1.3x of HEAD? I'm using 1.36 along with a RELENG_6 tree, since it works better (read: it works). From the HEAD commit messages I understand that some MFCs would've been in order by now. Are there any show-stoppers that push that schedule ahead ? no. The only thing that bugs me a bit, is that the change will break POLA for people using the old version. I have yet to hear from somebody using that successfully, though. I will get on MFCing it later today. Thanks, Max! -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade failed - /var/db/pkg/pkgdb.db: unexpected file type or format
On 7/2/06, Dominik Zalewski [EMAIL PROTECTED] wrote: I'm using FreeBSD 6.1-stable . Today I updated my ports tree using cvsup and then I ran as usually portupgrade -a . It upgraded my portupgrade to version portupgrade-2.1.3.2,2. After that portupgrade stopped working. Here is an error message: [EMAIL PROTECTED] /]# portupgrade -a [Updating the pkgdb format:bdb_btree in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb format:bdb_btree in /var/db/pkg ... [Updating the pkgdb format:bdb_btree in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb format:bdb_btree in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument: Cannot update the pkgdb!]: Cannot update the pkgdb!] Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFQ Removing pkgdb.db and INDEX-6.db and then rebuilding them with pkgdb and portsdb did the trick for me. Any ideas? Thank you in advance, Dominik Zalewski ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 frequent crashes
On 6/16/06, Vlad GALU [EMAIL PROTECTED] wrote: [...] I wonder why the page's wired refcounter reaches 0 and yet the page is on the wired list. It looks like this happens when the VM subsystem tries to move the page to a different queue. Am I wrong ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_6 frequent crashes
Unfortunately this is the third time I report this. This panic
occurs every 2 to 6 days. So far I've never managed to go over a
week's uptime. Between crashes I've periodically updated to the latest
RELENG_6. Here's the full backtrace:
-- cut here --
(kgdb) bt fu
#0 doadump () at pcpu.h:165
No locals.
#1 0xc0582b84 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0xc0583117 in panic (
fmt=0xc0751ab1 vm_page_unwire: invalid wire count: %d)
at ../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
buf = vm_page_unwire: invalid wire count: 0, '\0' repeats 218 times
#3 0xc06c4c00 in vm_page_unwire (m=0xc2669220, activate=0)
at ../../../vm/vm_page.c:1197
No locals.
#4 0xc05d4d75 in vfs_vmio_release (bp=0xda610da8)
at ../../../kern/vfs_bio.c:1470
i = 3
m = 0xc2669220
#5 0xc05d8509 in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384)
at ../../../kern/vfs_bio.c:1779
addr = 3663760120
bp = (struct buf *) 0xda610da8
nbp = (struct buf *) 0xda497348
defrag = 0
nqindex = 1
flushingbufs = 0
#6 0xc05d890e in getblk (vp=0xca945220, blkno=9273, size=16384, slpflag=0,
slptimeo=0, flags=0) at ../../../kern/vfs_bio.c:2486
bsize = 16384
maxsize = 0
vmio = 1
offset = 151928832
bp = (struct buf *) 0x4000
bo = (struct bufobj *) 0xca9452e0
#7 0xc067faf6 in ffs_balloc_ufs2 (vp=0xca945220,
startoffset=Unhandled dwarf expression opcode 0x93
)
at ../../../ufs/ffs/ffs_balloc.c:817
ip = (struct inode *) 0xca8eb8c4
dp = (struct ufs2_dinode *) 0xca21fd00
lbn = 9273
lastlbn = 11187
fs = (struct fs *) 0xc8622000
bp = (struct buf *) 0xda608af8
nbp = (struct buf *) 0xc05dea5f
ump = (struct ufsmount *) 0xc8396a00
indirs = {{in_lbn = -2061, in_off = 1, in_exists = 0}, {
in_lbn = -2061, in_off = 3, in_exists = 0}, {in_lbn = -8204,
in_off = 1069, in_exists = 0}, {in_lbn = 8589934591, in_off = 0,
in_exists = 0}, {in_lbn = -1828101238395240448, in_off = -1067988038,
in_exists = -969433728}}
nb = Unhandled dwarf expression opcode 0x93
(kgdb)
-- and here --
My kernel looks like this:
-- cut here --
machine i386
cpu I686_CPU
ident ANONYMOUS
maxusers0
options HZ=100
options INCLUDE_CONFIG_FILE
makeoptions DEBUG=-g
options SCHED_4BSD
options COMPAT_FREEBSD5
options KTRACE
options _KPOSIX_PRIORITY_SCHEDULING
options PREEMPTION
options ADAPTIVE_GIANT
options DDB
options KDB
options KDB_UNATTENDED
options BLKDEV_IOSIZE=8192
options DFLDSIZ=(128UL*1024*1024)
options MAXDSIZ=(1024UL*1024*1024)
options MAXSSIZ=(384UL*1024*1024)
options SYSVSHM
options SHMMAXPGS=4096
options SHMMAX=(SHMMAXPGS*PAGE_SIZE)+1
options SHMALL=(SHMMAXPGS*PAGE_SIZE)+1
options SYSVMSG
options SYSVSEM
options HWPMC_HOOKS
options INET
options INET6
options IPSTEALTH
options TCP_DROP_SYNFIN
options ZERO_COPY_SOCKETS
options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_HTTP
options FFS
options SOFTUPDATES
options UFS_DIRHASH
options CD9660
options PSEUDOFS
options PROCFS
options FDESCFS
options NULLFS
options MD_ROOT
options MAC
options MAC_PARTITION
options MAC_SEEOTHERUIDS
device npx
device apic
device acpi
device pmtimer
device atkbdc
device atkbd
device psm
device vga
device sc
device sio
device speaker
device fdc
device hwpmc
device isa
device pci
device ata
device atadisk
device atapicd
options ATA_STATIC_ID
device scbus
device da
device pass
device atapicam
device cd
device miibus
device fxp
device em
device usb
device uhci
device ohci
device ehci
device uhid
device ukbd
device ums
device umass
device ulpt
device ucom
device uplcom
device md
device loop
device mem
device io
device random
device ether
device vlan
device gif
device gre
device tun
device tap
device disc
device bpf
device pf
device pflog
device pty
device snp
-- and here --
VFS is tuned to
vfs.read_max=16
vfs.ufs.dirhash_mem=1048576
vfs.ufs.dirhash_maxmem=67108864
What else can I do to help narrow down the origin of these crashes ?
--
If it's there, and you can see it, it's
Re: openoffice.org-2.0, portinstall and MAKE_ARGS
On 6/11/06, Vlad GALU [EMAIL PROTECTED] wrote:
On 6/10/06, Andrey Melentyev [EMAIL PROTECTED] wrote:
Hi all!
I've got a problem with building editors/openoffice-2.0 on my FreeBSD-6.1.
I want to control the configure process via knobs, such as WITH_CUPS, WITH_KDE
and some others. When I try to install OOo this way:
portupgrade -Nvm -DWITH_KDE -DWITH_CUPS -DWITH_CCACHE -DWITH_GPC
-DWITHOUT_MOZILLA
editors/openoffice.org-2.0
I see right messages about make flags:
--- Session started at: Sat, 10 Jun 2006 16:34:58 +0400
--- Fresh installation of editors/openoffice.org-2.0 started at: Sat, 10 Jun
2006 16:34:58 +0400
--- Installing 'openoffice.org-2.0.3rc5' from a port
(editors/openoffice.org-2.0)
--- Build of editors/openoffice.org-2.0 started at: Sat, 10 Jun 2006
16:35:03 +0400
--- Building '/usr/ports/editors/openoffice.org-2.0' with make
flags: -DWITH_KDE -DWITH_CUPS -DWITH_CCACHE -DWITH_GPC -DWITHOUT_MOZILLA
But if I put those make flags into /usr/local/etc/pkgtools.conf, then I get no
message about custom make flags, and if I look
at /usr/ports/editors/openoffice.org-2.0/work/config_office/config.log, I see
that my make flags are not working properly.
My pkgtools.conf part:
MAKE_ARGS = {
...
'editors/openoffice.org-2.0' = [
'-DWITH_CUPS',
'-DWITH_KDE',
'LOCALIZED_LANG=ru',
'-DWITH_GPC',
'-DWITH_CCACHE'
],
...
}
FWIW, I spotted the same problem today. portupgrade -N doesn't pick
up the MAKE_ARGS from pkgtools.conf.
FYI, after updating portupgrade to 2.1.2_1,1, everything works correctly.
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openoffice.org-2.0, portinstall and MAKE_ARGS
On 6/10/06, Andrey Melentyev [EMAIL PROTECTED] wrote:
Hi all!
I've got a problem with building editors/openoffice-2.0 on my FreeBSD-6.1.
I want to control the configure process via knobs, such as WITH_CUPS, WITH_KDE
and some others. When I try to install OOo this way:
portupgrade -Nvm -DWITH_KDE -DWITH_CUPS -DWITH_CCACHE -DWITH_GPC
-DWITHOUT_MOZILLA
editors/openoffice.org-2.0
I see right messages about make flags:
--- Session started at: Sat, 10 Jun 2006 16:34:58 +0400
--- Fresh installation of editors/openoffice.org-2.0 started at: Sat, 10 Jun
2006 16:34:58 +0400
--- Installing 'openoffice.org-2.0.3rc5' from a port
(editors/openoffice.org-2.0)
--- Build of editors/openoffice.org-2.0 started at: Sat, 10 Jun 2006
16:35:03 +0400
--- Building '/usr/ports/editors/openoffice.org-2.0' with make
flags: -DWITH_KDE -DWITH_CUPS -DWITH_CCACHE -DWITH_GPC -DWITHOUT_MOZILLA
But if I put those make flags into /usr/local/etc/pkgtools.conf, then I get no
message about custom make flags, and if I look
at /usr/ports/editors/openoffice.org-2.0/work/config_office/config.log, I see
that my make flags are not working properly.
My pkgtools.conf part:
MAKE_ARGS = {
...
'editors/openoffice.org-2.0' = [
'-DWITH_CUPS',
'-DWITH_KDE',
'LOCALIZED_LANG=ru',
'-DWITH_GPC',
'-DWITH_CCACHE'
],
...
}
FWIW, I spotted the same problem today. portupgrade -N doesn't pick
up the MAKE_ARGS from pkgtools.conf.
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
