Re: 8.0-RELEASE -> -STABLE and size of /

[Randi Harper]

On Fri, Jan 22, 2010 at 8:27 AM, Marian Hettwer  wrote:
> Hi All,
>
> On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller 
> wrote:
>> Hi,
>>
>> I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default
>> 512M. First step after setup was to csup to RELENG_8 and buildkernel and
>> buildworld (no custom kernel, no make.conf).
>>
>> Instaling the new kernel failed, since /boot/kernel/ is already well
>> over 230 MBytes in size. moving that to kernel.old and writing a new one
>> with about the same size fails due to no space left on device.
>>
>> This is not a question; I do know how to get around this and how to
>> configure custom kernels so they are a fragment of that size afterwards.
>> However, I think this is a clear POLA violation. So, either GENERIC with
>> less debugging information (symbols and stuff), which makes debugging
>> harder or setting a higher default for / would be options, if not anyone
>> else has better ideas.
>>
> +1 vote for making / bigger.
> At least a size where a make installkernel runs through.
>
> I like FreeBSD because it honors POLA.
> And as Oliver stated, this is a clear POLA violation.
>
> Cheers,
> Marian
>
> ___
> 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"
>

This is going to happen. It's been on my to-do list for a while, as I
find it increasingly annoying. The default sizes of all mount points
need to be tweaked a bit. Be patient, there will be some new changes
going into sysinstall very soon.

-- randi
___
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: ionice in FreeBSD?

[Daniel O'Connor]

On Wed, 3 Feb 2010, Jordi Espasa Clofent wrote:
> In Linux exists the ionice(1) for "get/set program io scheduling
> class and priority".
>
> In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if
> I'm understanding correctly, they're related to CPU priorty only, not
> to I/O.
>
> ¿Is there some ionice(1) equivalent in FreeBSD?

There is no IO scheduler in FreeBSD outside of some experimental patches 
at 
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-01/msg00316.html

(I have no idea of their status)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


signature.asc
Description: This is a digitally signed message part.

Re: ionice in FreeBSD?

[Andrew Snow]

Jordi Espasa Clofent wrote:


¿Is there some ionice(1) equivalent in FreeBSD?


No.

- Andrew

___
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 probe order issues

[Peter Jeremy]

On 2010-Feb-02 08:39:34 +0200, Andriy Gapon  wrote:
>on 02/02/2010 08:36 Peter Jeremy said the following:
>> On 2010-Feb-01 11:37:33 +0200, Andriy Gapon  wrote:
 This strikes me as undesirable.  Is there some way to bump up the
 probe/attach priority of console input devices to ensure that they
 exist before the kernel tries to read input?
>>> It seems to be a problem with either your keyboard or your USB controller.
>>> USB keyboard can be discovered much earlier than mountroot if the hardware 
>>> is
>>> ready.  No magical software priority bump can help here.
>> 
>> I've tried a couple of different USB ports (controllers) with no
>> change in behaviour.  I'll try another keyboard if I can find one.  It
>> _does_ work as expected on 7.x so this is a regression.
>
>Unfortunately you keep being low on hardware details.

Sorry.  The box is a Dell GX620 (P4 with ICH7 chipset).  The keyboard
is a Dell SK-8115 connected directly to a motherboard port.  I've also
tried a Dell SK-8135 (which is the "multimedia" variant and has a
builtin hub) which behaves the same.

I've uploaded full details as follows:
FreeBSD 7.x verbose dmesg:  http://pastebin.ca/1776339
FreeBSD 8.x verbose dmesg:  http://pastebin.ca/1776359
"pciconf -lv" (same in 7 & 8):  http://pastebin.ca/1776363

The output from 'usbdevs -v' on FreeBSD 7 is:
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
 port 1 powered
 port 2 addr 2: low speed, power 70 mA, config 1, Dell USB Keyboard(0x2003), 
Dell(0x413c), rev 2.00
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
 port 1 powered
 port 2 powered
Controller /dev/usb4:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 powered

And the output from "usbconfig list" on FreeBSD 8 is:
ugen0.1:  at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1:  at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1:  at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1:  at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1:  at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=ON
ugen2.2:  at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) 
pwr=ON

The alternate keyboard shows up as:
 port 2 addr 2: full speed, power 100 mA, config 1, Dell USB Keyboard 
Hub(0x1003), Dell(0x413c), rev 2.00
  port 1 addr 3: full speed, power 50 mA, config 1, Dell USB Keyboard(0x2010), 
Dell(0x413c), rev 2.00
  port 2 addr 4: low speed, power 100 mA, config 1, product 0x3010(0x3010), 
vendor 0x413c(0x413c), rev 2.30
  port 3 powered

-- 
Peter Jeremy


pgpBEzGRR2Wy6.pgp
Description: PGP signature

Re: 8.0 install fails to create filesystem ("unable to find device node")

[Vitaly Magerya]

Jeremy Chadwick wrote:
>> Yes, ad0s1b is the swap, but I think it fails before doing newfs.
>> "Writing partition information to ad0" is the last message I see before
>> the error occurs, no newfs popups occur.

By the way, in the fixit console /dev has ad0b but not ad0s1b.

> Can you get this disk into a system (or the same system if booting off
> CD, etc.) where you can do the following to it and then retry the
> installation?
> 
> dd if=/dev/zero of=/dev/ad0 bs=64k count=1
> 
> No, this isn't a joke.  This should also clear up the GEOM label
> error/warning you see.

Yay, that did the trick.

I installed 8.0 into a usb flash and cleaned ad0 from there. The setup
successfully created the filesystems and is copying files right now.

Thank you! I hope that sysinstall will be able to recognize this
situation in future releases.
___
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: em(4) + ALTQ broken

[Jack Vogel]

Just teseted, and at least in the kernel build I'm doing its definitely
defining
that code on, hit my syntax error rebuilding em.

Jack


On Tue, Feb 2, 2010 at 2:43 PM, Jack Vogel  wrote:

