Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)
Hi Ed,
On Fri, Jun 22, 2018 at 09:11:06PM +0200, Ed Schouten wrote:
E> > Ah, yes! Haven't thought about running syslogd in debugging mode:
E> >
E> > Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]:
INFO […]
E>
E> This is interesting. As fail2ban uses Python's logging framework, I
E> managed to reproduce this with the following script:
E>
E> #!/usr/bin/env python3
E> import logging.handlers
E> logging.basicConfig(handlers=[
E> logging.handlers.SysLogHandler(
E> '/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7)
E> ])
E> logging.warning('Hi')
E>
E> This will write the following message to syslogd:
E>
E> sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0) = 21 (0x15)
E>
E> This message gets rejected by syslogd, due to the change made in
E> r326573, which later got adjusted by me and subsequently MFCed:
E>
E> https://svnweb.freebsd.org/base?view=revision=326573
E>
E> Gleb, what are your thoughts on the attached patch? It alters syslogd
E> to let the 'legacy' RFC 3164 parser also accept messages without a
E> timestamp. The time on the syslogd server will be used instead.
E>
E> Michael, Marek, could you please give this patch a try? Thanks!
I didn't examine the patch thoroughly, but I agree that looks like
we have no other choice as to support the legacy and normal messages
at the same time.
--
Gleb Smirnoff
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: removing SVR4 binary compatibilty layer
On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote: m> Is this removing is because no-interest on maintaining it? m> m> If it helps, I am working to use the `kern_* instead sys_*` as m> mentioned patch in that discussion suggests for svr4, if this helps. Well, we all "maintain" it, meaning that we keep it compilable. However, I'm sure that no one checks the functionality. There are no regression tests, and seems to be no users. I recently found that if you run GENERIC and 'kldload svr4.ko', the socket layer compatibility will be broken, since SVR4 requires COMPAT_OLDSOCK. And that has been for decades, and no one notices that. I bet there are simply no users. Towing this piece of code into the future is just a waste of time. -- Totus tuus, Glebius. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
removing SVR4 binary compatibilty layer
Hello! After some discussion on svn mailing list [1], there is intention to remove SVR4 binary compatibilty layer from FreeBSD head, meaning that FreeBSD 12.0-RELEASE, available in couple of years would be shipped without it. There is no intention of merge of the removal. The stable@ mailing list added for wider audience. P.S. I account any objector as taker of maintainership :) [1] https://lists.freebsd.org/pipermail/svn-src-head/2017-February/096502.html -- Totus tuus, Glebius. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: coredump when loading cxgb after boot with routing daemon already running (RELENG11)
On Sun, Jan 08, 2017 at 04:22:33PM +0300, Andrey V. Elsukov wrote: A> On 04.01.2017 22:07, Navdeep Parhar wrote: A> > What source line in releng-11 does ifioctl+0x6dd correspond to? A> > A> > (kgdb) l *(ifioctl+0x6dd) A> > A> > This might be race where the ifnet is being created or coming up and A> > zebra pokes it in some way before it's fully ready. If that's the A> > case it could affect any ifnet. A> A> Hi, A> A> from a quick look, it seems that ifnet becomes available for any actions A> just after if_alloc() and any strange things can happen in a window A> after if_alloc() and before if_attach(). Am I right? I believe so. That's why in projects/ifnet an interface will be attached by just if_alloc(). -- Totus tuus, Glebius. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Multiple kernels installed when KERNCONF lists more than one kernel configuration file
Trond, On Wed, Jan 06, 2016 at 01:45:39PM +0100, Trond Endrestøl wrote: T> I'm running stable/10, amd64, r293231, and KERNCONF in /etc/src.conf T> lists three kernel configuration files, E5530, GENERIC, and ZFS, in T> that order. T> T> The former is the preferred kernel, while the other two simply exists T> to verify GENERIC and GENERIC + ZFS. T> T> /boot is a symlink to /bootpool/boot, and /bootpool is a 4 GiB UFS, T> yes, that's UFS, not ZFS. T> T> This system uses EFI, and uses the EFI/UFS boot1.efi bootstrap loader T> to load the kernel and its modules from the UFS partition, while T> loader.conf redirects the rootfs to a dataset on the ZFS pool. T> T> Consequently, I have: T> T> /boot/kernel <-- E5530 T> /boot/kernel.GENERIC <-- GENERIC T> /boot/kernel.ZFS <-- ZFS T> T> UPDATING has nothing on the subject, but maybe I'm blind after all. T> T> Is there a way to prevent installing the other kernels, i.e. GENERIC T> and ZFS? T> T> Maybe it's simply a matter of overriding KERNCONF at the command line T> while running make installkernel. My fault. The change I did in head is that "kernels built" == "kernels installed". The naming for alternative kernel directories is the same as in a release build. And looks like everyone was happy with that in head. I assumed the scenario for multiple kernels is possibility to quickly reboot into alternative kernel. Now after your email and chatting with David, I see that another scenaruio is a buildbox that builds kernels for multiple machines, and installs the first one for itself. What I am going to do now is to provide another knob (INSTALLKERNEL probably) that will allow to override behaviour of "kernels built" == "kernels installed". And put it in head. For stable/10 I will restore the original behaviour. -- Totus tuus, Glebius. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Multiple kernels installed when KERNCONF lists more than one kernel configuration file
Trond & David,
can you please test the attached patch. It is against stable/10 and
should restore original behaviour.
--
Totus tuus, Glebius.
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 293275)
+++ Makefile.inc1 (working copy)
@@ -1011,6 +1011,7 @@ KERNCONFDIR?= ${KRNLCONFDIR}
BUILDKERNELS=
INSTALLKERNEL=
+NO_INSTALLEXTRAKERNELS=yes
.for _kernel in ${KERNCONF}
.if exists(${KERNCONFDIR}/${_kernel})
BUILDKERNELS+= ${_kernel}
@@ -1102,7 +1103,7 @@ reinstallkernel reinstallkernel.debug: _installche
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
${CROSSENV} PATH=${TMPPATH} \
${MAKE} ${IMAKE_INSTALL} KERNEL=${INSTKERNNAME} ${.TARGET:S/kernel//}
-.if ${BUILDKERNELS:[#]} > 1
+.if ${BUILDKERNELS:[#]} > 1 && !defined(NO_INSTALLEXTRAKERNELS)
.for _kernel in ${BUILDKERNELS:[2..-1]}
@echo "--"
@echo ">>> Installing kernel ${_kernel}"
@@ -1131,7 +1132,7 @@ distributekernel distributekernel.debug:
sed -e 's|^./kernel|.|' ${DESTDIR}/${DISTDIR}/kernel.premeta > \
${DESTDIR}/${DISTDIR}/kernel.meta
.endif
-.if ${BUILDKERNELS:[#]} > 1
+.if ${BUILDKERNELS:[#]} > 1 && !defined(NO_INSTALLEXTRAKERNELS)
.for _kernel in ${BUILDKERNELS:[2..-1]}
.if defined(NO_ROOT)
echo "#${MTREE_MAGIC}" > ${DESTDIR}/${DISTDIR}/kernel.${_kernel}.premeta
@@ -1155,7 +1156,7 @@ packagekernel:
cd ${DESTDIR}/${DISTDIR}/kernel; \
tar cvf - @${DESTDIR}/${DISTDIR}/kernel.meta | \
${XZ_CMD} > ${DESTDIR}/${DISTDIR}/kernel.txz
-.if ${BUILDKERNELS:[#]} > 1
+.if ${BUILDKERNELS:[#]} > 1 && !defined(NO_INSTALLEXTRAKERNELS)
.for _kernel in ${BUILDKERNELS:[2..-1]}
cd ${DESTDIR}/${DISTDIR}/kernel.${_kernel}; \
tar cvf - @${DESTDIR}/${DISTDIR}/kernel.${_kernel}.meta | \
@@ -1166,7 +1167,7 @@ packagekernel:
cd ${DESTDIR}/${DISTDIR}/kernel; \
tar cvf - . | \
${XZ_CMD} > ${DESTDIR}/${DISTDIR}/kernel.txz
-.if ${BUILDKERNELS:[#]} > 1
+.if ${BUILDKERNELS:[#]} > 1 && !defined(NO_INSTALLEXTRAKERNELS)
.for _kernel in ${BUILDKERNELS:[2..-1]}
cd ${DESTDIR}/${DISTDIR}/kernel.${_kernel}; \
tar cvf - . | \
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
Yonghyeon,
On Thu, Aug 20, 2015 at 11:30:24AM +0900, Yonghyeon PYUN wrote:
YMaybe it can be controlled by some kind of flag, if all the three TSO
Ylimits should include the TCP/IP/ethernet headers too. I'm pretty sure
Ywe want both versions.
Y
Y
YHmm, I'm afraid it's already complex. Drivers have to tell almost
Ythe same information to both bus_dma(9) and network stack.
Y
Y Don't forget that not all drivers in the tree set the TSO limits before
Y if_attach(), so possibly the subtraction of one TSO fragment needs to go
Y into ip_output()
Y
Y Ok, I realized that some drivers may not know the answers before
ether_ifattach(),
Y due to the way they are configured/written (I saw the use of
if_hw_tsomax_update()
Y in the patch).
Y
Y I was not able to find an interface that configures TSO parameters
Y after if_t conversion. I'm under the impression
Y if_hw_tsomax_update() is not designed to use this way. Probably we
Y need a better one?(CCed to Gleb).
Yes. In the projects/ifnet all the TSO stuff is configured differently.
I'd really appreciate if other developers look there and review it,
try it, give some input.
Here is a snippet from net/if.h in projects/ifnet:
/*
* Structure describing TSO properties of an interface. Known both to ifnet
* layer and TCP. Most interfaces point to a static tsomax in ifdriver
* definition. However, vlan(4) and lagg(4) require a dynamic tsomax.
*/
struct iftsomax {
uint32_t tsomax_bytes;/* TSO total burst length limit in bytes */
uint32_t tsomax_segcount; /* TSO maximum segment count */
uint32_t tsomax_segsize; /* TSO maximum segment size in bytes */
};
Now closer to your original question. I haven't yet converted lagg(4), so
haven't yet worked on if_hw_tsomax_update(). I am convinced that it shouldn't
be needed for a regular driver (save lagg(4).
A proper driver should first study its hardware and only then call if_attach().
Correct me if am wrong, please.
Also, I suppose, that a piece of hardware can't change its TSO maximums at
runtime, so I don't see reason for changing them at runtime (save lagg(4)).
--
Totus tuus, Glebius.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pfsync between 8.4 and 9.2
On Wed, Oct 02, 2013 at 12:33:09PM +0100, Pete French wrote: P Just to follow this up for anyuone finding the thread, after upgrading P the other firewall to 9.2 as well, pfsync works fine agai. The failover P actually seems a lot faster in fact, so it looks like a big improvements. Btw, pfsync between 9.x and 10.x is compatible, so provided you have a failover, you are encouraged to try 10-ALPHA4, where pf(4) has got performance improvements comparing to 9.x. More on pf(4) in 10.x: http://www.freebsd.org/news/status/report-2012-10-2012-12.html#SMP-Friendly-pf%284%29 Where to get latest 10.0-ALPHA4 release: http://www.freebsd.org/where.html#helptest -- Totus tuus, Glebius. ___ 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: Flow monitoring with PF
On Thu, Jun 13, 2013 at 10:46:43AM +0930, Daniel O'Connor wrote: D Some software is kind enough to work with either tun or tap as a configurable option. D D Unfortunately I am using ppp which doesn't :( You can use mpd instead of ppp, and mpd can insert ng_netflow node into its PPP graph. -- Totus tuus, Glebius. ___ 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: Possible DoS in mpd 5.6 pppoe server
Marcelo, On Sat, Apr 20, 2013 at 02:26:10PM -0300, Marcelo Gondim wrote: M I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of M 1000 connections using an incorrect login and after a certain time can M cause a kernel panic in the system. Below the panicgenerated: M M http://pastebin.com/nUXGVR3y M You seem to use dummynet and the problem is not in mpd/pppoe code, M it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 M for workarounds. M Ok :) I will try this: M M - net.isr.bindthreads=1 in /boot/loader.conf; M - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf Be advised, that these settings do not fix the problem with dummynet, they just make the race less probable to happen. -- Totus tuus, Glebius. ___ 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: kern/165903: mbuf leak
Chris,
can you please test attached patch?
Jeremy, thanks for cc :)
--
Totus tuus, Glebius.
Index: if_ether.c
===
--- if_ether.c (revision 249327)
+++ if_ether.c (working copy)
@@ -558,13 +558,13 @@ in_arpinput(struct mbuf *m)
if (ah-ar_pln != sizeof(struct in_addr)) {
log(LOG_NOTICE, in_arp: requested protocol length != %zu\n,
sizeof(struct in_addr));
- return;
+ goto drop;
}
if (allow_multicast == 0 ETHER_IS_MULTICAST(ar_sha(ah))) {
log(LOG_NOTICE, arp: %*D is multicast\n,
ifp-if_addrlen, (u_char *)ar_sha(ah), :);
- return;
+ goto drop;
}
op = ntohs(ah-ar_op);
___
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: 9.1-RC3 IGB dropping connections.
On Tue, Nov 27, 2012 at 10:26:55PM -0500, Zaphod Beeblebrox wrote: Z Are you using pf ? Also, did you confirm it is the igb nic and not Z something more general ? e.g. if you put in a different nic, does the Z problem go away ? Z Z No pf, the motherboard em-driver NIC does not have this problem. I'd suggest to do some traffic sniffing when connection is dropped. May be some other host on network takes your IP address and resets connection? -- Totus tuus, Glebius. ___ 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: systutils/arcconf errors on 9.x versions
On Wed, Sep 12, 2012 at 12:02:10PM -0400, David Boyd wrote: D Back in July, this error was discussed briefly on the mailing list(s). D D It appears that a fix (r238182) was submitted for inclusion in 9.1 (early). D D This problem still appears in 9.1-RC1. D D Will the fix be included in 9.1-RELEASE (or better yet 9.1-RC2)? It will. I've merged the fix to both stable/9 and releng/9.1. -- Totus tuus, Glebius. ___ 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: VLAN and ARP table
On Tue, Sep 04, 2012 at 09:18:43AM -0400, Brad Plank wrote: B VLAN interfaces that have a parent interface configured with an IP B address do not show up in the arp table. If the VLAN's parent interface B does not have an IP address, it will show up in the arp table. B [Notice the output from ifconfig below, to duplicate this issue.] B B #ifconfig B em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 B options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM B ether 08:00:27:b7:11:3b B inet 10.20.13.104 netmask 0x broadcast 10.20.255.255 B inet6 fe80::a00:27ff:feb7:113b%em0 prefixlen 64 scopeid 0x1 B inet6 2620:3f:8000:1:d::104 prefixlen 64 B nd6 options=21PERFORMNUD,AUTO_LINKLOCAL B media: Ethernet autoselect (1000baseT full-duplex) B status: active B vlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 B options=3RXCSUM,TXCSUM B ether 08:00:27:b7:11:3b B inet 172.16.200.104 netmask 0xff00 broadcast 172.16.200.255 B nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL B media: Ethernet autoselect (1000baseT full-duplex) B status: active B vlan: 115 parent interface: em0 B B # arp -an B ? (10.20.13.112) at c8:60:00:c3:24:19 on em0 expires in 1182 seconds B [ethernet] B ? (10.20.13.9) at 00:12:3f:20:b9:4c on em0 expires in 1104 seconds B [ethernet] B ? (10.20.13.104) at 08:00:27:b7:11:3b on em0 permanent [ethernet] B ? (10.20.13.110) at 00:90:fb:02:db:e8 on em0 expires in 669 seconds B [ethernet] B ? (10.20.13.109) at 08:00:27:7c:19:d5 on em0 expires in 1199 seconds B [ethernet] B ? (10.20.254.254) at 00:00:5e:00:01:33 on em0 expires in 1179 seconds B [ethernet] Can't reproduce that on 10-current: root@behemoth:~:|ifconfig vlan0 create root@behemoth:~:|ifconfig vlan0 vlan 666 vlandev igb1 10.205.0.1/24 root@behemoth:~:|arp -s 10.205.0.2 0:0:0:0:0:0 root@behemoth:~:|arp -an root@behemoth:~:|arp -an | grep vlan ? (10.205.0.2) at 00:00:00:00:00:00 on vlan0 permanent [vlan] root@behemoth:~:| May it happen that your vlan0 really doesn't have any entries in arp cache? -- Totus tuus, Glebius. ___ 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 on 9.0 and 9.1 with carp on BCE network interface
On Thu, Aug 30, 2012 at 02:39:10PM +, Jean-Luc Dupont wrote: J Sorry, it seems that I didn't put the right backtrace : J J #0 doadump (textdump=Variable textdump is not available. J ) at /usr/src/sys/kern/kern_shutdown.c:271 J 271 dumpsys(dumper); J (kgdb) #0 doadump (textdump=Variable textdump is not available. J ) at /usr/src/sys/kern/kern_shutdown.c:271 J #1 0x807fdf02 in kern_reboot (howto=260) J at /usr/src/sys/kern/kern_shutdown.c:448 J #2 0x807fe3e3 in panic (fmt=0x104 Address 0x104 out of bounds) J at /usr/src/sys/kern/kern_shutdown.c:636 J #3 0x80ad2700 in trap_fatal (frame=0xc, eva=Variable eva is not available. J ) J at /usr/src/sys/amd64/amd64/trap.c:857 J #4 0x80ad2a3d in trap_pfault (frame=0xff82e97a3500, usermode=0) J at /usr/src/sys/amd64/amd64/trap.c:773 J #5 0x80ad305e in trap (frame=0xff82e97a3500) J at /usr/src/sys/amd64/amd64/trap.c:456 J #6 0x80abd67f in calltrap () J at /usr/src/sys/amd64/amd64/exception.S:228 J #7 0x8085f597 in m_copym (m=0x0, off0=1500, len=1480, wait=1) J at /usr/src/sys/kern/uipc_mbuf.c:542 J #8 0x8092f2c8 in ip_fragment (ip=0xfe00970e0580, J m_frag=0xff82e97a3728, mtu=Variable mtu is not available. J ) at /usr/src/sys/netinet/ip_output.c:822 J #9 0x8092fc17 in ip_output (m=0xfe00970e0500, opt=Variable opt is not available. J ) J at /usr/src/sys/netinet/ip_output.c:653 J #10 0x80928713 in ip_forward (m=0xfe00970e0500, srcrt=Variable srcrt is not available. J ) J at /usr/src/sys/netinet/ip_input.c:1494 J #11 0x80929dc8 in ip_input (m=0xfe00970e0500) J at /usr/src/sys/netinet/ip_input.c:702 I don't see that this is CARP related. Do you use any firewall: pf or ipfw? Can you please show the below session in gdb with discussed core file: gdb fr 9 gdb p mtu gdb fr 7 gdb p off gdb fr 8 gdb p m0 gdb p *m0 -- Totus tuus, Glebius. ___ 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: geom mirror now rebuilding on every reboot?
Michael, On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote: M Something in -current and recently MFC'd to -stable is causing all of my M gmirror drives to rebuild on reboot :-( M M Being remote and these being production machines, I suspect SVN r237929 M and r237930 in -current and SVN r238500 to -stable but haven't yet been M able to prove it. I'd appreciate if you test that and either confirm or disclaim that r238500 introduces such regression. Thanks! -- Totus tuus, Glebius. ___ 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: CARP carpdev
On Wed, Feb 15, 2012 at 02:33:43AM +, Bjoern A. Zeeb wrote: B On 02/14/12 17:33, Freddie Cash wrote: B On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silvah...@barafranca.com wrote: B Looks like there's been conversations about porting this to FreeBSD since at B least 2007. B B Are there any plans to have ifconfig carpdev available in 9.0-STABLE? B B CARP support has been redone in 10-CURRENT, removing the whole carp0 B pseudo-interface support, and just enabling the CARP protocol on the B existing network interfaces. This includes the equivalent of carpdev B support. B B Search the -current archives for more information, CFT, and so on. B B I don't recall seeing anything about specific plans to MFC to B stable/9, but could be mis-remembering things. B B B B http://svnweb.freebsd.org/base?view=revisionrevision=228571 B B The single IP limitation may be a problem in some locations.. B B Did not find anything about a possible MFC either. glebius@ is cc'd, perhaps he can add something, but based on http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been MFCd (there's a primer for the new carp in current's UPDATING)\ B B B There's no plans to MFC given it changes things significantly. B B I however wonder if someone wants to provide a user branch in SVN to B provide regular patchsets for stable/9 and maybe even stable/8 (8.3R) B to help people not going to HEAD? If you are hinting at me, I would not :P To get benefits of new carp(4) and updated pf(4) I'm running head in production. What I can do is providing information about exact revisions that I am running. Usually I update a single router, and wait for some time to prove its stability, then roll out a release from that revision and update other routers. -- Totus tuus, Glebius. ___ 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: carp patch - will this ever be in releng_6?
On Sat, May 19, 2007 at 04:35:49PM +0300, Stefan Lambrev wrote: S Bruce M. Simpson wrote: S Stefan Lambrev wrote: S S Are there any chances for this: S http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_carp.c.diff?r1=1.46;r2=1.47 S to be MFCed to RELENG_6 before 6.3-release ? S S It fixes quite annoying bug - destroying carpX (when having at least 2 S carp interfaces) will panic immediately. S This bugfix is from 3+ months ago. S S Sadly it is unlikely the failure condition you describe will be fixed in S -STABLE, as resolving it requires far more work to be merged than the link S to the diff you post above. S The attached patch worked for me - it is based on the posted URL. S At least I didn't notice bad effects and it fixes the bug. Bruce misinformes you ;) I've just merged the patch. Thanks for reminder. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld: make: don't know how to make ng_deflate.4
On Sun, Jan 28, 2007 at 11:40:49PM +0100, Lars Stokholm wrote: L Result of 'make buildworld': L L gzip -cn /usr/src/share/man/man4/ng_cisco.4 ng_cisco.4.gz L make: don't know how to make ng_deflate.4. Stop L *** Error code 2 My fault. I have just fixed this. I'm sorry :( -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CARP + VLAN = kernel dump
On Thu, Dec 14, 2006 at 07:05:04PM -0800, Ask Bj?rn Hansen wrote: A Hi, A A If I enable carp on a vlan interface in rc.conf the kernel goes A boom. This is 6.2-RC from a couple of weeks ago. (IIRC then I had A the same problem setting up carp on a bridge'd interface). A A I'm configuring it like this: A A ifconfig_vlan2=inet 10.50.0.3/24 vlan 202 vlandev sis2 A ifconfig_carp2=vhid 3 advskew 200 pass awe4jkfha4jkfha4f 10.50.0.1 A A cloned_interfaces=... carp2 ... vlan2 A A However, if I do the carp2 setup manually after the system is A booted, it is working fine. A A ifconfig carp2 vhid 3 advskew 200 pass hjarefhakjewfha 10.50.0.1 A A Any ideas? A A (kernel dump below) A A - ask A A A fault virtual address = 0x15c A fault code = supervisor read, page not present A instruction pointer = 0x20:0xc05ba533 A stack pointer = 0x28:0xc7975c30 A frame pointer = 0x28:0xc7975c90 A code segment= base 0x0, limit 0xf, type 0x1b A = DPL 0, pres 1, def32 1, gran 1 A processor eflags= interrupt enabled, resume, IOPL = 0 A current process = 13 (swi1: net) A trap number = 12 A panic: page fault A Uptime: 17s A Cannot dump. No dump device defined. Can you please configure dump device, obtain kernel dump, and print the backtrace from it? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
Jack, On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: J Since this was just seen, and the patch below validated as working I J wanted J to send general email to capture this: J J The Lenovo X60 can have issues with long ping times, this is a KNOWN J hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has J not been decided on yet. Nevertheless, the patch below will work, but J I do not want to check it in as its still temporary. J J Address questions to me, J J Okay, I have a question. Could you elaborate on just what the problem is? J (I mean, since it's KNOWN and all...) I'm just having a hard time figuring J out what problem could possibly be fixed by setting the RX interrupt J delay timer to a non-zero value (especially since elsewhere in the em(4) J source it says that doing so is a Bad Thing (tm)). J J saying its known to be a problem doesnt mean its cause is known :) J They discovered that setting this eliminated the problem, but we J immediately pointed out that this is, as you pointed out, a Bad J Thing on other hardware, so the investigation continues, there is J always a communication lag on these kind of things, so I dont know J if it has been resolved yet or not. J J I just dont think this patch will become the final way to solve this, J but we shall see :) Good to know that there is progress on this. Thanks! I will try the patch on my Lenovo T60 notebook, where the problem is also present. AFAIK, it is present on any Lenovo notebook with 82573 NIC. Can you please acknowledge that another bug with Lenovo + em(4) is known? I mean the problem, that em(4) isn't initialized properly on kernel boot, if the link is down. I have already reported this to you, and you said that I probably have bad hardware. Since that time, I've found several similar reports about Lenovo notebooks and em(4) driver in FreeBSD. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge Ierr rate increase from 5.3R - 6.1R
D Greg Eden wrote: D Hello D D I recently updated two production servers from 5.3 to 6.1 via D cvsup and D buildworld. Since the upgrade I've seen an increase in the number of D Input packet errors reported on the bge cards in on both boxes. In 5.3-RELEASE the bge(4) driver did not read the error count from the chip at all. So errors were not accounted. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ 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 panic under heavy load
I wonder why UMA was suspected to be the problem. Dima gave
me access to the core. Here are more details from the trace:
Unread portion of the kernel message buffer:
panic: thread 100147(nagios):1 holds process lock but isn't blocked on a lock
#9 0xd060038e in panic (fmt=0xd08094d9 thread %d(%s):%d holds %s but isn't
blocked on a lock\n) at /usr/src/sys/kern/kern_shutdown.c:549
#10 0xd0629228 in propagate_priority (td=0xd745c900) at
/usr/src/sys/kern/subr_turnstile.c:239
#11 0xd0629f32 in turnstile_wait (lock=0xd5dd5498, owner=0xd745c900) at
/usr/src/sys/kern/subr_turnstile.c:643
#12 0xd05f4fc1 in _mtx_lock_sleep (m=0xd5dd5498, tid=3583683968, opts=0,
file=0x12 Address 0x12 out of bounds, line=18) at
/usr/src/sys/kern/kern_mutex.c:579
#13 0xd05f4992 in _mtx_lock_flags (m=0xd5dd5498, opts=0, file=0xd0806c3d
/usr/src/sys/kern/kern_thread.c, line=824) at
/usr/src/sys/kern/kern_mutex.c:288
#14 0xd060d340 in thread_single (mode=0) at /usr/src/sys/kern/kern_thread.c:824
#15 0xd05e38b9 in fork1 (td=0xd59aad80, flags=20, pages=0, procp=0xf5ca) at
/usr/src/sys/kern/kern_fork.c:274
#16 0xd05e3509 in fork (td=0xd59aad80, uap=0xf5cacd04) at
/usr/src/sys/kern/kern_fork.c:98
#17 0xd07a6d10 in syscall (frame=
{tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134953856,
tf_esi = 673312612, tf_ebp = -809526568, tf_isp = -171258524, tf_ebx =
672261300, tf_edx = 0, tf_ecx = 134963456, tf_eax = 2, tf_trapno = 12, tf_err =
2, tf_eip = 672684403, tf_cs = 51, tf_eflags = 642, tf_esp = -809526660, tf_ss
= 59})
at /usr/src/sys/i386/i386/trap.c:983
#18 0xd078f38f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#19 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 10
#10 0xd0629228 in propagate_priority (td=0xd745c900) at
/usr/src/sys/kern/subr_turnstile.c:239
239 KASSERT(TD_ON_LOCK(td), (
(kgdb) list
234 #endif
235
236 /*
237 * If we aren't blocked on a lock, we should be.
238 */
239 KASSERT(TD_ON_LOCK(td), (
240 thread %d(%s):%d holds %s but isn't blocked on a
lock\n,
241 td-td_tid, td-td_proc-p_comm, td-td_state,
242 ts-ts_lockobj-lo_name));
243
(kgdb) frame 14
#14 0xd060d340 in thread_single (mode=0) at /usr/src/sys/kern/kern_thread.c:824
824 PROC_LOCK(p);
(kgdb) list
819 thread_stopped(p);
820 thread_suspend_one(td);
821 PROC_UNLOCK(p);
822 mi_switch(SW_VOL, NULL);
823 mtx_unlock_spin(sched_lock);
824 PROC_LOCK(p);
825 mtx_lock_spin(sched_lock);
826 if (mode == SINGLE_EXIT)
827 remaining = p-p_numthreads;
828 else if (mode == SINGLE_BOUNDARY)
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
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 panic under heavy load
On Thu, Nov 16, 2006 at 01:24:36PM +0300, Gleb Smirnoff wrote:
T I wonder why UMA was suspected to be the problem. Dima gave
T me access to the core. Here are more details from the trace:
It looks like a race between two threads in one process. Look here:
(kgdb) frame 12
#12 0xd05f4fc1 in _mtx_lock_sleep (m=0xd5dd5498, tid=3583683968, opts=0,
file=0x12 Address 0x12 out of bounds, line=18) at
/usr/src/sys/kern/kern_mutex.c:579
579 turnstile_wait(m-mtx_object, mtx_owner(m));
(kgdb) p *m
$10 = {mtx_object = {lo_class = 0xd084e224, lo_name = 0xd080508c process
lock, lo_type = 0xd080508c process lock, lo_flags = 4390912, lo_list = {
tqe_next = 0xd5dd56b0, tqe_prev = 0xd5dd5290}, lo_witness = 0xd088a100},
mtx_lock = 3611674882, mtx_recurse = 0}
(kgdb) p ((struct thread *)tid)
$15 = (struct thread *) 0xd59aad80
(kgdb) p ((struct thread *)(m-mtx_lock ~(0x1 | 0x2)))
$17 = (struct thread *) 0xd745c900
(kgdb) p ((struct thread *)(m-mtx_lock ~(0x1 | 0x2)))-td_proc
$18 = (struct proc *) 0xd5dd5430
(kgdb) p ((struct thread *)tid)-td_proc
$19 = (struct proc *) 0xd5dd5430
So, we see that one thread blocks on the lock that is held by an
other thread of the same process. Here they are:
* 134 Thread 100198 (PID=47872: nagios) doadump () at pcpu.h:165
133 Thread 100147 (PID=47872: nagios) sched_switch (td=0xd745c900,
newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980
Let's look at the second one:
(kgdb) thread 133
[Switching to thread 133 (Thread 100147)]#0 sched_switch (td=0xd745c900,
newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980
980 sched_lock.mtx_lock = (uintptr_t)td;
(kgdb) bt
#0 sched_switch (td=0xd745c900, newtd=0xd51f7a80, flags=2) at
/usr/src/sys/kern/sched_4bsd.c:980
#1 0xd0607f46 in mi_switch (flags=2, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:420
#2 0xd0615ecf in maybe_preempt_in_ksegrp (td=0xd59aad80) at kern_switch.c:467
#3 0xd06160c8 in setrunqueue (td=0xd59aad80, flags=0) at kern_switch.c:585
#4 0xd06151e7 in sched_wakeup (td=0xd59aad80) at
/usr/src/sys/kern/sched_4bsd.c:996
#5 0xd0608025 in setrunnable (td=0xd59aad80) at
/usr/src/sys/kern/kern_synch.c:483
#6 0xd060d78e in thread_unsuspend_one (td=0xd59aad80) at
/usr/src/sys/kern/kern_thread.c:972
#7 0xd060d584 in thread_suspend_check (return_instead=0) at
/usr/src/sys/kern/kern_thread.c:935
#8 0xd0628a88 in userret (td=0xd745c900, frame=0xf5dd4d38, oticks=1) at
/usr/src/sys/kern/subr_trap.c:116
#9 0xd07a6e16 in syscall (frame=
{tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134997504,
tf_esi = 134998528, tf_ebp = -813707944, tf_isp = -170046108, tf_ebx =
672261300, tf_edx = 0, tf_ecx = 134969072, tf_eax = 1, tf_trapno = 0, tf_err =
2, tf_eip = 672832335, tf_cs = 51, tf_eflags = 646, tf_esp = -813707972, tf_ss
= 59})
at /usr/src/sys/i386/i386/trap.c:1034
#10 0xd078f38f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
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 panic under heavy load
On Thu, Nov 16, 2006 at 02:15:25PM +0300, Gleb Smirnoff wrote:
T On Thu, Nov 16, 2006 at 01:24:36PM +0300, Gleb Smirnoff wrote:
T T I wonder why UMA was suspected to be the problem. Dima gave
T T me access to the core. Here are more details from the trace:
And even more:
(kgdb) thread 133
[Switching to thread 133 (Thread 100147)]#0 sched_switch (td=0xd745c900,
newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980
980 sched_lock.mtx_lock = (uintptr_t)td;
(kgdb) frame 9
#9 0xd07a6e16 in syscall (frame=
{tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134997504,
tf_esi = 134998528, tf_ebp = -813707944, tf_isp = -170046108, tf_ebx =
672261300, tf_edx = 0, tf_ecx = 134969072, tf_eax = 1, tf_trapno = 0, tf_err =
2, tf_eip = 672832335, tf_cs = 51, tf_eflags = 646, tf_esp = -813707972, tf_ss
= 59})
at /usr/src/sys/i386/i386/trap.c:1034
1034userret(td, frame, sticks);
(kgdb) p *callp
$92 = {sy_narg = 65539, sy_call = 0xd0630550 poll, sy_auevent = 43012}
(kgdb) set $poll = (struct thread *)0xd745c900
(kgdb) set $fork = (struct thread *)0xd59aad80
(kgdb) p $poll-td_state
$93 = TDS_INHIBITED
(kgdb) p $poll-td_inhibitors
$94 = 1 == TDI_SUSPENDED
(kgdb) p/x $poll-td_flags
$96 = 0x1010c01 == TDF_BORROWING | TDF_BOUNDARY | TDF_ASTPENDING |
TDF_NEEDRESCHED | TDF_SCHED0
(kgdb) p $fork-td_state
$97 = TDS_INHIBITED
(kgdb) p $fork-td_inhibitors
$98 = 8 == TDI_LOCK
(kgdb) p/x $fork-td_flags
$99 = 0x100 == TDF_SCHED0
Not everything clear yet, but looks like:
1) $fork thread obtains proc lock
2) $poll thread blocks on proc lock
3) $fork thread has suspended the $poll thread in thread_single()
4) $fork thread temporarily unlocks proc lock (line 821) and is
preempted by $poll thread
5) $poll thread obtains proc lock, and starts doing its poll job
6) $fork thread blocks on proc lock, and is added to its turnstile
7) $poll thread drops the proc lock, but isn't preempted by $fork
8) $poll thread exits and is preempted by $fork
...) and here is something difficult to understand, when $poll tries to
make $fork runnable, while $fork is trying to put itself in the turnstile
that is owned by $poll
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EM stability
On Sun, Nov 12, 2006 at 02:26:36PM -0600, Barry Boes wrote: B After the last hang I added giant locks back in and the machine has B been up since. B B I don't have a serial console, just a graphic console. When the B machine hangs it stops replying to ethernet packets at all protocol B levels and doesn't respond to keyboard input in any way, virtual B console or otherwise. If I run a script of the form Bwhile(1) B sleep 1 B date datelog Bend B B the file stops updating when the machine hangs. B B I will define the debugger in the kernel (options DDB, right?), attach B a serial console, and do what I can to get more information on the B problem. Yes, this looks like something is running in an endless loop. Once you compile kernel with debugger, you should enter in several times and see the backtraces. Usually, they will be inside this cycle. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EM stability
Hello Barry, On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: BI see you listed on the EM stability issues list. I have a Tyan B H1000S with dual em ports on 6.1, and it won't stay up 5 minutes B without EM watchdog resets unless I use giant locks. BIs there any way you'd like me to help you with testing the updated B drivers? Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new kernel and report whether the problem is fixed or not. You see, I have added a o lot of people and two mailing lists to Cc. Please do not remove them, when replying. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EM stability
On Fri, Nov 10, 2006 at 04:28:30PM -0600, Barry Boes wrote: B B Luck ran out. Hard must press the reset button hang. No console B messages. The system was idle at the time. BIs there anything you'd like me to do to attempt to narrow down the B problem or get debugging output? I do not know if the freeze was B related to em or something else. In cases like this you need to prepare a kernel with debugger compiled in and try to exit into the debugger, when the hang occurs. You can try keyboard debugger sequence, and if it fails try serial break. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: J The engineer in our test group has installed 6.2 BETA2 and attempted via a J number of tests to reproduce this problem, the machine even shares the em J interrupt with usb, and yet so far he has been unsuccessful. I've failed to reproduce on a system where IRQ was shared between em(4) and fxp(4). I've put traffic on both, but failed to reproduce. Probably shared IRQ is required, but not sufficient. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On Thu, Oct 19, 2006 at 12:18:16PM -0700, Jeremy Chadwick wrote: J A bit more helpfull, but unfortunately not much is a datapoint saying no J problems April 3rd and watchdog timeouts after September 28 RELENG_6. I J know, probably too vague to be of any use, but there it is. J J Someone else has already discussed the date of the commit which J supposedly broke this. Here is the exact post in the exact thread J discussing this: J J http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029094.html Yes, this merge was awesome in its volume. However, it is suspected that this part of merge causes the problem: o a significant performance improvements. the interrupt handler schedules work to a private taskqueue. the em_rxeof() function runs lockless. rev. 1.98 - 1.101 by scottl. To check whether this is true or not, one needs to build kernel with em(4) static in the kernel and with DEVICE_POLLING option. One shouldn't turn polling(4) on em(4), but option must be present in kernel config. In this case the driver will use interrupt driven module, but with old style interrupt handler, that doesn't make use of taskqueue. I'd appreciate if people who are observing the problem will report whether adding DEVICE_POLLING option to kernel config helps them or not. This will help to tell whether the problem is in the above quote or in the import of new versions from vendor. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On Sat, Oct 21, 2006 at 12:57:52PM -0400, Kris Kennaway wrote: K On Sat, Oct 21, 2006 at 10:17:06AM +0400, Gleb Smirnoff wrote: K On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: K J The engineer in our test group has installed 6.2 BETA2 and attempted via a K J number of tests to reproduce this problem, the machine even shares the em K J interrupt with usb, and yet so far he has been unsuccessful. K K I've failed to reproduce on a system where IRQ was shared between em(4) K and fxp(4). I've put traffic on both, but failed to reproduce. Probably K shared IRQ is required, but not sufficient. K K Note what I've said a couple of times now...blasting packets out over K the shared em doesn't trigger it for me either. I can trigger it by K fetching via FTP from a remote machine over the em. I suppose the TCP_STREAM test from the netperf is the same as ftp fetch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On Sat, Oct 21, 2006 at 01:00:08PM -0400, Mikhail Teterin wrote: M = I'd appreciate if people who are observing the problem will report M = whether adding DEVICE_POLLING option to kernel config helps them M = or not. This will help to tell whether the problem is in the above M = quote or in the import of new versions from vendor. M M I tried this yesterday -- before writing to [EMAIL PROTECTED] I saw the system component M of the total load being rather high and then enabled polling. M M Again, I did not wait long enough to check, whether the system will cease M communicating completely before enabling polling on em, but the system load M was shooting way up upon starting my backup procedure even when I switched to M DEVICE_POLLING-using kernel. We aren't currently speaking about performance, we need to know whether kernel with DEVICE_POLLING option makes NIC work stable. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:56:21AM -0400, Ernest Natiello wrote:
E here we go:
E
E (kgdb) frame 7
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E 1184INP_LOCK(inp);
E (kgdb) p *sopt
E $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
E 0x0,
E sopt_valsize = 0, sopt_td = 0xc73add80}
Not clear to me what IP option is it trying to set... sopt_valsize is 0.
Which port/package/software does tcpserver program belong to?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, Oct 13, 2006 at 10:50:43AM -0400, Ernest Natiello wrote: E On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: E Gentlemen, sorry I interrupt you. What version of FreeBSD is that? E If it something RELENG_6 you should consider to upgrade to it. I E believe this panic was fixed by rwatson. E E Do you have a date as to when this was patch was committed? One of the E boxes undergoing the issue was cvsup'd and build as of Oct 4th. AFAIK, Robert made this panic less probable to happen in RELENG_6, but didn't eliminated it completely. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Wed, Oct 11, 2006 at 03:43:07PM -0400, Ernest Natiello wrote:
E Hello,
E I have 4 HP Proliant DL360's (1u) which panic/reboot often (minimum
E 1x month), but in a seemingly inconsistent manner. As per other
E suggestions, ipf was replaced with pf, an Intel pro 100 was added, the
E BGE device was disabled in the BIOS and the BGE driver was removed from
E the kernel. Also, Lights Out Management was disabled.
E None of the suggestions have cleared up the issue, so the BGE
E driver was added back to the kernel after reading the most recent
E developments in the posting:
This is a known problem. It is fixed in HEAD, but unfortunately it
isn't mergeable to RELENG_6. The problem isn't related to either pf,
ipf or NIC drivers.
What I'd suggest you to do is to workaround the problem removing
the problematic syscall from the userland program, that causes kernel
to trap.
I guess it is setsockopt(sock, IPPROTO_IP, ...). In some cases, for
example IP_TOS setting the syscall can be safely removed from the source code,
w/o affecting operability of the software.
Let's look what is the socket option, in gdb:
frame 7
p *sopt
And let's look the name of the process:
frame 11
p td-td_proc-p_comm
E -begin crash dump-
E (kgdb) where
E #0 doadump () at pcpu.h:165
E #1 0xc0682aaa in boot (howto=260)
E at /usr/src/sys/kern/kern_shutdown.c:409
E #2 0xc0682dd1 in panic (fmt=0xc088273f %s)
E at /usr/src/sys/kern/kern_shutdown.c:565
E #3 0xc0837de0 in trap_fatal (frame=0xe9226ab0, eva=260)
E at /usr/src/sys/i386/i386/trap.c:837
E #4 0xc0837596 in trap (frame=
E {tf_fs = -858718200, tf_es = 463994920, tf_ds = -383647704, tf_edi
E = -952443520, tf_esi = 4, tf_ebp = -383620356, tf_isp = -383620388,
E tf_ebx = -927947756, tf_edx = 6, tf_ecx = 0, tf_eax = 1, tf_trapno = 12,
E tf_err = 0, tf_eip = -1066951471, tf_cs = 32, tf_eflags = 65538, tf_esp
E = -383619952, tf_ss = -927947900}) at /usr/src/sys/i386/i386/trap.c:270
E #5 0xc08242ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
E #6 0xc0679cd1 in _mtx_lock_sleep (m=0xc8b0a414, tid=3342523776, opts=0,
E file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E #8 0xc072fe07 in tcp_ctloutput (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/netinet/tcp_usrreq.c:1038
E #9 0xc06bea50 in sosetopt (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/kern/uipc_socket.c:1563
E #10 0xc06c3dc5 in kern_setsockopt (td=0xc73add80, s=0, level=1, name=1,
E val=0x0, valseg=UIO_USERSPACE, valsize=6)
E at /usr/src/sys/kern/uipc_syscalls.c:1351
E #11 0xc06c3ce6 in setsockopt (td=0xc73add80, uap=0x1)
E at /usr/src/sys/kern/uipc_syscalls.c:1307
E #12 0xc0838127 in syscall (frame=
E {tf_fs = -65477, tf_es = 65595, tf_ds = -1078001605, tf_edi = 1,
E tf_esi = 0, tf_ebp = -1077941176, tf_isp = -383619740, tf_ebx = 0,
E tf_edx = 0, tf_ecx = 0, tf_eax = 105, tf_trapno = 12, tf_err = 2, tf_eip
E = 672093283, tf_cs = 51, tf_eflags = 642, tf_esp = -1077941220, tf_ss =
E 59})
E at /usr/src/sys/i386/i386/trap.c:983
E #13 0xc082433f in Xint0x80_syscall ()
E at /usr/src/sys/i386/i386/exception.s:200
E #14 0x0033 in ?? ()
E Previous frame inner to this frame (corrupt stack?)
E (kgdb)
E #0 doadump () at pcpu.h:165
E #1 0xc0682aaa in boot (howto=260)
E at /usr/src/sys/kern/kern_shutdown.c:409
E #2 0xc0682dd1 in panic (fmt=0xc088273f %s)
E at /usr/src/sys/kern/kern_shutdown.c:565
E #3 0xc0837de0 in trap_fatal (frame=0xe9226ab0, eva=260)
E at /usr/src/sys/i386/i386/trap.c:837
E #4 0xc0837596 in trap (frame=
E {tf_fs = -858718200, tf_es = 463994920, tf_ds = -383647704, tf_edi
E = -952443520, tf_esi = 4, tf_ebp = -383620356, tf_isp = -383620388,
E tf_ebx = -927947756, tf_edx = 6, tf_ecx = 0, tf_eax = 1, tf_trapno = 12,
E tf_err = 0, tf_eip = -1066951471, tf_cs = 32, tf_eflags = 65538, tf_esp
E = -383619952, tf_ss = -927947900}) at /usr/src/sys/i386/i386/trap.c:270
E #5 0xc08242ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
E #6 0xc0679cd1 in _mtx_lock_sleep (m=0xc8b0a414, tid=3342523776, opts=0,
E file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E #8 0xc072fe07 in tcp_ctloutput (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/netinet/tcp_usrreq.c:1038
E #9 0xc06bea50 in sosetopt (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/kern/uipc_socket.c:1563
E #10 0xc06c3dc5 in kern_setsockopt (td=0xc73add80, s=0, level=1, name=1,
E val=0x0, valseg=UIO_USERSPACE, valsize=6)
E at /usr/src/sys/kern/uipc_syscalls.c:1351
E #11 0xc06c3ce6 in setsockopt (td=0xc73add80, uap=0x1)
E at /usr/src/sys/kern/uipc_syscalls.c:1307
E #12 0xc0838127 in syscall (frame=
E {tf_fs = -65477, tf_es = 65595, tf_ds = -1078001605, tf_edi = 1,
E tf_esi = 0, tf_ebp = -1077941176,
Re: bce issues still outstanding
Kevin, On Wed, Oct 11, 2006 at 11:21:27AM -0500, Kevin Kramer wrote: K here is a picture of a panic i get on a Dell Precision 390 booting K 6.2-beta2_amd64. hope this helps. K K http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg Well, although the message above is about bge(4) identified, the panic says that the CPU received NMI due to RAM parity error. Have you tried replacing the RAM? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:03:36AM +0100, Pete French wrote: P This is a known problem. It is fixed in HEAD, but unfortunately it P isn't mergeable to RELENG_6. The problem isn't related to either pf, P ipf or NIC drivers. P P This is a little alarming - because what you seem to be saying is that P if you have DL360's then you need to either run current, or accept that P they will panic every so often for as long as you are running RELENG_6. P We are looking to change our hardware soon, and DL360's were top of the P list for replacements! Again, this has nothing to do with hardware. It is general problem in RELENG_6. P Is there a PR reference for this describing the solution to the problem P in HEAD somewhere that I could take a look at ? The problem wasn't fixed with a single commit. Maybe Robert, who is carbon copied, can provide more details. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:18:03AM -0400, Ernest Natiello wrote: E Hello, E Thank you very much for all of the help. I am trying to understand E this issue, as it has been plaguing me for quite some time. E So, extrapolating from the below kgdb output, am I to assume that E the process causing the error is tcpserver? Probably it is. However, can you run the gdb commands I mentioned in previous post, to make us sure. E And should I further infer E that tcpserver would cause this issue on all instances of FreeBSD E RELENG_6, regardless of hardware? I think so. A tcpserver(8) in given configuration. E I have three other servers HP Proliant DL380s (2u) which are E operating in a _similar_ capacity, (incoming vs. outgoing mailservers) E running the exact same software, which have never had a problem. E These three servers are running: FreeBSD unix29 6.1-PRERELEASE E FreeBSD 6.1-PRERELEASE #0: Mon Mar 27 10:42:56 EST 2006 E [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX34 i386 E The operating system on this machine was rsync'd from one of the E servers that is having the panic issue, yet it continues to operate E flawlessly. The discussed problem is a race between remote client closing TCP connection (may be resetting?), and local software performing setsockopt() system call on the same socket. It may happen that this particulat server has to deal with clients that drop the connection randomly, and other servers don't. That's why other servers are stable. E I guess I could try swapping the services between two of the E servers and see if the behavior follows the move. Does that sound E viable? You can try it. And don't forget to run gdb commands, and see what is the actual socket option that causes the problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge watchdog timeouts still happening
On Mon, Sep 11, 2006 at 02:17:22AM +0200, Herve Boulouis wrote: H Hi, H H I've recently put into production 2 web servers with 6.0-STABLE from H mid january and was bitten by the bge watchdog timeouts problems. H H I cvsupped the 2 boxes with the latest -stable (latest if_bge.c, H rev 1.91.2.17) but the problem still persists :( H H Server hardware is Dell poweredge 2550 with SMP kernel. H H Relevant portion of dmesg : H H bge0: Broadcom BCM5700 B2, ASIC rev. 0x7102 mem 0xfeb0-0xfeb0 irq 17 at device 8.0 on pci1 H miibus0: MII bus on bge0 H brgphy0: BCM5401 10/100/1000baseTX PHY on miibus0 H brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto H bge0: Ethernet address: 00:06:5b:1a:7f:4a Is it integrated or not? I've got exactly the same NIC and I can try to reproduce the problem if you describe the workload. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em watchdog timeout on UP, 6-stable
Barney, On Tue, Sep 05, 2006 at 02:33:52PM -0400, Barney Wolff wrote: B Updated my Athlon-xp 6-stable system last night, got an em watchdog B timeout for the first time a few hours later, during a fairly B high-traffic period. System is UP but does have device apic in B the config. Any chance this is the recent race condition? B Workaround? ifconfig em0 down, ifconfig em0 up seemed to cure it, B at least for the moment. Not clear from your mail whether interface was working after the event occured. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Pyun,
On Wed, Aug 30, 2006 at 04:30:25PM +0900, Pyun YongHyeon wrote:
P ===
P RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
P retrieving revision 1.91.2.16
P diff -u -r1.91.2.16 if_bge.c
P --- if_bge.c 10 Aug 2006 11:02:14 - 1.91.2.16
P +++ if_bge.c 30 Aug 2006 07:20:43 -
P @@ -1007,9 +1007,26 @@
P /* Set up the PCI DMA control register. */
P if (sc-bge_pcie) {
P /* PCI Express bus */
P -dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
P -(0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
P -(0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
P +uint32_t device_ctl;
P +
P +/* alternative from Linux driver */
P +#define DMA_CTRL_WRITE_PCIE_H20MARK_128 0x0018
P +#define DMA_CTRL_WRITE_PCIE_H20MARK_256 0x0038
P +
P +dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
P +device_ctl = pci_read_config(sc-bge_dev,
P +BGE_PCI_CONF_DEV_CTRL, 4);
P +if ((device_ctl 0x00e0) 0) {
P +/*
P + * This clause is exactly what the Broadcom-supplied
P + * Linux does; but given overall register programming
P + * by bge(4), this larger DMA-write watermark
P + * value causes BCM5721 chips to totally wedge.
P + */
P +dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
P +} else {
P +dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
P +}
P } else if (sc-bge_pcix) {
My small penny into the discussion. I was working on reviewing the
difference in initializing the PCI DMA control register in Linux tg3.c
and in bge(4).
I was quite lost in this stuff, and so I asked for help from David
Christensen (davidch@). He has explained me all the differencies
in this register between chips and I have prepared the attached patch.
Since I have very small collection of bge(4) cards, I avoid to commit
it. May be I will commit it after 6.2-RELEASE if several people test it
on their cards and all is OK. And it will live unmerged in HEAD until
6.3-RELEASE.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.139
diff -u -p -r1.139 if_bge.c
--- if_bge.c23 Aug 2006 11:32:54 - 1.139
+++ if_bge.c23 Aug 2006 15:18:22 -
@@ -1005,36 +1005,48 @@ bge_chipinit(struct bge_softc *sc)
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc-bge_flags BGE_FLAG_PCIE) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+* DMA read watermark not used on PCI-E.
+* DMA write watermark set to 128 bytes.
+*/
+ dma_rw_ctl |= (3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc-bge_flags BGE_FLAG_PCIX) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl = ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc-bge_asicrev == BGE_ASICREV_BCM5780)
- dma_rw_ctl |= (1 20) | (1 18) |
- BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
- dma_rw_ctl |= (1 20) | (1 18) | (1 15);
-
- } else if (sc-bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc-bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE_LOCAL;
+ break;
+
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Ganbold,
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
G Thanks a lot for your patch. Your patch fixes panic, however I still see
G bge0: firmware handshake timed out
G bge0: link state changed to DOWN
G messages.
And yesterday delphij@ have sent me patch against firmware handshake timed
out.
It is attached. Can you please test it?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
---BeginMessage---
Hi,
A colleague of mine has found that BCM 5752 A02 would get firmware
handshake timeout problem during the ifconfig stage. After some
investigation and comparing to the Linux driver I have the attached
patch make the problem disappear. Unfortunately I do not have
specification documentation from Broadcom so I can not say if that is a
real fix :-(
The patch was tested on Dell Latitude D820. The only problem remains is
that the -CURRENT kernel crashes if I did not explicitly set the media
and do a ifconfig bge0 up, with panic: invalid ife-ifm_data (0xa) in
mii_phy_setmedia. Backtrace is available upon request.
Cheers,
--
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.140
diff -u -r1.140 if_bge.c
--- if_bge.c24 Aug 2006 14:41:16 - 1.140
+++ if_bge.c29 Aug 2006 06:20:44 -
@@ -2313,6 +2313,13 @@
BGE_PCIMISCCTL_INDIRECT_ACCESS|BGE_PCIMISCCTL_MASK_PCI_INTR|
BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_PCISTATE_RW, 4);
+ /* XXX: Broadcom Linux driver. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5752 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5755 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5787) {
+ CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0);
+ }
+
reset = BGE_MISCCFG_RESET_CORE_CLOCKS|(651);
/* XXX: Broadcom Linux driver. */
Index: if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.52
diff -u -r1.52 if_bgereg.h
--- if_bgereg.h 23 Aug 2006 11:32:54 - 1.52
+++ if_bgereg.h 29 Aug 2006 06:32:31 -
@@ -1656,6 +1656,7 @@
#define BGE_EE_CTL 0x6840
#define BGE_MDI_CTL0x6844
#define BGE_EE_DELAY 0x6848
+#define BGE_FASTBOOT_PC0x6894
/* Mode control register */
#define BGE_MODECTL_INT_SNDCOAL_ONLY 0x0001
signature.asc
Description: OpenPGP digital signature
---End Message---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 05:22:23PM +0900, Ganbold wrote: G On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote: G G Thanks a lot for your patch. Your patch fixes panic, however I still see G G bge0: firmware handshake timed out G G bge0: link state changed to DOWN G G messages. G G And yesterday delphij@ have sent me patch against firmware handshake G timed out. G It is attached. Can you please test it? G G G Applied delphij@'s patch and now bge0: firmware handshake timed out G message is gone. Previously there was applied Pyun's brgphy(4) patch. Good. We probably need to commit them both soon. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
On Wed, Aug 30, 2006 at 05:26:07PM +0900, Ganbold wrote: G Gleb, Pyun, G G I'm a kind of bit confused here whose patch to choose. G Can you guys enlighten me in this regard? Can you please merge them? You should take all the stuff that prepares the dma_rw_ctl variable from my patch, and all the other stuff from Pyun's patch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fresh em(4) patch for RELENG_6 available
Colleagues, although one week ago we have made a very big merge of the em(4) driver from HEAD to RELENG_6, during this week the driver has experienced few important changes in HEAD: 1) Pyun YongHyeon has fixed problems in both TX and RX path that can happen when system experiences mbuf shortage. 2) Intel's driver version 6.1.4 has been merged. The patch for RELENG_6 is available here: http://people.freebsd.org/~glebius/em-RELENG_6.patch Currently there is also a known problem - a race condition, that occurs on SMP triggering a fake watchdog event, that leads to unwanted NIC reset. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fresh em(4) patch for RELENG_6 available
On Mon, Aug 14, 2006 at 08:12:21AM -0400, Mike Tancsa wrote: M At 06:45 AM 14/08/2006, Gleb Smirnoff wrote: M M The patch for RELENG_6 is available here: M M http://people.freebsd.org/~glebius/em-RELENG_6.patch M M Currently there is also a known problem - a race condition, M that occurs on SMP triggering a fake watchdog event, that M leads to unwanted NIC reset. M M Is that problem in the driver in RELENG_6, or what is in the patch ? It is present both in RELENG_6 and in HEAD. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd problem with Intel em driver
On Fri, Aug 11, 2006 at 01:27:42AM -0400, lnelson wrote: l I'm having an odd problem with the Intel em driver. It's l built into the kernel by default, but it won't recognize l the part. l l However, if I grab the driver source from the Intel website, l compile it as a KLD, and put it in loader.conf, it works. l The odd thing is that it complains that it is already loaded, l and acts as if it is refusing to load the module. l l When it works, the message I get is: l l module_register: module pci/em already exists! l Module pci/em failed to register: 17 l ... lots of stuff ... l em0: Intel(R) PRO/1000 Network Connection Version - 6.1.4 port 0x3000-0x301f mem l 0xc830-0xc831 i l rq 18 at device 0.0 on pci5 l em0: Ethernet address: 00:30:48:78:5a:2a l em0: Speed:N/A Duplex:N/A l em1: Intel(R) PRO/1000 Network Connection Version - 6.1.4 port 0x3020-0x303f mem l 0xc832-0xc833 i l rq 19 at device 0.1 on pci5 l em1: Ethernet address: 00:30:48:78:5a:2b l em1: Speed:N/A Duplex:N/A l l When it doesn't work, I get no messages regarding l em at all. l l It seems like the KLD is actually getting loaded, even l though it says it isn't. l l I should mention that I am running the amd64 port of l 6.1 RELEASE. l l Any thoughts? Can I run a production server like this? FreeBSD is always a bit behind in the version of the driver. First driver appears on Intel website, and later is merged to FreeBSD. Currently in 6-STABLE we've got version 6.0.5 driver. First you should try to update to 6-STABLE. If this doesn't help you should wait few weeks until driver 6.1.4 will be present in 6-STABLE. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) update for 6-STABLE
On Mon, Aug 07, 2006 at 11:32:18PM +0200, Thomas wrote: T Thanks for you work. T I will test this on a small freebsd based router with an averrage of T 300mb/s in the next few days. T Should I test anything special? Where should I see most of the T improvements compared to 6.1 Release? (less interrupts without polling?) I have just merged the driver to RELENG_6. Here is detailed changelog: http://lists.freebsd.org/pipermail/cvs-src/2006-August/067130.html -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) update for 6-STABLE
On Mon, Aug 07, 2006 at 10:24:44AM +1000, Michael Vince wrote: M On Thu, Aug 03, 2006 at 04:14:35PM -0700, Nikolas Britton wrote: M N First, it significantly improves perfromance of the driver M N under high pps load. M N Second, it adds support for few new chips. M N M N You need to update your system to fresh RELENG_6. The driver M N will not compile on 6.1-RELEASE. M N M N Why will it not compile on 6.1? M M Because it uses new taskqueue API not yet present in 6.1-RELEASE. M M Sounds good, M I will have to wait till 6.2release before using it, Stable just isn't M as stable as it used to be. If everyone avoid using RELENG branch, it won't get any more stable. Subseqently the releases (that are cut from RELENG branch) will get less testing, and thus will be less stable. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) update for 6-STABLE
On Thu, Aug 03, 2006 at 04:14:35PM -0700, Nikolas Britton wrote: N First, it significantly improves perfromance of the driver N under high pps load. N Second, it adds support for few new chips. N N You need to update your system to fresh RELENG_6. The driver N will not compile on 6.1-RELEASE. N N Why will it not compile on 6.1? Because it uses new taskqueue API not yet present in 6.1-RELEASE. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em(4) update for 6-STABLE
Colleagues, here is a patch that merges HEAD em(4) driver to RELENG_6. First, it significantly improves perfromance of the driver under high pps load. Second, it adds support for few new chips. You need to update your system to fresh RELENG_6. The driver will not compile on 6.1-RELEASE. Then you need to run the following sequence: cd /usr/src/sys/dev/em fetch http://people.freebsd.org/~glebius/em-6.0.5.RELENG_6.patch.gz gunzip em-6.0.5.RELENG_6.patch.gz patch em-6.0.5.RELENG_6.patch and then rebuild your kernel and reboot. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) update for 6-STABLE
On Thu, Aug 03, 2006 at 12:53:08PM +0200, Kurt Jaeger wrote: Khere is a patch that merges HEAD em(4) driver to RELENG_6. K K Does it address the issue raised in the mail with the subject K Subject: em promiscuous mode bug? K on current@ ? AFAIK, it doesn't. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Mon, Mar 06, 2006 at 06:59:07PM +, Hiroki Sato wrote: H H Modified files: H en/releases/6.1R todo.sgml H Log: H Add new items: H exec_map depletion, H NFS data corruption between two 7.0 machines, H panic in fxp driver, H deadlock in vn_start_write() consumers, H panic in bpf, H devfs locking problem, H pty leak, H trap in cpu_ipi_selected() on sparc64, and H rpc.lockd interoperability problems. Is it possible place kern/87208 into TODO list for 6.1-RELEASE? The problem appeared to be a bad regression in 6.0-RELEASE, that hurted many users. The PR contains several test cases, description and patch for the problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Tue, Mar 07, 2006 at 05:46:54AM +0900, Hiroki Sato wrote: H gl Is it possible place kern/87208 into TODO list for 6.1-RELEASE? H gl The problem appeared to be a bad regression in 6.0-RELEASE, H gl that hurted many users. The PR contains several test cases, H gl description and patch for the problem. H H Thanks, added just now. Will this description do? Looks fine, thanks. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter + bge strangeness
Darren, On Sun, Feb 26, 2006 at 12:16:05PM +, Darren Reed wrote: D Root of the problem is inside ipfilter - if driver use 'partial' (i.e. without D pseudo header) rx checksum offloading ipfilter fails to calculate checksum D correctly (it's using ip packet length (ip_fil_freebsd.c:1561) instead of D tcp/udp length). D This patch enables 'full' rxcsum offloading so ipfilter's bug should not be D triggered. D D I think what you're saying is that this is wrong: D sum = in_pseudo(ip-ip_src.s_addr, ip-ip_dst.s_addr, D htonl(m-m_pkthdr.csum_data + D fin-fin_ip-ip_len + fin-fin_p)); D D And that fin-fin_ip-ip_len needs to be replaced by something D that is like ip_len - ip_hl - tcp/icmp/udp_hl ? D D Just so that I understand the interactions here properly, is there D a way to tell when FreeBSD will use partial checksums like it was D before compare to now ? If the m-m_pkthdr.csum_flags field doesn't have the CSUM_PSEUDO_HDR flag, then the m-m_pkthdr.csum_data field contains partial checksum. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange number of mbufs
On Fri, Feb 03, 2006 at 12:52:09AM +0300, Artem Kuchin wrote: A Running 5.4-CURRENT. Web server. About 150 virtual servers. A A %netstat -m A A 4294481198 mbufs in use A 4294662679/25600 mbuf clusters in use (current/max) A 0/694/6656 sfbufs in use (current/peak/max) A 3463545 KBytes allocated to network A 0 requests for sfbufs denied A 0 requests for sfbufs delayed A 1681997 requests for I/O initiated by sendfile A 75325 calls to protocol drain routines A A What does this mean? Do i really have 4294481198 mbufs in use? A How is this possible? This is fixed in 6.0-RELEASE. In 5.x the true values can be obtained via 'vmstat -z'. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange number of mbufs
On Fri, Feb 03, 2006 at 11:37:32AM +0300, Artem Kuchin wrote: A This is fixed in 6.0-RELEASE. In 5.x the true values can be obtained A via 'vmstat -z'. A A Which number from output of vmstat -z indicates mbufs? I don't see it A there. vmstat -z | grep Mbuf MbufClust: 2048,25600,400, 34, 523776 Mbuf:256,0,403,482, 1216688264 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent MFC's causing trouble with network and mouse
On Tue, Jan 31, 2006 at 02:27:58AM +0300, Andrew Pantyukhin wrote: A I upgraded my world and kernel from about a week's A old state to today's source and network (vge) and A mouse (ums) stopped working. vge0 has a formerly A usual trouble of link state going up and down, while A ums0 doesn't move or feel its buttons (tried moused A and xorg). A A Had a look at cvs, didn't see anything suspicious A about vge and ums in particular :-( This is about time A I learnt how to live with several kernels at hand... Yes, vge(4) and ums(4) wasn't agressively edited recently, so the breakage is somewhere else. Probably you need to make a binary search to find the commit that caused the problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dc0: watchdog timeout and nve0: device timeout
On Tue, Jan 31, 2006 at 03:08:03AM -0500, Anish Mistry wrote: A After updating to STABLE today I'm getting the following message with A my dc and nve NICs every few seconds. UP, AMD64. A kernel from last A Thursday was fine. A A dc0: watchdog timeout A nve0: device timeout (4) Can you try to backout the code in sys/dev/pci to Thursday? If this doesn't help, you probably need to do a binary search in this small timeframe. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent MFC's causing trouble with network and mouse
On Tue, Jan 31, 2006 at 12:38:44PM +0300, Andrew Pantyukhin wrote: A On 1/31/06, Gleb Smirnoff [EMAIL PROTECTED] wrote: A On Tue, Jan 31, 2006 at 02:27:58AM +0300, Andrew Pantyukhin wrote: A A I upgraded my world and kernel from about a week's A A old state to today's source and network (vge) and A A mouse (ums) stopped working. vge0 has a formerly A A usual trouble of link state going up and down, while A A ums0 doesn't move or feel its buttons (tried moused A A and xorg). A A A A Had a look at cvs, didn't see anything suspicious A A about vge and ums in particular :-( This is about time A A I learnt how to live with several kernels at hand... A A Yes, vge(4) and ums(4) wasn't agressively edited recently, A so the breakage is somewhere else. Probably you need to A make a binary search to find the commit that caused the problem. A A Ok, could you please tell me where to learn how to do A that? 1) Divide the breakage timeframe by two, to determine the middle. (For example 26 Jan - working, 31 Jan - not working. Then the middle would be 28 Jan.) 2) Update your sources to the middle. 3) Check whether problem is present? Goto 1). You loop in this cycle until you come to a small timeframe with a few commits. Then you either determine which one is problematic logically, or try to apply them one by one. Once you habe found the problematic commit, you contact its author. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent MFC's causing trouble with network and mouse
On Tue, Jan 31, 2006 at 03:19:19PM +0300, Andrew Pantyukhin wrote: A Oh, I see. I know what binary search is, I just thought A I needed to look for some binaries :-) Thanks, I'll try A A But first, I want to look through recent commit messages. A While FreshSource is still kind of beta, I wonder what you A usually use to do it. Mailing list? Some tool? I mirror the whole CVS repo using /usr/share/examples/cvsup/cvs-supfile, thus I just read /home/ncvs/CVSROOT-src/commitlogs/. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem. - Upgrade to RELEASE :)
On Tue, Jan 31, 2006 at 02:16:38PM +0200, husnu demir wrote: h Yes I know but there is no point which date should be used. I made a random date with date=2006.01.27.01.00.00 but it is just skipping the tag :( and I could not found any solution. h h I am trying to get all the previous files by hand. It takes too much time for me :) Another option is to use CVS instead of cvsup. I always to so. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: couldn't map interrupt problems with updated 6.0 kernel
On Tue, Jan 31, 2006 at 03:36:32PM +0200, husnu demir wrote: h It also caused the some problems with my machine. I get all the files by hand and replaced the whole pci subsystem. Can somebody revert what is committed to the CVS system. Is there any possibility for that. Warner is working on this. It is night at his timezone now, so I think he will fix it after several hours. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem. - Upgrade to RELEASE :)
On Wed, Feb 01, 2006 at 09:11:22AM +0200, husnu demir wrote: h No I am not tired. We would like to be part of that, even like testers. I did try to compile but gave these error messages. I did not make CVSUP because of the pci error in the tree. You can CVSUP once more, the PCI issue is fixed already. h Here is the error messages; h h cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/METU/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/METU -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/bge/../../dev/bge/if_bge.c h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function `bge_poll_locked': h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2749: error: structure has no member named `bge_link_evt' h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2754: error: structure has no member named `bge_link_evt' h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function `bge_intr': h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2806: error: structure has no member named `bge_link_evt' h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function `bge_tick_locked': h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2857: error: structure has no member named `bge_link_evt' h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function `bge_link_upd': h /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3741: error: structure has no member named `bge_link_evt' Looks like the patch to if_bgereg.h wasn't applied. Can you reapply patches after cvsup? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem.
On Fri, Jan 27, 2006 at 02:24:38PM +0200, husnu demir wrote: h Hi, h h I upgraded my pc after 2006-01-25 FreeBSD-SA-06:06.kmem issue. After that it also upgrade the bge drivers and now it is not working. In fact my Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 is not working. The other bge's working properly. Most probly last update may cause that. I have been using 6-STABLE. h h I also tried to look at the switch part and find out that there are CRC Errors. The errors comes just after enabling the interface on the bsd box. After that there isnt any activity. Also when I sniff the interface with tcpdump, I saw lots of packets. Most probly, the driver did not let the further comminication after bad CRCs. What happens if you disable hardware checksum offloading on your NIC? ifconfig bge0 -rxcsum -txcsum -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem.
On Fri, Jan 27, 2006 at 02:24:38PM +0200, husnu demir wrote: h I upgraded my pc after 2006-01-25 FreeBSD-SA-06:06.kmem issue. After that it also upgrade the bge drivers and now it is not working. In fact my Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 is not working. The other bge's working properly. Most probly last update may cause that. I have been using 6-STABLE. h h I also tried to look at the switch part and find out that there are CRC Errors. The errors comes just after enabling the interface on the bsd box. After that there isnt any activity. Also when I sniff the interface with tcpdump, I saw lots of packets. Most probly, the driver did not let the further comminication after bad CRCs. Please provide also output from 'pciconf -lv | grep -A 3 ^bge', and from 'ifconfig'. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem. - Upgrade to RELEASE :)
On Fri, Jan 27, 2006 at 06:11:51PM +0200, husnu demir wrote: h I upgraded to the 6_RELEASE; h h $ uname -a h FreeBSD nrouter.cc.metu.edu.tr 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Jan 27 18:03:39 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NON-GENERIC i386 h h and now it is working. But the CRC errors still exists. I only see the CRC errors on enabling the interface. But the stable still does not work. One more time: please provide also output from 'pciconf -lv | grep -A 3 ^bge', and from 'ifconfig'. Also it is important to know whether doing 'ifconfig bge0 -rxcsum -txcsum' fixes operation on 6.0-STABLE. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem.
On Fri, Jan 27, 2006 at 05:58:18PM +0200, husnu demir wrote: h By the way the problem exists on bge2 (with Multimode F/O connector.) Oh, this is an important information. Can you please upgrade to STABLE and then test several versions of if_bge.c? The breakage is somewhere between rev. 1.101 and 1.113. There is high probability it is one of Oleg's changes. Details here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c All revisions up to the latest should be buildable on 6.0-STABLE. The only place where build can fail is VLAN_INPUT_TAG() macro. You probably need to replace it with VLAN_INPUT_TAG_NEW() if it fails to build. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bge driver problem.
On Fri, Jan 27, 2006 at 07:01:53PM +0200, husnu demir wrote: h I tried http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/bge/if_bge.c?rev=1.91.2.7content-type=text/plain; version and replaced VLAN_INPUT_TAG with VLAN_INPUT_TAG_NEW (only one occurance). And the following errors come up. Ohh, you also need to keep if_bgereg.h in sync with if_bge.c. Sorry, I didn't mention this. h Not: I am leaving the office. Most probly, I will be here tomorrow morning :( Me too. I will be online tomorrow for short time. I think Oleg will join debugging your problem. Here is attached files of all (if I haven't lost anything) important changes. You can fetch actual files from cvsweb. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE pjd 2005-09-28 19:20:49 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c Log: Implement suspend/resume methods to be more ACPI friendly. I'm able to suspend/resume my laptop without this change, but then I need to wait for the watchdog to reset the card. With this change, it is ready immediately. Glanced at by: glebius Revision ChangesPath 1.96 +36 -0 src/sys/dev/bge/if_bge.c glebius 2005-10-22 14:31:02 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c if_bgereg.h Log: Introduce polling(4) capability for bge(4). Submitted by: Oleg Bulyzhin oleg rinet.ru Revision ChangesPath 1.98 +110 -2src/sys/dev/bge/if_bge.c 1.37 +3 -0 src/sys/dev/bge/if_bgereg.h glebius 2005-11-15 14:43:23 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c if_bgereg.h Log: Recognize Broadcom BCM5752 chip, that can be found in HP DC7600. PR: kern/88940 Submitted by: Alexander Hausner Revision ChangesPath 1.100 +5 -2 src/sys/dev/bge/if_bge.c 1.38 +2 -0 src/sys/dev/bge/if_bgereg.h glebius 2005-11-30 12:37:07 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c Log: If bus_dmamap_load() failed, we free the mbuf. We also need to clear the pointer, to avoid double free on next bge_stop(). Revision ChangesPath 1.101 +6 -2 src/sys/dev/bge/if_bge.c oleg2005-12-08 13:31:52 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c sys/dev/mii brgphy.c Log: 1) fix tiny bug in bge_start_locked() 2) rework link state detection code use it in POLLING mode 3) fix 2 bugs in link state detection code: a) driver unable to detect link loss on bcm5721 b) on bcm570x chips (tested on bcm5700 bcm5701 bcm5702) driver fails to detect link loss with probability 1/6 (solved in brgphy.c) Devices working in TBI mode should not be affected by this change. Approved by:glebius (mentor) MFC after: 1 month Revision ChangesPath 1.102 +115 -105 src/sys/dev/bge/if_bge.c 1.38 +1 -1 src/sys/dev/mii/brgphy.c glebius 2005-12-08 16:11:45 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c if_bgereg.h Log: A big rewrite of receive Jumbo frame handling. Remove the local Jumbo cluster allocator, that wasn't MPSAFE. Instead, utilize our new generic UMA jumbo cluster allocator. Since UMA gives us a 9k piece that is contigous in virtual memory, but isn't contigous in physical memory we need to handle a few segments. To deal with this we utilize Tigon chip feature - extended RX descriptors, that can handle up to four DMA segments for one frame. Details: o Remove bge_alloc_jumbo_mem(), bge_free_jumbo_mem(), bge_jalloc(), bge_jfree() functions. o Remove SLIST heads, bge_jumbo_tag, bge_jumbo_map from softc. o Use extended RX BDs for Jumbo receive producer ring, and initialize it appropriately. o New bge_newbuf_jumbo(): - Allocate an mbuf with Jumbo cluster with help of m_cljget(). - Load the cluster for DMA with help of bus_dmamap_load_mbuf_sg(). - Assert that we got 3 segments in the DMA mapping. - Fill in these 3 segments into the extended RX descriptor. Revision ChangesPath 1.103 +49 -233 src/sys/dev/bge/if_bge.c 1.39 +26 -15src/sys/dev/bge/if_bgereg.h marcel 2005-12-13 06:14:14 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c Log: In bge_link_upd(), rewrite the logic so that status is assigned on the code path it is used in a way that GCC understands. This avoids breakage due to higher optimization levels. Revision ChangesPath 1.104 +2 -4 src/sys/dev/bge/if_bge.c yongari 2005-12-15 05:48:49 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c if_bgereg.h Log: Add bge(4) support for big-endian architectures(part 1/2). - Give up endianess support and switch to native-endian
Re: panic: mb_dtor_mbuf: M_EXT set
On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I And another bogus panic is removed in 1.9.2.4 I I I The kernel is working again, thanks! I I It's working in regard of vr0, thank you. However now my computer I resets w/o anything logged when starting kde; if I only startx it I doesn't happen (without exec startkde in .xinitrc); I commented out any I fancy options like dri with no effect and it also happen if I kldunload I snd_via8233 before starting kde. I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I happen with sources from 19. Bad news. Can you do a binary search and find commit that makes this regression? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system laggy under load, SCHED_BSD
On Sun, Jan 22, 2006 at 11:00:28PM +0100, Tobias Roth wrote: T Since some time, I experience extremely bad system behaviour under T load. For instance when compiling something, or unpacking a large T archive, the system is almost unusable, even the mouse pointer T reacts sloppy. T T My system: T T 6.0-STABLE FreeBSD 6.0-STABLE #7: Sun Jan 22 15:53:39 CET 2006 i386 T T I use SCHED_BSD. T T How can I diagnose the problem, or provide more information? What T factors might influence what I experience? I cannot give a more precise T point in time as when this started, since I switched versions and T systems a few times recently. What are numbers for the swap in/out in top(1)? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I The kernel is working again, thanks! I I I I It's working in regard of vr0, thank you. However now my computer I I resets w/o anything logged when starting kde; if I only startx it I I doesn't happen (without exec startkde in .xinitrc); I commented I I out any fancy options like dri with no effect and it also happen I I if I kldunload snd_via8233 before starting kde. I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I I happen with sources from 19. I I Bad news. Can you do a binary search and find commit that makes this I regression? I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) So upgrading once more did help you? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:35:07PM +0200, Ion-Mihai Tetcu wrote: I On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I I wrote: I I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff I I I wrote: I I I T This should be fixed in src/sys/kern_mbuf.c, rev. I I I T 1.9.2.3 I I I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I I I I The kernel is working again, thanks! I I I I I I It's working in regard of vr0, thank you. However now my I I I computer resets w/o anything logged when starting kde; if I I I I only startx it doesn't happen (without exec startkde I I I in .xinitrc); I commented out any fancy options like dri with I I I no effect and it also happen if I kldunload snd_via8233 I I I before starting kde. I I I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it I I I didn't happen with sources from 19. I I I I Bad news. Can you do a binary search and find commit that makes I I this regression? I I I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) I I So upgrading once more did help you? I I So it seem. I am using ULE, I have no problem with the new kernel with I either UL or 4BSD. I didn't test the bad kernel with 4BSD, but I I could do it if you like. Probably you hit another incorrect KASSERT in kern_mbuf.c. I have removed it some time after the first one. Since X was starting at this moment you couldn't be dropped into debugger, and so the box was rebooting. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, Jan 23, 2006 at 04:44:53PM +0200, Ion-Mihai Tetcu wrote: I Probably you hit another incorrect KASSERT in kern_mbuf.c. I have I removed it some time after the first one. Since X was starting at I this moment you couldn't be dropped into debugger, and so the box was I rebooting. I I I don't know if I understand you right, but starting a bare X and I playing around for a while then typing startkde resulted in a reset. When panic happens and you have X on the screen, the kernel can't switch to syscons. It dumps core if you have KDB_UNATTENDED in kernel, in other case it just reboots. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 And another bogus panic is removed in 1.9.2.4 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ on GIF tunnels?
On Wed, Jan 18, 2006 at 05:36:16PM -0600, J. Buck Caldwell wrote: J Gleb Smirnoff wrote: J On Mon, Jan 16, 2006 at 11:48:34PM -0600, J. Buck Caldwell wrote: J J Is there any work on adding support for ALTQ to the GIF tunnel J J interface? I'm having wonderful results getting ALTQ working on normal J J interfaces, but it would be heavenly to prioritize the traffic inside J J the tunnels. J J You can (and probably should) enable ALTQ on the physical interface J that gif(4) runnels use for encapsulated packets. J J Yes, but that doesn't do any good for the packets traveling inside the J tunnel. Specifically, I have a corporate network hooked to a branch via J VPN, and want to prioritize not just the tunnel over ordinary traffic, J but prioritize different types of traffic inside the tunnel. You tag packets with ALTQ identifier in ipfw/pf, and this identifier isn't lost after packet is encapsulated. So, when going out the physical interface the packet will be queued according to the ALTQ policy you have specified. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Wed, Jan 18, 2006 at 11:36:46AM +0900, Pyun YongHyeon wrote: P same problem device timeout. P fxp is also timing out and I don't know why. P Any idea? P P P If sk(4) is the cause of problem fxp wouldn't be affected. P P I guess so. But fxp also times out almost at same time as sk does. Have you tried another motherboard? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ on GIF tunnels?
On Mon, Jan 16, 2006 at 11:48:34PM -0600, J. Buck Caldwell wrote: J Is there any work on adding support for ALTQ to the GIF tunnel J interface? I'm having wonderful results getting ALTQ working on normal J interfaces, but it would be heavenly to prioritize the traffic inside J the tunnels. You can (and probably should) enable ALTQ on the physical interface that gif(4) runnels use for encapsulated packets. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ 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 tinderbox] failure on i386/i386
On Sat, Jan 14, 2006 at 09:00:24PM -0500, FreeBSD Tinderbox wrote: F TB --- 2006-01-15 01:09:26 - tinderbox 2.3 running on freebsd-current.sentex.ca F TB --- 2006-01-15 01:09:26 - starting RELENG_6 tinderbox run for i386/i386 F TB --- 2006-01-15 01:09:26 - cleaning the object tree F TB --- 2006-01-15 01:09:48 - checking out the source tree F TB --- 2006-01-15 01:09:48 - cd /tinderbox/RELENG_6/i386/i386 F TB --- 2006-01-15 01:09:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src F TB --- 2006-01-15 01:19:09 - building world (CFLAGS=-O -pipe) F TB --- 2006-01-15 01:19:09 - cd /src F TB --- 2006-01-15 01:19:09 - /usr/bin/make -B buildworld F Rebuilding the temporary build tree F stage 1.1: legacy release compatibility shims F stage 1.2: bootstrap tools F stage 2.1: cleaning up the object tree F stage 2.2: rebuilding the object tree F stage 2.3: build tools F stage 3: cross tools F stage 4.1: building includes F stage 4.2: building libraries F stage 4.3: make dependencies F stage 4.4: building everything F [...] F cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/44arp.c F cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm F gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 ipresend.1.gz F === sbin/ipfw (all) F cc -O -pipe -c /src/sbin/ipfw/ipfw2.c F /src/sbin/ipfw/ipfw2.c: In function `list_pipes': F /src/sbin/ipfw/ipfw2.c:2166: error: invalid operands to binary != F /src/sbin/ipfw/ipfw2.c:2205: error: invalid operands to binary != F *** Error code 1 Looks like it was checkouted in small gap (~ 3 mins) between two commits. Since no more reports on the list, I think there is no breakage. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libnetgraph compilation problem
On Mon, Jan 09, 2006 at 08:49:27PM +0100, Frederic Praca wrote: F Hello and happy new year, F I still got the same problem that is described there F (http://docs.freebsd.org/cgi/mid.cgi?1706.84.247.145.210.1132137934.squirrel ). F My uname is : F FreeBSD coruscant.dnsalias.net 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed F Jan 4 21:41:20 CET 2006 F [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CORUSCANT i386 F F Any idea ? Is your /usr/src/sys/netgraph/ng_split.h file correct? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libnetgraph compilation problem
On Mon, Jan 09, 2006 at 10:34:38PM +0100, Fr?d?ric PRACA wrote: F On Mon, Jan 09, 2006 at 08:49:27PM +0100, Frederic Praca wrote: F F Hello and happy new year, F F I still got the same problem that is described there F F F (http://docs.freebsd.org/cgi/mid.cgi?1706.84.247.145.210.1132137934.squirrel F ). F F My uname is : F F FreeBSD coruscant.dnsalias.net 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed F F Jan 4 21:41:20 CET 2006 F F [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CORUSCANT i386 F F F F Any idea ? F F Is your /usr/src/sys/netgraph/ng_split.h file correct? F I just cvsup'ed few hours ago with RELENG_6. Of course, I could hack the source F code but that's not my goal. May be /usr/include/netgraph/ng_split.h is incorrect? But if it affects build, than we have problem in our build infrastructure. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
patch against xl(4) regression in RELENG_6
Colleagues,
here is WIP patch for the regression with PCMCIA 3Com cards that
you have reported. Please test it and tell whether it helps.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: cardbus.c
===
RCS file: /home/ncvs/src/sys/dev/cardbus/cardbus.c,v
retrieving revision 1.54
diff -u -r1.54 cardbus.c
--- cardbus.c 28 Oct 2005 06:03:53 - 1.54
+++ cardbus.c 26 Dec 2005 10:17:47 -
@@ -149,14 +149,6 @@
cardbus_add_map(cbdev, child, PCIR_BAR(reg));
}
-static void
-cardbus_do_res(struct resource_list_entry *rle, device_t child, uint32_t start)
-{
- rle-start = start;
- rle-end = start + rle-count - 1;
- pci_write_config(child, rle-rid, rle-start, 4);
-}
-
static int
cardbus_barsort(const void *a, const void *b)
{
@@ -249,8 +241,16 @@
rle = barlist[tmp];
if (rle-type == SYS_RES_MEMORY
dinfo-mprefetchable BARBIT(rle-rid)) {
- cardbus_do_res(rle, child, start);
- start += rle-count;
+ rle-res = bus_alloc_resource(cbdev,
+ rle-type, rle-rid, start, end,
+ rle-count,
+ rman_make_alignment_flags(rle-count));
+ if (rle-res != NULL) {
+ rle-start = rman_get_start(rle-res);
+ rle-end = rman_get_end(rle-res);
+ pci_write_config(child,
+ rle-rid, rle-start, 4);
+ }
}
}
}
@@ -297,8 +297,20 @@
rle = barlist[tmp];
if (rle-type == SYS_RES_MEMORY
(dinfo-mprefetchable BARBIT(rle-rid)) == 0) {
- cardbus_do_res(rle, child, start);
- start += rle-count;
+ rle-res = bus_alloc_resource(cbdev,
+ rle-type, rle-rid, start, end,
+ rle-count,
+ rman_make_alignment_flags(rle-count));
+ if (rle-res == NULL) {
+ DEVPRINTF((cbdev, Cannot pre-allocate
+ memory for cardbus device\n));
+ free(barlist, M_DEVBUF);
+ return (ENOMEM);
+ }
+ rle-start = rman_get_start(rle-res);
+ rle-end = rman_get_end(rle-res);
+ pci_write_config(child,
+ rle-rid, rle-start, 4);
}
}
}
@@ -341,8 +353,20 @@
for (tmp = 0; tmp count; tmp++) {
rle = barlist[tmp];
if (rle-type == SYS_RES_IOPORT) {
- cardbus_do_res(rle, child, start);
- start += rle-count;
+ rle-res = bus_alloc_resource(cbdev,
+ rle-type, rle-rid, start, end,
+ rle-count,
+ rman_make_alignment_flags(rle-count));
+ if (rle-res == NULL) {
+ DEVPRINTF((cbdev, Cannot pre-allocate
+ IO port for cardbus device\n));
+ free(barlist, M_DEVBUF);
+ return (ENOMEM);
+ }
+ rle-start = rman_get_start(rle-res);
+ rle-end = rman_get_end(rle-res);
+ pci_write_config(child,
+ rle-rid, rle-start, 4);
}
}
}
@@ -357,9 +381,10 @@
}
start = rman_get_start(res);
end = rman_get_end(res);
- bus_release_resource(cbdev, SYS_RES_IRQ, rid, res);
resource_list_add(dinfo-pci.resources, SYS_RES_IRQ, rid, start, end,
1);
+ rle = resource_list_find(dinfo-pci.resources, SYS_RES_IRQ, rid);
+ rle-res = res;
dinfo-pci.cfg.intline = start;
pci_write_config(child, PCIR_INTLINE, start, 1);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em bad performance
On Wed, Dec 21, 2005 at 06:55:29PM +0200, Danny Braniss wrote: D this particular mb, intel sr1435vp2, has 2 ethernets, D one is an Intel '82547EI Gigabit Ethernet Controller', the other is D a Marvell (which seems that the driver is around the corner). D D the em performance under 6.0-stable is half of any other box i have, D and a similar mb running linux gives about 1GB, so D D Q: any ideas what can be wrong? Please be more informative. How do you measure performance: netperf, ftp, ... ? What is the box doing: routing, bridging, running ftp server? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em bad performance
On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote: D D Server listening on TCP port 5001 D TCP window size: 64.0 KByte (default) D D [ 4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 58122 D (intel westvill) D [ ID] Interval Transfer Bandwidth D [ 4] 0.0-10.0 sec 1.01 GBytes 867 Mbits/sec D [ 4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 55269 D (intel westvill) D [ ID] Interval Transfer Bandwidth D [ 4] 0.0-10.0 sec 967 MBytes 811 Mbits/sec D [ 5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 58363 D (intel dual xeon/emt64) D [ ID] Interval Transfer Bandwidth D [ 5] 0.0-10.0 sec 578 MBytes 485 Mbits/sec D D i've run this several times, and the results are very similar. D i also tried i386, and the same bad results. D all hosts are connected at 1gb to the same switch. So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's compare the NIC hardware. Can you plese show pciconf -lv | grep -A3 ^em on both motherboards? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em bad performance
On Thu, Dec 22, 2005 at 12:37:53PM +0200, Danny Braniss wrote: D On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote: D D D D Server listening on TCP port 5001 D D TCP window size: 64.0 KByte (default) D D D D [ 4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 58122 D D (intel westvill) D D [ ID] Interval Transfer Bandwidth D D [ 4] 0.0-10.0 sec 1.01 GBytes 867 Mbits/sec D D [ 4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 55269 D D (intel westvill) D D [ ID] Interval Transfer Bandwidth D D [ 4] 0.0-10.0 sec 967 MBytes 811 Mbits/sec D D [ 5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 58363 D D (intel dual xeon/emt64) D D [ ID] Interval Transfer Bandwidth D D [ 5] 0.0-10.0 sec 578 MBytes 485 Mbits/sec D D D D i've run this several times, and the results are very similar. D D i also tried i386, and the same bad results. D D all hosts are connected at 1gb to the same switch. D D So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's compare the NIC D hardware. Can you plese show pciconf -lv | grep -A3 ^em on both motherboards? D D on a SE7501WV2: D [EMAIL PROTECTED]:7:0: class=0x02 card=0x341a8086 chip=0x10108086 rev=0x01 D hdr=0x00 D vendor = 'Intel Corporation' D device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' D class= network D D on a SR1435VP2: D [EMAIL PROTECTED]:3:0: class=0x02 card=0x34668086 chip=0x10768086 rev=0x05 D hdr=0x00 D vendor = 'Intel Corporation' D device = '82547EI Gigabit Ethernet Controller' D class= network The first one 82546EB is attached to fast PCI-X bus, and the 82547EI is on CSA bus. The CSA bus is twice faster than old PCI bus, CSA can handle 266 Mbps. I'm not sure but may be it has same ~50% overhead as old PCI bus. Probably our em(4) driver is not optimized enough and does too many accesses to the PCI bus, thus utilizing more bandwidth than needed to handle traffic. In this case we see that NIC on slower bus (but enough to handle Gigabit) is must slower than NIC on faster bus. (This paragraph is my own theory, it can be complete bullshit.) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 panic: kmem_malloc(16384): kmem_map too small: 172728320 total allocated
On Wed, Dec 14, 2005 at 01:25:30PM +0100, Fabian Keil wrote: F I triggered a few reproducible panics on FreeBSD 6.0-STABLE. F F I created a ramdisk with: F F /sbin/mdconfig -a -t malloc -s 256M -u 10 F /sbin/newfs -U /dev/md10 F /sbin/mount /dev/md10 /mnt/ramdisk F F The system has avail memory = 515932160 (492 MB) F and 1GB swap space. F F While copying to /mnt/ramdisk trough ftp localhost F it got: This usually exposes some memory leak in kernel. Can you please do the following - copy some amount of data to /mnt/ramdisk trough ftp localhost, and cancel the operation before it panics. Then run vmstat -m and vmstat -z, to determine what kind of memory allocation is leaking. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: puc fails to attach serial ports
On Sun, Dec 11, 2005 at 06:22:40PM +, Gavin Atkinson wrote: G I'm trying to use puc(4) under RELENG_6 to attach the two serial ports on G a PCI card I have, but it's not working. It also fails under 6.0-RELEASE, G I don't have the ability to test earlier versions. G G The card is developed, but as far as I can see, no attempt is made to G attach the sio(4) devices below it. G G puc0: Dolphin Peripherals 4036 port 0x18c0-0x18df irq 25 at device 9.0 on G pci0 G puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x18c0 G port rid 16 bst 0, start 18c0, end 18df G puc0: i 0, type sio, ressz 8, type 1 G puc: Using sio2 G puc: type 1, bar 10, offset 0 G puc0: i 1, type sio, ressz 8, type 1 G puc: Using sio3 G puc: type 1, bar 10, offset 8 G G Adding some printfs to the code, it turns out that device_probe_and_attach G around line 375 of sys/dev/puc/puc.c is returning 6. G G I have also added printfs to the probe and attach code of both the pci and G puc attachments of sio(4), and have determined that none of them get G called. G G How can I further diagnose why this card is not getting recognised? Afaik, you need 'device uart', that will attach to your pucs. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T42 freezes when going to sleep under X11
On Fri, Dec 02, 2005 at 12:52:58PM -0800, George Hartzell wrote:
G I finally found the cause of my problems: there has been changes in
G the em driver (Gb ethernet), such that the machine freezes when trying
G to switch automatically from the X11 VT to the system console, before
G going to sleep. The interaction is surprising, but clearly the problem
G disappears when I remove device em from the kernel configuration,
G and it reappears when I do kldload if_em. Since I'm using only ath
G (wireless) anyway, this is fine with me...
G
G A previous partial solution suggested to me was to add
G hw.syscons.sc_no_suspend_vtswitch=1
G to sysctl.conf, but this means the screen gets garbled and I have to
G do the switch by hand anyway, which is a real pain.
G Worse still: the machine would still freeze when going to sleep while
G the disk is active.
G
G The last step is to track down the bug in em, as it still seems to
G be there in yesterday's STABLE.
G
G I don't seem to have any problem with my T42p using a kernel compiled
G on 11/29 11:21
G
G My copy of if_em.c is:
G
G /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.65.2.8 2005/11/25 14:11:59 glebius
Exp $*/
George, Jacques,
what em(4) cards exactly do you have?
pciconf -lv | grep -A4 ^em
Can you please try the attached patch?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.85
diff -u -r1.85 if_em.c
--- if_em.c 10 Nov 2005 11:44:37 - 1.85
+++ if_em.c 11 Nov 2005 12:13:48 -
@@ -129,8 +129,11 @@
static int em_attach(device_t);
static int em_detach(device_t);
static int em_shutdown(device_t);
+static int em_suspend(device_t);
+static int em_resume(device_t);
static void em_intr(void *);
static void em_start(struct ifnet *);
+static void em_start_locked(struct ifnet *ifp);
static int em_ioctl(struct ifnet *, u_long, caddr_t);
static void em_watchdog(struct ifnet *);
static void em_init(void *);
@@ -208,6 +211,8 @@
DEVMETHOD(device_attach, em_attach),
DEVMETHOD(device_detach, em_detach),
DEVMETHOD(device_shutdown, em_shutdown),
+ DEVMETHOD(device_suspend, em_suspend),
+ DEVMETHOD(device_resume, em_resume),
{0, 0}
};
@@ -580,6 +585,41 @@
return(0);
}
+/*
+ * Suspend/resume device methods.
+ */
+static int
+em_suspend(device_t dev)
+{
+ struct adapter *adapter = device_get_softc(dev);
+
+ EM_LOCK(adapter);
+ em_stop(adapter);
+ EM_UNLOCK(adapter);
+
+ return bus_generic_suspend(dev);
+}
+
+static int
+em_resume(device_t dev)
+{
+ struct adapter *adapter = device_get_softc(dev);
+ struct ifnet *ifp;
+
+ EM_LOCK(adapter);
+ ifp = adapter-ifp;
+ if (ifp-if_flags IFF_UP) {
+ em_init_locked(adapter);
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
+ em_start_locked(ifp);
+ }
+
+ em_init_locked(adapter);
+ EM_UNLOCK(adapter);
+
+ return bus_generic_resume(dev);
+}
+
/*
* Transmit entry point
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heavy loaded network machine
On Thu, Dec 01, 2005 at 11:22:41AM +0100, Massimo Lusetti wrote: M Due to the latest thread on em interrupt storm i would like to know M which is the recommended nic to choose to be deployed on a -STABLE M M Read recommended as: which works good without known wired behavior and M has produced good performance over a gigabit wire The em(4) driver in STABLE is now in quite good state. We use it on heavy loaded routers. The interrupt storm in the thread you mention was probably caused by some bad hardware combination between mainboard and NIC. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[WARNING] RELENG_6 is broken
Colleagues, I'm very sorry but at this moment RELENG_6 is broken a bit. If you are using DHCP (client or server) please do not upgrade until I reply here that it is fixed. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [WARNING] RELENG_6 is broken
On Sat, Nov 26, 2005 at 01:28:05PM +0300, Gleb Smirnoff wrote: T I'm very sorry but at this moment RELENG_6 is broken a bit. If you T are using DHCP (client or server) please do not upgrade until I T reply here that it is fixed. The ARP problem in RELENG_6 is fixed in revision 1.137.2.6 of if_ether.c. The problem was introduced in revision 1.137.2.5. Make sure that you have revision 1.137.2.4 or revision 1.137.2.6, before you build new kernel. P.S. Important note is that problem is not related to DHCP, it affects any Ethernet user. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [WARNING] RELENG_6 is broken
On Sat, Nov 26, 2005 at 10:51:22AM -0800, Frank Mayhar wrote: F On Sat, 2005-11-26 at 13:58 +0300, Gleb Smirnoff wrote: FThe ARP problem in RELENG_6 is fixed in revision 1.137.2.6 of if_ether.c. F F Does this problem cause an arp storm? If so, I ran into it last night F and am very glad to see that it's fixed. (It was a new system and I F just figured it was due to pilot error or bad hardware.) Yes, it does. I'm sorry to waste your time. :| -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel land ppp makes mage fault
On Tue, Nov 15, 2005 at 09:38:16AM +0200, Anatoli Marinov wrote: A I try to use pptp (pptpclient) and ppp connection to my ISP with FreeBSD A 6-STABLE. A If I compile pptp from ports after installation it works in user land and A consume 50-60% from my CPU time (for 200 KB/sec). A Before 6-STABLE with 6-TESTx and RCx my pptp, compiled to use kernel level ppp A works great, but with 6-STABLE after 5 to 10 minutes I have page fault and A reboot. A pptpclient from ports by default compiles to work with user land ppp but with A simple changes in Makefile I compile it to work with kernel level ppp. A A Would you help me how can I use pptp with kernel level ppp and FreeBSD A 6-STABLE? Use ports/net/mpd. It is a userland daemon, that configures in-kernel PPP (including PPTP). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kmem_malloc(4096): kmem_map too small: 536870912 total allocated
Vladimir,
please confirm that the attached patch fix your problem. The patch is relative
to src/sys tree.
Kris, Christian, please review it. Thanks.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: nfsclient/nfs_lock.c
===
RCS file: /home/ncvs/src/sys/nfsclient/nfs_lock.c,v
retrieving revision 1.40
diff -u -r1.40 nfs_lock.c
--- nfsclient/nfs_lock.c6 Dec 2004 08:31:32 - 1.40
+++ nfsclient/nfs_lock.c25 Oct 2005 14:51:11 -
@@ -62,9 +62,13 @@
#include nfsclient/nfs_lock.h
#include nfsclient/nlminfo.h
+extern void (*nlminfo_release_p)(struct proc *p);
+
MALLOC_DEFINE(M_NFSLOCK, NFS lock, NFS lock request);
+MALLOC_DEFINE(M_NLMINFO, nlminfo, NFS lock process structure);
static int nfslockdans(struct thread *td, struct lockd_ans *ansp);
+static void nlminfo_release(struct proc *p);
/*
*
* A miniature device driver which the userland uses to talk to us.
@@ -194,6 +198,7 @@
printf(nfslock: pseudo-device\n);
mtx_init(nfslock_mtx, nfslock, NULL, MTX_DEF);
TAILQ_INIT(nfslock_list);
+ nlminfo_release_p = nlminfo_release;
nfslock_dev = make_dev(nfslock_cdevsw, 0,
UID_ROOT, GID_KMEM, 0600, _PATH_NFSLCKDEV);
return (0);
@@ -259,7 +264,7 @@
*/
if (p-p_nlminfo == NULL) {
MALLOC(p-p_nlminfo, struct nlminfo *,
- sizeof(struct nlminfo), M_LOCKF, M_WAITOK | M_ZERO);
+ sizeof(struct nlminfo), M_NLMINFO, M_WAITOK | M_ZERO);
p-p_nlminfo-pid_start = p-p_stats-p_start;
timevaladd(p-p_nlminfo-pid_start, boottime);
}
@@ -381,3 +386,12 @@
return (0);
}
+/*
+ * Free nlminfo attached to process.
+ */
+void
+nlminfo_release(struct proc *p)
+{
+free(p-p_nlminfo, M_NLMINFO);
+p-p_nlminfo = NULL;
+}
Index: nfsclient/nlminfo.h
===
RCS file: /home/ncvs/src/sys/nfsclient/nlminfo.h,v
retrieving revision 1.2
diff -u -r1.2 nlminfo.h
--- nfsclient/nlminfo.h 18 Sep 2001 23:31:53 - 1.2
+++ nfsclient/nlminfo.h 25 Oct 2005 14:40:30 -
@@ -40,5 +40,3 @@
int getlk_pid;
struct timeval pid_start; /* process starting time */
};
-
-extern void nlminfo_release(struct proc *p);
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.268
diff -u -r1.268 kern_exit.c
--- kern/kern_exit.c23 Oct 2005 12:19:08 - 1.268
+++ kern/kern_exit.c25 Oct 2005 14:45:35 -
@@ -82,6 +82,9 @@
/* Required to be non-static for SysVR4 emulator */
MALLOC_DEFINE(M_ZOMBIE, zombie, zombie proc status);
+/* Hook for NFS teardown procedure. */
+void (*nlminfo_release_p)(struct proc *p);
+
/*
* exit --
* Death of process.
@@ -234,6 +237,12 @@
funsetownlst(p-p_sigiolst);
/*
+* If this process has an nlminfo data area (for lockd), release it
+*/
+ if (nlminfo_release_p != NULL p-p_nlminfo != NULL)
+ (*nlminfo_release_p)(p);
+
+ /*
* Close open files and release open-file table.
* This may block!
*/
Index: sys/lockf.h
===
RCS file: /home/ncvs/src/sys/sys/lockf.h,v
retrieving revision 1.18
diff -u -r1.18 lockf.h
--- sys/lockf.h 25 Jan 2005 10:15:25 - 1.18
+++ sys/lockf.h 25 Oct 2005 14:51:28 -
@@ -40,10 +40,6 @@
struct vop_advlock_args;
-#ifdef MALLOC_DECLARE
-MALLOC_DECLARE(M_LOCKF);
-#endif
-
/*
* The lockf structure is a kernel structure which contains the information
* associated with a byte range lock. The lockf structures are linked into
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kmem_malloc(4096): kmem_map too small: 536870912 total allocated
On Tue, Oct 25, 2005 at 06:04:15PM +0200, Max Laier wrote: M On Tuesday 25 October 2005 17:00, Gleb Smirnoff wrote: MVladimir, M Mplease confirm that the attached patch fix your problem. The patch is M relative to src/sys tree. M MKris, Christian, please review it. Thanks. M M Are you sure it's safe to free the nlminfo struct before calling to fdfree() M in exit1()? It sounds like it might need the structure if there are pending M locks? Just a guess, though. The locks are actually held on the server side, so we aren't leaking them here. Anyway, the fix is directly from BSD/OS, from where nlminfo have came from. M On a side note, there are some whitespace errors in and before M nlminfo_release(). Thanks. I'll take this into account. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: setsockopt and SO_RCV/SNDTIMEO
Lefteris, On Fri, Oct 07, 2005 at 01:23:22AM +0300, Lefteris Tsintjelis wrote: L I am trying to set something like this up but it doesn't seem to work L as I expect it (unless I expect wrong): L L timeout.tv_sec = 4; L timeout.tv_usec = 0; L if(setsockopt(listenSocket, SOL_SOCKET, SO_RCVTIMEO, (void *)timeout, L sizeof(timeout)) == -1) L fprintf(stdout, setsockopt SO_RCVTIMEO failed: %s\n, L strerror(errno)); L if(setsockopt(listenSocket, SOL_SOCKET, SO_SNDTIMEO, (void *)timeout, L sizeof(timeout)) == -1) L fprintf(stdout, setsockopt SO_SNDTIMEO failed: %s\n, L strerror(errno)); L L When I telnet to the socket, the socket always stays connected. The L timer doesn't seem to work right. Am I missing anything here or is L this broken? You are expecting wrong from these socket options. They do not specify time after which socket should be closed, if no IO is done. The do limit time the process can block on the socket. So, if you do read() from this socket and it blocks, it will resume after 4 seconds even if no input is present. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: setsockopt and SO_RCV/SNDTIMEO
On Fri, Oct 07, 2005 at 05:04:40PM +0300, Lefteris Tsintjelis wrote: L You are expecting wrong from these socket options. They do not specify L time after which socket should be closed, if no IO is done. L L Is there any easy build in functionality for that? Pardon, but I do not understand the question. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with PPPoE STABLE and ADSL 3Com HomeConnect
On Mon, Sep 12, 2005 at 08:37:03AM +0200, ComteZero _ wrote: C Hello, C C it's been two weeks I try to find out what's wrong. Clean install from cvsup C STABLE (5). C my ADSL account works fine with REL. 4.4+rp_pppoe but not with my new STABLE C (5) (without using rp_pppoe). C could someone help me on this issue (logs provided here)... two PADI are C emitted but nothing happens after. C (i saw that someone had a similar problem, but with previous netgraph C revisions). C C thank you. C C Since my ADSL modem is 3Com HomeConnect, I've set the C net.graph.nonstandard_pppoe=1 In modern FreeBSD versions 3Com mode for ng_pppoe is switched per-node, not via sysctl. You should use ppp(8) option to enable 3Com mode: set pppoe 3Com -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named coredumping
On Thu, Jun 30, 2005 at 12:57:32PM -0500, Doug Barton wrote: D FYI, I had a chat with the ISC folks this week, and they said in clear terms D that enabling threads on current versions of BIND would be a pessimization. D I have already turned off threads in the port of 9.3.1, and am looking at D doing that for the base as well. D D Could you give the port a try for now (with or without the option to D overwrite the base system BIND), and let me know if that helps/solves your D problems? I'll rebuild base bind with threads disabled, and report after a week. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
