Re: buildworld fails with "Zero byte read from file, skipping rest of line"
Jeremie, On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote: J> > J> ===> gnu/usr.bin/groff/src/libs/libgroff (all) J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 3: warning: Zero byte read from file, skipping rest of line. J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 3: Need an operator J> > J> make[6]: "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" line 4: Need an operator J> > J> make[6]: Fatal errors encountered -- cannot continue J> > J> make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff J> > J> *** [all] Error code 1 J> > J> J> > J> Typscript available here: J> > J> http://people.freebsd.org/~jlh/typescript.buildworld.txt J> > J> J> > J> Any ideas? J> > J> > Can you try to reproduce this with unmapped I/O turned off in boot loader? J> J> I've never heard of that. Can you please point me to the right J> code/doc? In loader prompt: OK set vfs.unmapped_buf_allowed=0 OK boot -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10-RC4: Got crash in igb driver
I have some compillation issues : ../../../dev/e1000/if_igb.c: In function 'igb_mq_start_locked': ../../../dev/e1000/if_igb.c:3936: warning: 'poff' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'poff' was declared here ../../../dev/e1000/if_igb.c:3936: warning: 'ip_hlen' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'ip_hlen' was declared here But this fix the crash. However, I have now a copy made of all ipv6 forwarded packet in igb_pullup_headers. It will be nice to m_free the copy of the packet made in ip6_forward before calling nd6_output function. It will put back the packet writable and avoid (in most cases) the copy. I have no time this week to check performance of this new driver version. I'll try to make that Monday. Thank you for this fix Le mardi 14 janvier 2014 14:22:43 Eric Joyner a écrit : > All, > > I work with Jack on FreeBSD network drivers, and we have a patch that we > think might fix this problem. It re-implements the header pull-up code that > was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you > apply this patch to the igb version in HEAD and try it out on your network? > We can't replicate your setup here. > > If it solves your problem, then the next step would be to port the patch to > the ixgbe driver since, as Yonghyeon noted, it looks like that driver will > encounter the same problem. We could then modify em to add IPv6 offload > support as well. > > Thanks, > > --- > - Eric Joyner > > On Fri, Jan 10, 2014 at 02:35:29PM +0400, Gleb Smirnoff wrote: > > Yonghyeon, > > > > On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote: > > Y> > I experience some troubles with the igb device driver on FreeBSD > > 10-RC4. > > > Y> > > > Y> > The kernel make a pagefault in the igb_tx_ctx_setup function when > > accessing to > > > Y> > a IPv6 header. > > Y> > > > Y> > The network configuration is the following: > > Y> > - box acting as an IPv6 router > > Y> > - one interface with an IPv6 (igb0) > > Y> > - another interface with a vlan, and IPv6 on it (vlan0 on igb1) > > Y> > > > Y> > Vlan Hardware tagging is set on both interfaces. > > Y> > > > Y> > The packet that cause the crash come from igb0 and go to vlan0. > > Y> > > > Y> > After investigation, i see that the mbuf is split in two. The first > > one carry > > > Y> > the ethernet header, the second, the IPv6 header and data payload. > > Y> > > > Y> > The split is due to the "m_copy" done in ip6_forward, that make the > > mbuf not > > > Y> > writable and the "M_PREPEND" in ether_output that insert the new > > mbuf before > > > Y> > the original one. > > Y> > > > Y> > The kernel crashes only if the newly allocated mbuf is at the end of > > a memory > > > Y> > page, and no page is available after this one. So, it's extremly > > rare. > > > Y> > > > Y> > I inserted a "KASSERT" into the function (see attached patch) to > > check this > > > Y> > behavior, and it raises on every IPv6 forwarded packet to the vlan. > > The > > > Y> > problem disapear if i remove hardware tagging. > > Y> > > > Y> > In the commit 256200, i see that pullups has been removed. May it be > > related ? > > > Y> > > Y> I think I introduced the header parsing code to meet controller > > Y> requirement in em(4) and Jack borrowed that code in the past but it > > Y> seems it was removed in r256200. It seems igb_tx_ctx_setup() > > Y> assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf > > Y> of the chain. > > Y> This looks wrong to me. > > > > Can you please restore the important code in head ASAP? Although crashes > > happen > > > only when the mbuf is last in a page and page isn't mapped, we read > > thrash from > > > next allocation on almost every packet. > > It seems other Intel ethernet drivers except em(4) have similar > issues. I didn't check recent Intel controllers/drivers for long > time so I don't know details on hardware requirements of > offloading. > Since Jack is very responsive and has hardwares to verify, he would > be more appropriate person to handle these issues. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Alexandre Martins NETASQ -- We secure IT smime.p7s Description: S/MIME cryptographic signature
Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)
Dear Andriy and FreeBSD community,
Andriy Gapon wrote:
AG> on 14/01/2014 07:27 Vladimir Sharun said the following:
AG> > Dear Andriy and FreeBSD community,
AG> >
AG> >> I am not sure if the buffers are leaked somehow or if they are actually
in use.
AG> >> It's one of the very few places where data buffers are allocated without
AG> >> charging ARC. In all other places it's quite easy to match allocations
and
AG> >> deallocations. But in L2ARC it is not obvious that all buffers get
freed or
AG> >> when that happens.
AG> >
AG> > After one week under load I think we figure out the cause: it's L2ARC.
AG> > Here's the top's header for 7d17h of the runtime:
AG> >
AG> > last pid: 46409; load averages: 0.37, 0.62, 0.70 up 7+17:14:01
07:24:10
AG> > 173 processes: 1 running, 171 sleeping, 1 zombie
AG> > CPU: 2.0% user, 0.0% nice, 3.5% system, 0.4% interrupt, 94.2% idle
AG> > Mem: 8714M Active, 14G Inact, 96G Wired, 1929M Cache, 3309M Buf, 3542M
Free
AG> > ARC: 85G Total, 2558M MFU, 77G MRU, 28M Anon, 1446M Header, 4802M Other
AG> >
AG> > ARC related tunables:
AG> >
AG> > vm.kmem_size="110G"
AG> > vfs.zfs.arc_max="90G"
AG> > vfs.zfs.arc_min="42G"
AG> >
AG> > For more than 7 days of hard runtime the picture clearly shows:
AG> > Wired minus ARC = 11..12Gb, ARC grow and shrinks in 80-87Gb range and the
AG> > system runs just fine.
AG> >
AG> > So what shall we do with L2ARC leakage ?
AG>
AG>
AG> Could you please try this patch
AG> http://cr.illumos.org/~webrev/skiselkov/3995/illumos-gate.patch ?
AG>
While applying path to curent version of arc.c (r260622) I'm found next truble
with compilation
olaris/uts/common/fs/zfs/arc.c -o arc.o
/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4628:18:
error: use of
undeclared identifier 'abl2'
trim_map_free(abl2->b_dev->l2ad_vdev, abl2->b_daddr,
^
1 error generated.
*** Error code 1
the code is -
if (zio->io_error != 0) {
/*
* Error - drop L2ARC entry.
*/
list_remove(buflist, ab);
ARCSTAT_INCR(arcstat_l2_asize, -l2hdr->b_asize);
ab->b_l2hdr = NULL;
trim_map_free(abl2->b_dev->l2ad_vdev, abl2->b_daddr,
ab->b_size, 0);
kmem_free(l2hdr, sizeof (l2arc_buf_hdr_t));
ARCSTAT_INCR(arcstat_l2_size, -ab->b_size);
}
Looks like it's part is freebsd specific changes.
Can somebody help with this part of code ?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)
on 15/01/2014 12:28 Vitalij Satanivskij said the following:
> Dear Andriy and FreeBSD community,
>
> Andriy Gapon wrote:
> AG> on 14/01/2014 07:27 Vladimir Sharun said the following:
> AG> > Dear Andriy and FreeBSD community,
> AG> >
> AG> >> I am not sure if the buffers are leaked somehow or if they are
> actually in use.
> AG> >> It's one of the very few places where data buffers are allocated
> without
> AG> >> charging ARC. In all other places it's quite easy to match
> allocations and
> AG> >> deallocations. But in L2ARC it is not obvious that all buffers get
> freed or
> AG> >> when that happens.
> AG> >
> AG> > After one week under load I think we figure out the cause: it's L2ARC.
> AG> > Here's the top's header for 7d17h of the runtime:
> AG> >
> AG> > last pid: 46409; load averages: 0.37, 0.62, 0.70 up 7+17:14:01
> 07:24:10
> AG> > 173 processes: 1 running, 171 sleeping, 1 zombie
> AG> > CPU: 2.0% user, 0.0% nice, 3.5% system, 0.4% interrupt, 94.2% idle
> AG> > Mem: 8714M Active, 14G Inact, 96G Wired, 1929M Cache, 3309M Buf, 3542M
> Free
> AG> > ARC: 85G Total, 2558M MFU, 77G MRU, 28M Anon, 1446M Header, 4802M Other
> AG> >
> AG> > ARC related tunables:
> AG> >
> AG> > vm.kmem_size="110G"
> AG> > vfs.zfs.arc_max="90G"
> AG> > vfs.zfs.arc_min="42G"
> AG> >
> AG> > For more than 7 days of hard runtime the picture clearly shows:
> AG> > Wired minus ARC = 11..12Gb, ARC grow and shrinks in 80-87Gb range and
> the
> AG> > system runs just fine.
> AG> >
> AG> > So what shall we do with L2ARC leakage ?
> AG>
> AG>
> AG> Could you please try this patch
> AG> http://cr.illumos.org/~webrev/skiselkov/3995/illumos-gate.patch ?
> AG>
>
> While applying path to curent version of arc.c (r260622) I'm found next
> truble with compilation
>
> olaris/uts/common/fs/zfs/arc.c -o arc.o
> /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4628:18:
> error: use of
> undeclared identifier 'abl2'
> trim_map_free(abl2->b_dev->l2ad_vdev, abl2->b_daddr,
> ^
> 1 error generated.
> *** Error code 1
>
>
> the code is -
>
> if (zio->io_error != 0) {
> /*
> * Error - drop L2ARC entry.
> */
> list_remove(buflist, ab);
> ARCSTAT_INCR(arcstat_l2_asize, -l2hdr->b_asize);
> ab->b_l2hdr = NULL;
> trim_map_free(abl2->b_dev->l2ad_vdev, abl2->b_daddr,
> ab->b_size, 0);
> kmem_free(l2hdr, sizeof (l2arc_buf_hdr_t));
> ARCSTAT_INCR(arcstat_l2_size, -ab->b_size);
> }
>
>
> Looks like it's part is freebsd specific changes.
> Can somebody help with this part of code ?
>
The first hunk of the patch is renaming of abl2 to l2hdr.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)
Dear Andriy and FreeBSD community, AG> AG> The first hunk of the patch is renaming of abl2 to l2hdr. AG> So it.s ok just change trim_map_free(abl2->b_dev->l2ad_vdev, abl2->b_daddr, ab->b_size, 0); to trim_map_free(l2hdr->b_dev->l2ad_vdev, l2hdr->b_daddr, ab->b_size, 0); ? Ok. Thank you. I will try this patch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Regression on 10-RC5 with a multicast routing daemon
Olivier, On Tue, Jan 14, 2014 at 05:51:53PM +0100, Olivier Cochard-Labbé wrote: O> I'm trying to port a PIM sparse-mode daemon ( O> https://github.com/troglobit/pimd/) and I've meet a problem: O> This daemon compile and run fine on FreeBSD 9.2 but on 10-RC5 this daemon O> can't understand received multicast packets (received from other PIM O> neighbors) and display this kind of error message in debug mode "warning - O> Received packet from 10.0.12.2 shorter (28 bytes) than hdr+data length O> (20+28)". O> How to troubleshoot this problem ? O> O> My current work of this port can be tested with theses commands: O> O> cd /usr/ports O> fetch -o ports.pimd.shar " O> https://sourceforge.net/p/bsdrp/code/HEAD/tree/trunk/BSDRP/patches/ports.pimd.shar?format=raw O> " O> sh ./ports.pimd.shar O> cd net/pimd O> make install TL;DR version: you need not subtract iphdrlen in 10.0. Code in igmp.c:accept_igmp() should be smth like: iphdrlen = ip->ip_hl << 2; #ifdef RAW_INPUT_IS_RAW /* Linux */ ipdatalen = ntohs(ip->ip_len) - iphdrlen; #else #if __FreeBSD_version >= 100 ipdatalen = ip->ip_len - iphdrlen; #else ipdatalen = ip->ip_len; #endif #endif You can also look into quagga sources, file ospfd/ospf_packet.c, for more examples of workarounds for this API mess. Long story is the following. Historical behaviour of BSD raw sockets were the following: * packet is modified - packets' ip_len and ip_off are converted to host byte order - packets' ip_len is reduced by the actual size of IP header This is an artefact from the fact that the kernel stack modified every packet at the very beginning of its processing, and worked with it in this form. It just didn't bother to convert it before passing to raw socket, so raw socket wasn't truly _raw_. This is actually a bug. Later, most non-BSD operating systems defined the following API for raw sockets: * packet is passed unmodified btw, I find this much better behavior. Later, right before 9.0-RELEASE, in r226105 (merged to stable/9 as r226299) Andre has changed behaviour to: * packet is modified - packets' ip_len and ip_off are converted to host byte order This appeared a huge disaster to a number of ports, thus it was backed out in r227423 in stable/9. However this remained in head. We decided that all ports should be fixed during two years up to 10.0-RELEASE. Later on, there is a trend for BSD systems to convert their IP stacks to stop modifying byte order internally in kernel. But the compatibility for the raw sockets remained. This is what I did in FreeBSD in r241913 and in r241923. Right now, looking behind, it seems to me that we should have convert raw sockets to be truly raw, like in Linux, right in the 10-release cycle. The API mess should be reduced. According to comments in quagga, DragonFly has the following behavior: * packet is modified - packets' ip_len is reduced by the actual size of IP header Damn, what a mess. I'd like to go towards absolutely unmodified packets for the 11-release cycle. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld fails with "Zero byte read from file, skipping rest of line"
On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote: > Jeremie, > > On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote: > J> > J> ===> gnu/usr.bin/groff/src/libs/libgroff (all) > J> > J> make[6]: > "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" > line 3: warning: Zero byte read from file, skipping rest of line. > J> > J> make[6]: > "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" > line 3: Need an operator > J> > J> make[6]: > "/usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend" > line 4: Need an operator > J> > J> make[6]: Fatal errors encountered -- cannot continue > J> > J> make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff > J> > J> *** [all] Error code 1 > J> > J> > J> > J> Typscript available here: > J> > J> http://people.freebsd.org/~jlh/typescript.buildworld.txt > J> > J> > J> > J> Any ideas? > J> > > J> > Can you try to reproduce this with unmapped I/O turned off in boot > loader? > J> > J> I've never heard of that. Can you please point me to the right > J> code/doc? > > In loader prompt: > > OK set vfs.unmapped_buf_allowed=0 > OK boot No, unfortunately I still have the same problem without unmapped bufs. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT] xboxfb with vt(9) (a.k.a. newcons)
Hello friends! I've just committed update to xboxfb driver for vt(9). But I have no HW to test on. So if anybody have HW and time/wish to test it, please help me. What you need to do that: 1. Update sources to latest HEAD; 2. In XBOX kernel config file replace that devices: -device xboxfb -device sc -device fb with those: +device vt_xboxfb +device vt +device fbd 3. rebuild/reinstall your kernel. Thanks a lot! WBW -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Regression on 10-RC5 with a multicast routing daemon
On 15 January 2014 03:34, Gleb Smirnoff wrote: [snip] > Damn, what a mess. I'd like to go towards absolutely unmodified packets > for the 11-release cycle. Well, now's the time to _start_ this. :-) Not 6 months before 11.0 :P -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT] xboxfb with vt(9) (a.k.a. newcons)
Hello there, On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko wrote: > I've just committed update to xboxfb driver for vt(9). But I have no HW > to test on. So if anybody have HW and time/wish to test it, please help > me. As I also mentioned to you privately, I think it might actually be wiser to just drop Xbox support entirely. The Xbox support was a funny thing back then, but I suspect it has actually outlived its usefulness. The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a 10 GB harddisk. I don't think there are that many people left who want to run FreeBSD 11 on it. Thoughts? Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] xboxfb with vt(9) (a.k.a. newcons)
On Wed, 15 Jan 2014 23:35:39 + Ed Schouten wrote: > Hello there, > > On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko > wrote: > > > I've just committed update to xboxfb driver for vt(9). But I have > > no HW to test on. So if anybody have HW and time/wish to test it, > > please help me. > > > As I also mentioned to you privately, I think it might actually be > wiser to just drop Xbox support entirely. The Xbox support was a > funny thing back then, but I suspect it has actually outlived its > usefulness. > > The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a > 10 GB harddisk. I don't think there are that many people left who > want to run FreeBSD 11 on it. > > Thoughts? > > Ed Hi folks! Ed, Raspberry-Pi has more RAM, almost same CPU clock and no HDD at all and people use it :) Since it already in HEAD I would prefer to left it here for some time. So other will be able to use it as example. But even for that better to know if it works, to not waste time of users or hackers who will try to use it. :) Thanks! WBW -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mtree acl support
On Jan 15, 2014, at 9:11 PM, Tim Kientzle wrote: > > On Jan 14, 2014, at 6:47 AM, Mark Felder wrote: > >> I was recently talking to someone about how one would backup / restore >> ACLs reliably. I didn't see any mention of ACLs in the mtree man page >> and after a quick google I came upon this old mailing list post: >> >> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html >> >> patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff >> I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff >> >> This old patch appears to still apply cleanly. I hate to see a patch die >> and be forgotten. > > One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s > work on star) is to permit ACLs to be restored even if the user database > is out of date. > > This is done by including a fourth field in each ACE with the > numeric user ID. > > I suspect you want to do the same for mtree. I thought > I remembered acl_to_text having an option to use > an extended text format, so it might be a trivial change. Also, comparing ACLs using strcmp() seems a little odd to me. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mtree acl support
On Jan 14, 2014, at 6:47 AM, Mark Felder wrote: > I was recently talking to someone about how one would backup / restore > ACLs reliably. I didn't see any mention of ACLs in the mtree man page > and after a quick google I came upon this old mailing list post: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html > > patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff > I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff > > This old patch appears to still apply cleanly. I hate to see a patch die > and be forgotten. One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s work on star) is to permit ACLs to be restored even if the user database is out of date. This is done by including a fourth field in each ACE with the numeric user ID. I suspect you want to do the same for mtree. I thought I remembered acl_to_text having an option to use an extended text format, so it might be a trivial change. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