> It should never get to the drbr code, look at net/if_var.h, in the inline
> definition
> of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if
> to use
> the old IFQ_DRV_DEQUEUE() method.
>
> I guess I can test the build on a system here, stick some syntax error in
> and see if it hits.
>
> Right now the inserted code looks solid enough to me, so somehow I think
> its not being defined.
>
> Jack
>
>
>
> On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon  wrote:
>
>> On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote:
>> > LOL, and I can answer my own question, I just looked and the ONLY
>> > 1Gig drivers using multiqueue are mine, so I guess not eh? :)
>> >
>>
>> I was wrong. ALTQ is defined in opt_global.h so drbr_ interface
>> should already see ALTQ. I have to look into drbr_ code.
>>
>> > J.
>> >
>> > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel  wrote:
>> >
>> > > Thanks Max, yes, i've done some digging myself and now see how things
>> > > work, the rubber meets the road in the defines in if_var.h.
>> > >
>> > > And what it does is effectively short circuit Kip Macy's multiqueue
>> code
>> > > in favor of the old method.
>> > >
>> > > Right now I can see two possibilities, either the defines are not set
>> in
>> > > the build, OR there is something wrong in the logic of the short
>> circuit
>> > > approach in Kip's code.
>> > >
>> > > A question might be if ANY driver that is usinig TX Multiqueue has
>> been
>> > > successfully used with ALTQ?
>> > >
>> > > Jack
>> > >
>> > >
>> > >
>> > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier 
>> wrote:
>> > >
>> > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
>> > >> > So apparently this thing needs no special knowledge in the driver,
>> yet
>> > >> > something in
>> > >> > the new code breaks it, can someone explain tersely how the altq
>> app
>> > >> > actually
>> > >> > "pokes" or "hooks up" to the driver? I am not clear about that and
>> I
>> > >> >  suspect if I was
>> > >> > this would all be clearer.
>> > >>
>> > >> The whole story is in
>> > >>
>> > >>  man 9 altq
>> > >>
>> > >> long story short, as long as you consistently use the IFQ_* macros to
>> > >> manage
>> > >> the interface queue, things should just work.  if_var.h used to
>> > >> conditionally
>> > >> define these macros to avoid ALTQ overhead when the kernel is built
>> > >> without
>> > >> ALTQ.  This has changed a long time ago and should not make any
>> difference
>> > >> anymore.
>> > >>
>> > >> I can't figure out who the OP is, but could you make sure that the
>> > >> includes
>> > >> that are used to built the kernel are up to date?  You are building
>> with
>> > >> the
>> > >> buildkernel target and not "the old way", right?  Also, if you build
>> just
>> > >> the
>> > >> module, the build might pick up the includes from /usr/include
>> instead of
>> > >> src/sys ...
>> > >>
>> > >> > Jack
>> > >> >
>> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon 
>> > >> wrote:
>> > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
>> > >> > > > > I guess the problem comes from multi-queue support. The drbr
>> > >> > > > > interface is implemented with inline function so em(4)/igb(4)
>> may
>> > >> > > > > have to define ALTQ to the header. I have not tested the
>> patch(no
>> > >> > > > > time at this moment) but would you give it try?
>> > >> > > > >
>> > >> > > > > I tried the patch and it did not work.
>> > >> > >
>> > >> > > You rebuilt kernel, right? Rebuilding kernel module has no
>> effect.
>> > >> >
>> > >> > ___
>> > >> > 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"
>> > >> >
>> > >> >
>> > >> > !DSPAM:4b686584144321871135632!
>> > >> >
>> > >>
>> > >
>> > >
>>
>
>
___
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: em(4) + ALTQ broken

[Jack Vogel]

It should never get to the drbr code, look at net/if_var.h, in the inline
definition
of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if to
use
the old IFQ_DRV_DEQUEUE() method.

I guess I can test the build on a system here, stick some syntax error in
and see if it hits.

Right now the inserted code looks solid enough to me, so somehow I think
its not being defined.

Jack


On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon  wrote:

> On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote:
> > LOL, and I can answer my own question, I just looked and the ONLY
> > 1Gig drivers using multiqueue are mine, so I guess not eh? :)
> >
>
> I was wrong. ALTQ is defined in opt_global.h so drbr_ interface
> should already see ALTQ. I have to look into drbr_ code.
>
> > J.
> >
> > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel  wrote:
> >
> > > Thanks Max, yes, i've done some digging myself and now see how things
> > > work, the rubber meets the road in the defines in if_var.h.
> > >
> > > And what it does is effectively short circuit Kip Macy's multiqueue
> code
> > > in favor of the old method.
> > >
> > > Right now I can see two possibilities, either the defines are not set
> in
> > > the build, OR there is something wrong in the logic of the short
> circuit
> > > approach in Kip's code.
> > >
> > > A question might be if ANY driver that is usinig TX Multiqueue has been
> > > successfully used with ALTQ?
> > >
> > > Jack
> > >
> > >
> > >
> > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier  wrote:
> > >
> > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
> > >> > So apparently this thing needs no special knowledge in the driver,
> yet
> > >> > something in
> > >> > the new code breaks it, can someone explain tersely how the altq app
> > >> > actually
> > >> > "pokes" or "hooks up" to the driver? I am not clear about that and I
> > >> >  suspect if I was
> > >> > this would all be clearer.
> > >>
> > >> The whole story is in
> > >>
> > >>  man 9 altq
> > >>
> > >> long story short, as long as you consistently use the IFQ_* macros to
> > >> manage
> > >> the interface queue, things should just work.  if_var.h used to
> > >> conditionally
> > >> define these macros to avoid ALTQ overhead when the kernel is built
> > >> without
> > >> ALTQ.  This has changed a long time ago and should not make any
> difference
> > >> anymore.
> > >>
> > >> I can't figure out who the OP is, but could you make sure that the
> > >> includes
> > >> that are used to built the kernel are up to date?  You are building
> with
> > >> the
> > >> buildkernel target and not "the old way", right?  Also, if you build
> just
> > >> the
> > >> module, the build might pick up the includes from /usr/include instead
> of
> > >> src/sys ...
> > >>
> > >> > Jack
> > >> >
> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon 
> > >> wrote:
> > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > >> > > > > I guess the problem comes from multi-queue support. The drbr
> > >> > > > > interface is implemented with inline function so em(4)/igb(4)
> may
> > >> > > > > have to define ALTQ to the header. I have not tested the
> patch(no
> > >> > > > > time at this moment) but would you give it try?
> > >> > > > >
> > >> > > > > I tried the patch and it did not work.
> > >> > >
> > >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect.
> > >> >
> > >> > ___
> > >> > 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"
> > >> >
> > >> >
> > >> > !DSPAM:4b686584144321871135632!
> > >> >
> > >>
> > >
> > >
>
___
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: em(4) + ALTQ broken

[Pyun YongHyeon]

On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote:
> LOL, and I can answer my own question, I just looked and the ONLY
> 1Gig drivers using multiqueue are mine, so I guess not eh? :)
> 

I was wrong. ALTQ is defined in opt_global.h so drbr_ interface
should already see ALTQ. I have to look into drbr_ code.

> J.
> 
> On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel  wrote:
> 
> > Thanks Max, yes, i've done some digging myself and now see how things
> > work, the rubber meets the road in the defines in if_var.h.
> >
> > And what it does is effectively short circuit Kip Macy's multiqueue code
> > in favor of the old method.
> >
> > Right now I can see two possibilities, either the defines are not set in
> > the build, OR there is something wrong in the logic of the short circuit
> > approach in Kip's code.
> >
> > A question might be if ANY driver that is usinig TX Multiqueue has been
> > successfully used with ALTQ?
> >
> > Jack
> >
> >
> >
> > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier  wrote:
> >
> >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
> >> > So apparently this thing needs no special knowledge in the driver, yet
> >> > something in
> >> > the new code breaks it, can someone explain tersely how the altq app
> >> > actually
> >> > "pokes" or "hooks up" to the driver? I am not clear about that and I
> >> >  suspect if I was
> >> > this would all be clearer.
> >>
> >> The whole story is in
> >>
> >>  man 9 altq
> >>
> >> long story short, as long as you consistently use the IFQ_* macros to
> >> manage
> >> the interface queue, things should just work.  if_var.h used to
> >> conditionally
> >> define these macros to avoid ALTQ overhead when the kernel is built
> >> without
> >> ALTQ.  This has changed a long time ago and should not make any difference
> >> anymore.
> >>
> >> I can't figure out who the OP is, but could you make sure that the
> >> includes
> >> that are used to built the kernel are up to date?  You are building with
> >> the
> >> buildkernel target and not "the old way", right?  Also, if you build just
> >> the
> >> module, the build might pick up the includes from /usr/include instead of
> >> src/sys ...
> >>
> >> > Jack
> >> >
> >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon 
> >> wrote:
> >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> >> > > > > I guess the problem comes from multi-queue support. The drbr
> >> > > > > interface is implemented with inline function so em(4)/igb(4) may
> >> > > > > have to define ALTQ to the header. I have not tested the patch(no
> >> > > > > time at this moment) but would you give it try?
> >> > > > >
> >> > > > > I tried the patch and it did not work.
> >> > >
> >> > > You rebuilt kernel, right? Rebuilding kernel module has no effect.
> >> >
> >> > ___
> >> > 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"
> >> >
> >> >
> >> > !DSPAM:4b686584144321871135632!
> >> >
> >>
> >
> >
___
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: 8.0 install fails to create filesystem ("unable to find device node")

[Jeremy Chadwick]

On Tue, Feb 02, 2010 at 11:58:11PM +0200, Vitaly Magerya wrote:
> Kevin Oberman wrote:
> >> The setup tries to create filesystem and fails with this message:
> >>
> >> Unable to find device node for /dev/ad0s1b in /dev!
> > 
> > Are you doing a 'W'rite in the labeling tools? I'm guess that you are
> > not, but I wanted to be sure. You don't want to.
> 
> Nope, no write.
> 
> > You say that you are doing the default partitions. If so, the 'b'
> > partition should be swap. It should not get 'newfs'ed. No file system
> > needed (or wanted) there. This tells me that something was wrong in the
> > partition setup if it THINKS that there is a need to newfs partition
> > 'b'. 
> 
> Yes, ad0s1b is the swap, but I think it fails before doing newfs.
> "Writing partition information to ad0" is the last message I see before
> the error occurs, no newfs popups occur.
> 
> >> Aside from debug messages, there's this on second VT:
> >>
> >> GEOM: ad0: geometry does not match label (255h,63s != 16h,63s).
> > 
> > This is a known issue, but cosmetic in almost all cases.
> 
> OK, good.
> 
> > I suspect that you are doing something wrong, but it's hard to figure
> > out just what it might be.
> 
> Anything I can do to see what's the problem?

Can you get this disk into a system (or the same system if booting off
CD, etc.) where you can do the following to it and then retry the
installation?

dd if=/dev/zero of=/dev/ad0 bs=64k count=1

No, this isn't a joke.  This should also clear up the GEOM label
error/warning you see.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: 8.0 install fails to create filesystem ("unable to find device node")

[Vitaly Magerya]

Kevin Oberman wrote:
>> The setup tries to create filesystem and fails with this message:
>>
>> Unable to find device node for /dev/ad0s1b in /dev!
> 
> Are you doing a 'W'rite in the labeling tools? I'm guess that you are
> not, but I wanted to be sure. You don't want to.

Nope, no write.

> You say that you are doing the default partitions. If so, the 'b'
> partition should be swap. It should not get 'newfs'ed. No file system
> needed (or wanted) there. This tells me that something was wrong in the
> partition setup if it THINKS that there is a need to newfs partition
> 'b'. 

Yes, ad0s1b is the swap, but I think it fails before doing newfs.
"Writing partition information to ad0" is the last message I see before
the error occurs, no newfs popups occur.

>> Aside from debug messages, there's this on second VT:
>>
>> GEOM: ad0: geometry does not match label (255h,63s != 16h,63s).
> 
> This is a known issue, but cosmetic in almost all cases.

OK, good.

> I suspect that you are doing something wrong, but it's hard to figure
> out just what it might be.

Anything I can do to see what's the problem?
___
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: em(4) + ALTQ broken

[Jack Vogel]

LOL, and I can answer my own question, I just looked and the ONLY
1Gig drivers using multiqueue are mine, so I guess not eh? :)

J.

On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel  wrote:

> Thanks Max, yes, i've done some digging myself and now see how things
> work, the rubber meets the road in the defines in if_var.h.
>
> And what it does is effectively short circuit Kip Macy's multiqueue code
> in favor of the old method.
>
> Right now I can see two possibilities, either the defines are not set in
> the build, OR there is something wrong in the logic of the short circuit
> approach in Kip's code.
>
> A question might be if ANY driver that is usinig TX Multiqueue has been
> successfully used with ALTQ?
>
> Jack
>
>
>
> On Tue, Feb 2, 2010 at 12:37 PM, Max Laier  wrote:
>
>> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
>> > So apparently this thing needs no special knowledge in the driver, yet
>> > something in
>> > the new code breaks it, can someone explain tersely how the altq app
>> > actually
>> > "pokes" or "hooks up" to the driver? I am not clear about that and I
>> >  suspect if I was
>> > this would all be clearer.
>>
>> The whole story is in
>>
>>  man 9 altq
>>
>> long story short, as long as you consistently use the IFQ_* macros to
>> manage
>> the interface queue, things should just work.  if_var.h used to
>> conditionally
>> define these macros to avoid ALTQ overhead when the kernel is built
>> without
>> ALTQ.  This has changed a long time ago and should not make any difference
>> anymore.
>>
>> I can't figure out who the OP is, but could you make sure that the
>> includes
>> that are used to built the kernel are up to date?  You are building with
>> the
>> buildkernel target and not "the old way", right?  Also, if you build just
>> the
>> module, the build might pick up the includes from /usr/include instead of
>> src/sys ...
>>
>> > Jack
>> >
>> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon 
>> wrote:
>> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
>> > > > > I guess the problem comes from multi-queue support. The drbr
>> > > > > interface is implemented with inline function so em(4)/igb(4) may
>> > > > > have to define ALTQ to the header. I have not tested the patch(no
>> > > > > time at this moment) but would you give it try?
>> > > > >
>> > > > > I tried the patch and it did not work.
>> > >
>> > > You rebuilt kernel, right? Rebuilding kernel module has no effect.
>> >
>> > ___
>> > 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"
>> >
>> >
>> > !DSPAM:4b686584144321871135632!
>> >
>>
>
>
___
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: em(4) + ALTQ broken

[Jack Vogel]

Thanks Max, yes, i've done some digging myself and now see how things
work, the rubber meets the road in the defines in if_var.h.

And what it does is effectively short circuit Kip Macy's multiqueue code
in favor of the old method.

Right now I can see two possibilities, either the defines are not set in
the build, OR there is something wrong in the logic of the short circuit
approach in Kip's code.

A question might be if ANY driver that is usinig TX Multiqueue has been
successfully used with ALTQ?

Jack


On Tue, Feb 2, 2010 at 12:37 PM, Max Laier  wrote:

> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
> > So apparently this thing needs no special knowledge in the driver, yet
> > something in
> > the new code breaks it, can someone explain tersely how the altq app
> > actually
> > "pokes" or "hooks up" to the driver? I am not clear about that and I
> >  suspect if I was
> > this would all be clearer.
>
> The whole story is in
>
>  man 9 altq
>
> long story short, as long as you consistently use the IFQ_* macros to
> manage
> the interface queue, things should just work.  if_var.h used to
> conditionally
> define these macros to avoid ALTQ overhead when the kernel is built without
> ALTQ.  This has changed a long time ago and should not make any difference
> anymore.
>
> I can't figure out who the OP is, but could you make sure that the includes
> that are used to built the kernel are up to date?  You are building with
> the
> buildkernel target and not "the old way", right?  Also, if you build just
> the
> module, the build might pick up the includes from /usr/include instead of
> src/sys ...
>
> > Jack
> >
> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon  wrote:
> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > > > I guess the problem comes from multi-queue support. The drbr
> > > > > interface is implemented with inline function so em(4)/igb(4) may
> > > > > have to define ALTQ to the header. I have not tested the patch(no
> > > > > time at this moment) but would you give it try?
> > > > >
> > > > > I tried the patch and it did not work.
> > >
> > > You rebuilt kernel, right? Rebuilding kernel module has no effect.
> >
> > ___
> > 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
> "
> >
> >
> > !DSPAM:4b686584144321871135632!
> >
>
___
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: 8.0 install fails to create filesystem ("unable to find device node")

[Kevin Oberman]

> Date: Tue, 02 Feb 2010 21:29:26 +0200
> From: Vitaly Magerya 
> Sender: owner-freebsd-sta...@freebsd.org
> 
> Greetings everyone. I'm trying to install FreeBSD 8.0 from Disk1 on
> ThinkPad T40, so far unsuccessfully.
> 
> Here are the setup steps:
> Installer complains that "77520/16/63" may not be a good geometry for
> ad0, proposes "4864/255/63" instead (both eventually lead to failure).
> I create a single disk-wide slice (ad0s1), choose a boot manager, set up
> standard labeling for ad0s1, choose distributions.
> 
> The setup tries to create filesystem and fails with this message:
> 
> Unable to find device node for /dev/ad0s1b in /dev!

Are you doing a 'W'rite in the labeling tools? I'm guess that you are
not, but I wanted to be sure. You don't want to.

You say that you are doing the default partitions. If so, the 'b'
partition should be swap. It should not get 'newfs'ed. No file system
needed (or wanted) there. This tells me that something was wrong in the
partition setup if it THINKS that there is a need to newfs partition
'b'. 

> Aside from debug messages, there's this on second VT:
> 
> GEOM: ad0: geometry does not match label (255h,63s != 16h,63s).

This is a known issue, but cosmetic in almost all cases.

I suspect that you are doing something wrong, but it's hard to figure
out just what it might be.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
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: 8-STABLE outgoing scp stalling frequently.

[Mike Tancsa]

At 04:09 PM 2/2/2010, Adam Vande More wrote:
On Tue, Feb 2, 2010 at 2:51 PM, Jonathan Chen 
<j...@chen.org.nz> wrote:

The 2 hosts are going in on cables to the same switch. I've tried
other ports and hosts , but experience the same problem.


I run a similar network setup at home, and am unable to replicate 
your experience regardless which host is being copied 
to/from.  Perhaps you have a more specific issue eg nic driver ?


This is to a box on the same ethernet and subnet

0(ich10)% dd if=/dev/urandom of=testfile bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 1.879028 secs (55804169 bytes/sec)
0(ich10)% scp testfile 192.168.1.207:/dev/null
testfile 
100%  100MB  12.5MB/s   00:08

0(ich10)% scp -C testfile 192.168.1.207:/dev/null
testfile 
100%  100MB  11.1MB/s   00:09

0(ich10)%

From RELENG_8 to RELENG_7

em0: flags=8843 metric 0 mtu 1500
options=19b
ether 00:1c:c0:95:0d:0d
inet 192.168.1.219 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX )
status: active

uname -a
FreeBSD ich10.sentex.ca 8.0-STABLE FreeBSD 8.0-STABLE #13: Tue Jan 19 
12:24:57 EST 
2010 mdtan...@ich10.sentex.ca:/usr/obj/usr/src/sys/server  i386


If you are using an em nic, does
sysctl -w dev.em.0.stats=1
give any interesting numbers in /var/log/messages ?
em0: Excessive collisions = 0
em0: Sequence errors = 0
em0: Defer count = 0
em0: Missed Packets = 0
em0: Receive No Buffers = 0
em0: Receive Length Errors = 0
em0: Receive errors = 0
em0: Crc errors = 0
em0: Alignment errors = 0
em0: Collision/Carrier extension errors = 0
em0: RX overruns = 0
em0: watchdog timeouts = 0
em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0
em0: XON Rcvd = 0
em0: XON Xmtd = 0
em0: XOFF Rcvd = 0
em0: XOFF Xmtd = 0
em0: Good Packets Rcvd = 1003041
em0: Good Packets Xmtd = 690690
em0: TSO Contexts Xmtd = 15709
em0: TSO Contexts Failed = 0


Results from RELENG_8 to RELENG_9 are about the same, but on a different nic

0(ich10)% scp  testfile 10.255.255.117:/dev/null
testfile 
100%  100MB  11.1MB/s   00:09

0(ich10)%
igb1: Excessive collisions = 0
igb1: Sequence errors = 0
igb1: Defer count = 0
igb1: Missed Packets = 0
igb1: Receive No Buffers = 0
igb1: Receive Length Errors = 0
igb1: Receive errors = 0
igb1: Crc errors = 0
igb1: Alignment errors = 0
igb1: Collision/Carrier extension errors = 0
igb1: RX overruns = 0
igb1: watchdog timeouts = 0
igb1: XON Rcvd = 0
igb1: XON Xmtd = 0
igb1: XOFF Rcvd = 0
igb1: XOFF Xmtd = 0
igb1: Good Packets Rcvd = 36484881
igb1: Good Packets Xmtd = 50922117
igb1: TSO Contexts Xmtd = 5452450
igb1: TSO Contexts Failed = 0




--
Adam Vande More



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-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: 8-STABLE outgoing scp stalling frequently.

[Jeremy Chadwick]

On Wed, Feb 03, 2010 at 09:51:11AM +1300, Jonathan Chen wrote:
> On Tue, Feb 02, 2010 at 02:44:09PM -0500, Mike Tancsa wrote:
> > At 02:36 PM 2/2/2010, Jonathan Chen wrote:
> > >Hi,
> > >
> > >I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be
> > >stalling very frequently. This is the output from a "scp -v -v"
> > >of a 300Mb file from a local to a remote within an internal network:
> > 
> > Hi,
> > Is it on the same ethernet segment, or does it go through a 
> > router(s) and is the path asymmetric?
> 
> The 2 hosts are going in on cables to the same switch. I've tried
> other ports and hosts , but experience the same problem.

Do you see this behaviour both directions, or just unidirectional?  E.g.
does the problem happen in both of the below examples, or just one?

box1$ scp u...@box2:/file .
box1$ scp file u...@box2:/some/path

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: 8-STABLE outgoing scp stalling frequently.

[Pete French]

> I run a similar network setup at home, and am unable to replicate your
> experience regardless which host is being copied to/from.  Perhaps you have
> a more specific issue eg nic driver ?

I missed the start of this thread, but I have also seen scp stalling
on 8-STABLE, except in my case it as inbound ... i.e. uploading to
the FreeBSd machine. The client was scp on OSX, though I also saw the
same issue with rsync, leading me to belve taht the problem lies
somewhere in ssh.

In the end I just used NFS and didn't worry too much about it, but
just a "me too" to show it's not just the OP. Mu machines were also
directly connected to the same switch on the same ether.

-pete.
___
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: 8-STABLE outgoing scp stalling frequently.

[Adam Vande More]

On Tue, Feb 2, 2010 at 2:51 PM, Jonathan Chen  wrote:

> The 2 hosts are going in on cables to the same switch. I've tried
> other ports and hosts , but experience the same problem.
>

I run a similar network setup at home, and am unable to replicate your
experience regardless which host is being copied to/from.  Perhaps you have
a more specific issue eg nic driver ?


-- 
Adam Vande More
___
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: 8-STABLE outgoing scp stalling frequently.

[Jonathan Chen]

On Tue, Feb 02, 2010 at 02:44:09PM -0500, Mike Tancsa wrote:
> At 02:36 PM 2/2/2010, Jonathan Chen wrote:
> >Hi,
> >
> >I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be
> >stalling very frequently. This is the output from a "scp -v -v"
> >of a 300Mb file from a local to a remote within an internal network:
> 
> Hi,
> Is it on the same ethernet segment, or does it go through a 
> router(s) and is the path asymmetric?

The 2 hosts are going in on cables to the same switch. I've tried
other ports and hosts , but experience the same problem.
-- 
Jonathan Chen 
--
"Irrationality is the square root of all evil"
  - Douglas Hofstadter
___
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: em(4) + ALTQ broken

[Max Laier]

On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
> So apparently this thing needs no special knowledge in the driver, yet
> something in
> the new code breaks it, can someone explain tersely how the altq app
> actually
> "pokes" or "hooks up" to the driver? I am not clear about that and I
>  suspect if I was
> this would all be clearer.

The whole story is in

  man 9 altq

long story short, as long as you consistently use the IFQ_* macros to manage 
the interface queue, things should just work.  if_var.h used to conditionally 
define these macros to avoid ALTQ overhead when the kernel is built without 
ALTQ.  This has changed a long time ago and should not make any difference 
anymore.

I can't figure out who the OP is, but could you make sure that the includes 
that are used to built the kernel are up to date?  You are building with the 
buildkernel target and not "the old way", right?  Also, if you build just the 
module, the build might pick up the includes from /usr/include instead of 
src/sys ...
 
> Jack
> 
> On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon  wrote:
> > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > > I guess the problem comes from multi-queue support. The drbr
> > > > interface is implemented with inline function so em(4)/igb(4) may
> > > > have to define ALTQ to the header. I have not tested the patch(no
> > > > time at this moment) but would you give it try?
> > > >
> > > > I tried the patch and it did not work.
> >
> > You rebuilt kernel, right? Rebuilding kernel module has no effect.
> 
> ___
> 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"
> 
> 
> !DSPAM:4b686584144321871135632!
> 
___
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: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS

[Rick Macklem]

On Tue, 2 Feb 2010, alan bryan wrote:


--- On Wed, 1/6/10, Rick Macklem  wrote:



From: Rick Macklem 
Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with 
ZFS
To: "alan bryan" 
Cc: freebsd-stable@freebsd.org
Date: Wednesday, January 6, 2010, 12:19 PM


On Wed, 6 Jan 2010, alan bryan wrote:

> I have a AMD64 FreeBSD 8.0 server with ZFS filesystem
being shared via NFS.? These are being accessed by the
clients.? The clients are a mix of FreeBSD 6.2 32bit
and FreeBSD 7.0 64bit.? I have seen similar behavior
from both versions of FreeBSD as clients.
>
[stuff related to lotsa writes being done snipped]
>
> Any ideas on what to try, where to look for more
insight, etc...??
>
- Are they the same write being retried over and over?



yes - it appears so



- Is the server replying to them with an error?


yes



The above might give some insight into what's happening,


Didn't help much. The server is replying with NFS3ERR_IO (EIO) for
some reason. Unfortunately EIO is the catch all for just about
everything. (There is only one case in the NFS server code that
generates EIO and that would be caused by a bogus data mbuf list.)
As such, I suspect the EIO is coming from ZFS for some reason, but
can't be sure.

Btw, a binary capture using tcpdump can be read into wireshark, which
is much better at decoding NFS etc than tcpdump.

rick
___
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"

8.0 install fails to create filesystem ("unable to find device node")

[Vitaly Magerya]

Greetings everyone. I'm trying to install FreeBSD 8.0 from Disk1 on
ThinkPad T40, so far unsuccessfully.

Here are the setup steps:
Installer complains that "77520/16/63" may not be a good geometry for
ad0, proposes "4864/255/63" instead (both eventually lead to failure).
I create a single disk-wide slice (ad0s1), choose a boot manager, set up
standard labeling for ad0s1, choose distributions.
The setup tries to create filesystem and fails with this message:

Unable to find device node for /dev/ad0s1b in /dev!

Aside from debug messages, there's this on second VT:

GEOM: ad0: geometry does not match label (255h,63s != 16h,63s).

I also tried to setup 7.0 (w/o dangerously dedicated slicing), and then
freebsd-update to 8.0. On first reboot required by freebsd-update the
system drops to bootloader prompt and fails to find init on any of the
filesystems.

Help. Is there anything I can do to install 8.0?

The dmesg of this machine (as seen by 7.0) is at [1]. I'll provide any
further information -- just name it.

[1] http://tx97.net/~magv/dmesg-t40.70.txt
___
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: 8-STABLE outgoing scp stalling frequently.

[Mike Tancsa]

At 02:36 PM 2/2/2010, Jonathan Chen wrote:

Hi,

I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be
stalling very frequently. This is the output from a "scp -v -v"
of a 300Mb file from a local to a remote within an internal network:


Hi,
Is it on the same ethernet segment, or does it go through a 
router(s) and is the path asymmetric? I noticed similar symptoms on a 
jailed box where the round trip was asymmetric and an intermediary 
router was generating a lot of ICMP redirects that were ignored by 
the sending host.


---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

8-STABLE outgoing scp stalling frequently.

[Jonathan Chen]

Hi,

I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be
stalling very frequently. This is the output from a "scp -v -v"
of a 300Mb file from a local to a remote within an internal network:

[.. authentication negotiation ...]
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Sending file modes: C0700 367085370 file1
file10%  192KB 140.0KB/s   42:39 ETAdebug2: channel 0: rcvd adjust 
65593
file10%  256KB  78.2KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  336KB  41.6KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  416KB  26.9KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  496KB  17.1KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  576KB  12.4KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  656KB  11.3KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  736KB   9.7KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  816KB   9.9KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  896KB   9.0KB/s - stalled -debug2: channel 0: rcvd adjust 
81920
file10%  976KB   9.5KB/s - stalled -debug2: channel 0: rcvd adjust 
81920

/etc/ssh/ssh_config is untouched. Oddly enough a scp of a remote file
to the local machine is blindingly fast.

Does anyone know what's happening here? Any tips on how to track down
what the problem is? The network config appears to be fine - fetch(1) will
have downloads speeds of up to 300KB/s.

Cheers.
-- 
Jonathan Chen 
--
"With sufficient thrust, pigs fly just fine. However, this is not necessarily
a good idea. It is hard to be sure where they are going to land, and it
could be dangerous sitting under them as they fly overhead." -- RFC 1925
___
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: install root certificates

[Emil Smolenski]

On Tue, 02 Feb 2010 18:59:31 +0100, Xian Chen  wrote:


I install
/usr/ports/security/ca_root_nss and openssl but still I cannot find where
the certifications are.

Any ideas?


Try:
pkg_info -xL ca_root_nss

--
am
___
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: install root certificates

[Xian Chen]

Yes, I have this crt file. Is this one enough? I
need  UTN-USERFirst-Hardware . I do know exactly how the certification work.

thanks,

On Tue, Feb 2, 2010 at 1:56 PM, Brooks Davis  wrote:

> On Tue, Feb 02, 2010 at 12:59:31PM -0500, Xian Chen wrote:
> > Hello,
> >
> > I use 8.0 Release on my thinkpad T42 laptop and want to connect to the
> WIFI
> > AP near me.  The AP is encrypted by WPA2. I also need some root
> > certifications installed ( UTN-USERFirst-Hardware ). I install
> > /usr/ports/security/ca_root_nss and openssl but still I cannot find where
> > the certifications are.
> >
> > Any ideas?
>
> $ pkg_info -L ca_root_nss\*
> Information for ca_root_nss-3.11.9_2:
>
> Files:
> /usr/local/share/certs/ca-root-nss.crt
>
> -- Brooks
>
___
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: install root certificates

[Brooks Davis]

On Tue, Feb 02, 2010 at 12:59:31PM -0500, Xian Chen wrote:
> Hello,
> 
> I use 8.0 Release on my thinkpad T42 laptop and want to connect to the WIFI
> AP near me.  The AP is encrypted by WPA2. I also need some root
> certifications installed ( UTN-USERFirst-Hardware ). I install
> /usr/ports/security/ca_root_nss and openssl but still I cannot find where
> the certifications are.
> 
> Any ideas?

$ pkg_info -L ca_root_nss\*
Information for ca_root_nss-3.11.9_2:

Files:
/usr/local/share/certs/ca-root-nss.crt

-- Brooks


pgpp6ikDFVSGE.pgp
Description: PGP signature

install root certificates

[Xian Chen]

Hello,

I use 8.0 Release on my thinkpad T42 laptop and want to connect to the WIFI
AP near me.  The AP is encrypted by WPA2. I also need some root
certifications installed ( UTN-USERFirst-Hardware ). I install
/usr/ports/security/ca_root_nss and openssl but still I cannot find where
the certifications are.

Any ideas?

Thanks,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: em(4) + ALTQ broken

[Pyun YongHyeon]

On Tue, Feb 02, 2010 at 09:47:17AM -0800, Nick Rogers wrote:
> On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon  wrote:
> 
> > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > > I guess the problem comes from multi-queue support. The drbr
> > > > interface is implemented with inline function so em(4)/igb(4) may
> > > > have to define ALTQ to the header. I have not tested the patch(no
> > > > time at this moment) but would you give it try?
> > > >
> > > > I tried the patch and it did not work.
> >
> > You rebuilt kernel, right? Rebuilding kernel module has no effect.
> >
> Yes I rebuilt the kernel itself and replaced the one on my test system.

Hmm, I have to find time to experiment this.
Thank you for testing!
___
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: em(4) + ALTQ broken

[Jack Vogel]

So apparently this thing needs no special knowledge in the driver, yet
something in
the new code breaks it, can someone explain tersely how the altq app
actually
"pokes" or "hooks up" to the driver? I am not clear about that and I suspect
if I was
this would all be clearer.

Jack


On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon  wrote:

> On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > I guess the problem comes from multi-queue support. The drbr
> > > interface is implemented with inline function so em(4)/igb(4) may
> > > have to define ALTQ to the header. I have not tested the patch(no
> > > time at this moment) but would you give it try?
> > >
> > > I tried the patch and it did not work.
>
> You rebuilt kernel, right? Rebuilding kernel module has no effect.
>
___
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: em(4) + ALTQ broken

[Nick Rogers]

On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon  wrote:

> On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > I guess the problem comes from multi-queue support. The drbr
> > > interface is implemented with inline function so em(4)/igb(4) may
> > > have to define ALTQ to the header. I have not tested the patch(no
> > > time at this moment) but would you give it try?
> > >
> > > I tried the patch and it did not work.
>
> You rebuilt kernel, right? Rebuilding kernel module has no effect.
>
Yes I rebuilt the kernel itself and replaced the one on my test system.
___
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: em(4) + ALTQ broken

[Pyun YongHyeon]

On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > I guess the problem comes from multi-queue support. The drbr
> > interface is implemented with inline function so em(4)/igb(4) may
> > have to define ALTQ to the header. I have not tested the patch(no
> > time at this moment) but would you give it try?
> >
> > I tried the patch and it did not work.

You rebuilt kernel, right? Rebuilding kernel module has no effect.
___
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: em(4) + ALTQ broken

[Nick Rogers]

> I guess the problem comes from multi-queue support. The drbr
> interface is implemented with inline function so em(4)/igb(4) may
> have to define ALTQ to the header. I have not tested the patch(no
> time at this moment) but would you give it try?
>
> I tried the patch and it did not work.
___
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"

ionice in FreeBSD?

[Jordi Espasa Clofent]

Hi all,

In Linux exists the ionice(1) for "get/set program io scheduling class 
and priority".


In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if 
I'm understanding correctly, they're related to CPU priorty only, not to 
I/O.


¿Is there some ionice(1) equivalent in FreeBSD?

--
I must not fear. Fear is the mind-killer. Fear is the little-death that 
brings total obliteration. I will face my fear. I will permit it to pass 
over me and through me. And when it has gone past I will turn the inner 
eye to see its path. Where the fear has gone there will be nothing. Only 
I will remain.


Bene Gesserit Litany Against Fear.
___
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"

nmi_calltrap in siopoll()

[pluknet]

Hi.

I've got NMI on an almost idle system - FreeBSD 7.2-R amd64.
I guess the reason may be in (hardware?) binary garbage
seen once in a while on serial port (loader, then ttyd0).
Ask me for more details.

Tracing command swi4: clock sio pid 20 tid 100011 td 0xff000144e370
cpustop_handler() at cpustop_handler+64
ipi_nmi_handler() at ipi_nmi_handler+48
trap() at trap+796
nmi_calltrap() at nmi_calltrap+8
--- trap 19, rip = 18446744071567390785, rsp = 18446744067267268592,
rbp = 18446744067267558272 ---
_mtx_lock_spin() at _mtx_lock_spin+113
siopoll() at siopoll+206
ithread_loop() at ithread_loop+384
fork_exit() at fork_exit+287
fork_trampoline() at fork_trampoline+14
--- trap 0, rip = 0, rsp = 18446744067267558704, rbp = 0 ---

(kgdb) thr 13
[Switching to thread 13 (Thread 100011)]#0  cpustop_handler () at atomic.h:264
264 atomic.h: No such file or directory.
in atomic.h
(kgdb) bt
#0  cpustop_handler () at atomic.h:264
#1  0x807ec400 in ipi_nmi_handler ()
at /usr/src/sys/amd64/amd64/mp_machdep.c:1144
#2  0x807fceec in trap (frame=0xfffe80028f40)
at /usr/src/sys/amd64/amd64/trap.c:198
#3  0x807e0aeb in nmi_calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:427
#4  0x80513841 in _mtx_lock_spin (m=0x80bb3d00,
tid=18446742974219215728, opts=Variable "opts" is not available.
) at /usr/src/sys/kern/kern_mutex.c:474
#5  0x8082b96e in siopoll (dummy=Variable "dummy" is not available.
) at /usr/src/sys/dev/sio/sio.c:1703
#6  0x804ff940 in ithread_loop (arg=0xff000142bac0)
at /usr/src/sys/kern/kern_intr.c:1088
#7  0x804fc1df in fork_exit (
callout=0x804ff7c0 , arg=0xff000142bac0,
frame=0xfffe8006fc80) at /usr/src/sys/kern/kern_fork.c:834
#8  0x807e0b5e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:455
#9  0x in ?? ()
#10 0x in ?? ()
#11 0x0001 in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
---Type  to continue, or q  to quit---q
Quit
(kgdb) f 5
#5  0x8082b96e in siopoll (dummy=Variable "dummy" is not available.
) at /usr/src/sys/dev/sio/sio.c:1703
1703mtx_lock_spin(&sio_lock);
(kgdb) i loc
_tid = Variable "_tid" is not available.
(kgdb) list
1698com_events -= incc;
1699mtx_unlock_spin(&sio_lock);
1700continue;
1701}
1702if (com->iptr != com->ibuf) {
1703mtx_lock_spin(&sio_lock);
1704sioinput(com);
1705mtx_unlock_spin(&sio_lock);
1706}
1707if (com->state & CS_CHECKMSR) {
(kgdb) p sio_lock
$1 = {lock_object = {lo_name = 0x80b15380 "sio",
lo_type = 0x80b15380 "sio", lo_flags = 458752, lo_witness_data = {
  lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
  mtx_lock = 18446742974219094608, mtx_recurse = 0}
(kgdb) p/x sio_lock->mtx_lock
$10 = 0xff0001430a50  # == td for pid 17 tid 18


Binary garbage is like below (not touching anything on k/board atm).

login:
FreeBSD/amd64 (ho
FreeBSD/amd64 (host) (ttyd0)

login: <<|Ч
FreeBSD
FreeBSD
FreeBS
FreeBSD
Free
FreeBSD/amd64 (host) (ttyd0)

login:
FreeBSD/amd64 (host) (ttyd0)

login:
FreeBSD
Free

FreeBS
FreeBSD
FreeBS
FreeBSD
FreeBSD
FreeBS
FreeBSD
FreeBS
FreeBSD
FreeBSD
FreeBS
FreeBSD
FreeBS═╗Hхи M5
FreeBSD
FreeBS
FreeBSD
FreeBSD
FreeBS
FreeBSD
FreeBS═╗Hхи M5
FreeBSD
FreeBS
FreeBSD
FreeB
FreeBSD/amd6
FreeBS
FreeBS
FreeBSD
FreeBSD
FreeBS
FreeBSD
FreeBS
FreeBSD
FreeBSD
FreeBS
FreeBSD
FreeBS═╗Hхи M5
FreeBSD
FreeBS
FreeBSD
[..a little later..]

[r...@host ~]# <<<>8<8
<8<<<><

Other useful stuff.

(kgdb) f 4
#4  0x80513841 in _mtx_lock_spin (m=0x80bb3d00,
tid=18446742974219215728, opts=Variable "opts" is not available.
) at /usr/src/sys/kern/kern_mutex.c:474
474 while (m->mtx_lock != MTX_UNOWNED) {
(kgdb) list
469 lock_profile_obtain_lock_failed(&m->lock_object,
&contested, &waittime);
470 while (!_obtain_lock(m, tid)) {
471
472 /* Give interrupts a chance while we spin. */
473 spinlock_exit();
474 while (m->mtx_lock != MTX_UNOWNED) {
475 if (i++ < 1000) {
476 cpu_spinwait();
477 continue;
478 }
(kgdb) f 3
#3  0x807e0aeb in nmi_calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:427
427 calltrap
Current language:  auto; currently asm
(kgdb) list
422 swapgs
423 /* Note: this label is also used by ddb and gdb: */
424 nmi_

Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available

[Florian Smeets]

On 1/22/10 8:55 PM, Max Laier wrote:

On Friday 22 January 2010 19:49:19 John Baldwin wrote:

On Friday 22 January 2010 12:18:20 pm Max Laier wrote:


pf does change the byte order in the pfil hook, but changes it back on
return to the stack either when returning from the hook or when calling
back into the stack.  There have been some issues where we missed returns
to the stack that would result in this situation, but since pf is not in
the trace, this is clearly not the case here.


That isn't necessarily the case.  ip_input() invokes the PFIL hooks which
then return after possibly modifying the packet.  The (possibly modified)
packet is then passed to ip_forward() from ip_input().  If the PFIL hook
modified the packet and returned ip_len in network byte order then it would
cause this breakage without showing up in the stack trace.


What I meant to say was: if we return from the pfil hook we either report
error (and/or consume the mbuf) or switch back to network byte order:

http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655

While I can't completely rule out that there is a double flip happening in
some obscure path through pf, I very much doubt this is what is going on (or
there would be more reports and it would happen straight away, not only after
passing some data).  A quick search through the sources also didn't turn up
any red flags.  All byte order operations inside pf are either temporary or
performed on a properly copied packet that is send back through the stack
(icmp error, tcp packet, ...).

Depending on how easily this can be reproduced, my money is on modifying a
shared mbuf (possibly inside enc(4)).



I have been running with a WITNESS kernel for 10 days now, and have 
tried quite a few things to reproduce the problem, but no luck so far.


I'll post again if i find something.

Thanks to everyone involved!

Cheers,
Florian
___
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: patch for /usr/bin/mail

[Pete French]

> For what it's worth: note that Outlook, by default, uses semi-colon as
> its delimiter between addresses in To/Cc/Bcc fields.  The SMTP portion
> of the Exchange interface might turn these into commas though, but I'm
> not 100% certain (I'd have to manually check -- let me know if you want
> me to).

It would be inetersting to see what the arrive as when they have been
written onto a FreeBSd hhost by the mail transport certainly! That might
actually be the source of this bug if they come out with commas
but no spaces.

cheers,

-pete.
___
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: patch for /usr/bin/mail

[Jeremy Chadwick]

On Tue, Feb 02, 2010 at 02:21:44PM +, Pete French wrote:
> This patch fixes a problem of mail missing addresses when replying
> to emails generated by some Microsoft systems, which do not insert a
> space after the comma in lists of addresses. Was filed as PR bin/131861
> If anyone who still uses /usr/bin/mail as their primarly email client
> could test it then I would be grateful (would also be garetful if
> someone could volunteer to commit it shold it prove to work fine :-) )
> 
> -pete.
> 
> --- usr.bin/mail/util.c.orig2010-02-02 14:10:34.220987358 +
> +++ usr.bin/mail/util.c 2010-02-02 14:12:49.968147827 +
> @@ -496,10 +496,10 @@
> *cp2++ = ' ';
> }
> *cp2++ = c;
> -   if (c == ',' && *cp == ' ' && !gotlt) {
> +   if (c == ',' && (*cp == ' ' || *cp == '"') && !gotlt) 
> {
> *cp2++ = ' ';
> -   while (*++cp == ' ')
> -   ;
> +   while (*cp == ' ')
> +   cp++;
> lastsp = 0;
> bufend = cp2;
> }

For what it's worth: note that Outlook, by default, uses semi-colon as
its delimiter between addresses in To/Cc/Bcc fields.  The SMTP portion
of the Exchange interface might turn these into commas though, but I'm
not 100% certain (I'd have to manually check -- let me know if you want
me to).

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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"

patch for /usr/bin/mail

[Pete French]

This patch fixes a problem of mail missing addresses when replying
to emails generated by some Microsoft systems, which do not insert a
space after the comma in lists of addresses. Was filed as PR bin/131861
If anyone who still uses /usr/bin/mail as their primarly email client
could test it then I would be grateful (would also be garetful if
someone could volunteer to commit it shold it prove to work fine :-) )

-pete.

--- usr.bin/mail/util.c.orig2010-02-02 14:10:34.220987358 +
+++ usr.bin/mail/util.c 2010-02-02 14:12:49.968147827 +
@@ -496,10 +496,10 @@
*cp2++ = ' ';
}
*cp2++ = c;
-   if (c == ',' && *cp == ' ' && !gotlt) {
+   if (c == ',' && (*cp == ' ' || *cp == '"') && !gotlt) {
*cp2++ = ' ';
-   while (*++cp == ' ')
-   ;
+   while (*cp == ' ')
+   cp++;
lastsp = 0;
bufend = cp2;
}

___
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 Freebsd 8-RELEASE

[Giovanni Trematerra]

On Tue, Feb 2, 2010 at 10:45 AM, Giovanni Trematerra
 wrote:
> On Tue, Feb 2, 2010 at 3:14 AM, Daniel Ballenger  wrote:
>> On Feb 1, 2010, at 2:21 PM, Giovanni Trematerra wrote:
>>> On Mon, Feb 1, 2010 at 10:44 PM, Daniel Ballenger  wrote:


 The crash is repeatable (occurs everytime for me).  I also confirmed that 
 another FreeBSD 8 machine I have ran into the same >>> panic (also amd64).
>
> Hi, Daniel
> The bug was resolved in HEAD r200667 and  8-STABLE in r200668
>
> Hope this help
>

Sorry I was wrong for 8-STABLE the fix is in r200768

> --
> Gianni
>
___
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 Freebsd 8-RELEASE

[Giovanni Trematerra]

On Tue, Feb 2, 2010 at 3:14 AM, Daniel Ballenger  wrote:
> On Feb 1, 2010, at 2:21 PM, Giovanni Trematerra wrote:
>> On Mon, Feb 1, 2010 at 10:44 PM, Daniel Ballenger  wrote:
>>>
>>>
>>> The crash is repeatable (occurs everytime for me).  I also confirmed that 
>>> another FreeBSD 8 machine I have ran into the same >>> panic (also amd64).

Hi, Daniel
The bug was resolved in HEAD r200667 and  8-STABLE in r200668

Hope this help

--
Gianni
___
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"