Re: dereferencing type-punned pointer will break strict-aliasingrules

[Bruce Evans]

On Mon, 28 Jul 2003, Thomas Moestl wrote:

> On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
> >
> > Is this caused by -oS option?
> >
> > - in making BOOTMFS in make release
> > cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
> > -std=c99  -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/dev 
> > -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter 
> > -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL 
> > -include opt_global.h -fno-common -finline-limit=15000  -mno-align-long-strings 
> > -mpreferred-stack-boundary=2 -ffreestanding -Werror  /usr/src/sys/geom/geom_dev.c
> > /usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
> > /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will 
> > break strict-aliasing rules
> > [...]
>
> Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
> workaround.

gcc.info claims that -fstrict-aliasing is implied by -Wall, but this is
apparently wrong -- adding -fstrict-aliasing to our standard warning flags
gives the same warnings.  -Os gives it since -Os is more like -O2 than -O,
and gcc.info's claim that -fstrict-aliasing is implied by -O2 is apparently
not wrong.  Related bug: our warning flags are missing other new gcc warnings.

> The problem is caused by the i386 PCPU_GET/PCPU_SET
> implementation:
>
>   #define __PCPU_GET(name) ({ \
>   __pcpu_type(name) __result; \
>   \
>   [...]
>   } else if (sizeof(__result) == 4) { \
>   u_int __i;  \
>   __asm __volatile("movl %%fs:%1,%0"  \
>   : "=r" (__i)\
>   : "m" (*(u_int *)(__pcpu_offset(name;   \
>   __result = *(__pcpu_type(name) *)&__i;  \
>   [...]
>
> In this case, the PCPU_GET is used to retrieve curthread, causing
> sizeof(__result) to be 4, so the cast at the end of the code snippet
> is from a u_int * to struct thread *, and __i is accessed through the
> casted pointer, which violates the C99 aliasing rules.
> An alternative is to type-pun via a union, which is also a bit ugly,
> but explicitly allowed by C99. Patch attached (but only superficially
> tested).

Uh, this macro is hideous enough without making it larger.  I found that
using __builtin_memcpy() avoids the warning at little or no cost in
object code size (the memcpy gets optimized away in almost the same way
as the assignment).  Then I tried to improve the macro.  I didn't quite
succeed -- the smller versions gave slightly larger object code for
5-20 out of 300 object files that depend on pcpu.h.

Annotated version:

% Index: pcpu.h
% ===
% RCS file: /home/ncvs/src/sys/i386/include/pcpu.h,v
% retrieving revision 1.35
% diff -u -2 -r1.35 pcpu.h
% --- pcpu.h1 Oct 2002 14:01:58 -   1.35
% +++ pcpu.h28 Jul 2003 14:02:30 -
% @@ -78,5 +80,5 @@
%   * Evaluates to the address of the per-cpu variable name.
%   */
% -#define  __PCPU_PTR(name) ({ \
% +#define  __PCPU_PTR(name) __extension__ ({   \

Unrelated change.  This prevents warnings when compiled with certain
strict warning flags (-pedantic?).

%   __pcpu_type(name) *__p; \
%   \
% @@ -96,21 +98,21 @@
%   \
%   if (sizeof(__result) == 1) {\
% - u_char __b; \
% - __asm __volatile("movb %%fs:%1,%0"  \
% - : "=r" (__b)\
% - : "m" (*(u_char *)(__pcpu_offset(name;  \
% - __result = *(__pcpu_type(name) *)&__b;  \
% + __pcpu_type(name) __res;\

The temporary variable with a basic type is to avoid gcc getting confused
doing reloads in dead code.  E.g., if __pcpu_type(name) is "struct timeval",
then the type can't be loaded into a byte register, and gcc would die
trying since it apparently tries to load things in dead code, especially
in asms.  However, this problem doesn't seem to affect __PCPU_GET().
There is no problem loading the source operand since only its address
can really be loaded, and no problem loading the target o

psmintr: discard a byte (1) [moused issues]

[Wilkinson,Alex]

:Can you add
:options PSM_DEBUG=2
:to your kernel config and recompile, then do a verbose boot (boot -v) and
:send me the output?


Jul 29 15:00:15 hostname kernel: Copyright (c) 1992-2003 The FreeBSD Project.
Jul 29 15:00:15 hostname kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 
1991, 1992, 1993, 1994
Jul 29 15:00:15 hostname kernel: The Regents of the University of California. All 
rights reserved.
Jul 29 15:00:15 hostname kernel: FreeBSD 5.1-CURRENT #1: Tue Jul 29 14:23:55 CST 2003
Jul 29 15:00:15 hostname kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Jul 29 15:00:15 hostname kernel: Preloaded elf kernel "/boot/kernel/kernel" at 
0xc077.
Jul 29 15:00:15 hostname kernel: Preloaded elf module "/boot/kernel/vesa.ko" at 
0xc07701f4.
Jul 29 15:00:15 hostname kernel: Preloaded elf module "/boot/kernel/snd_ich.ko" at 
0xc07702a0.
Jul 29 15:00:15 hostname kernel: Preloaded elf module "/boot/kernel/snd_pcm.ko" at 
0xc077034c.
Jul 29 15:00:15 hostname kernel: Preloaded elf module "/boot/kernel/acpi.ko" at 
0xc07703f8.
Jul 29 15:00:15 hostname kernel: Timecounter "i8254"  frequency 1193182 Hz
Jul 29 15:00:15 hostname kernel: Timecounter "TSC"  frequency 1004833815 Hz
Jul 29 15:00:15 hostname kernel: CPU: Intel Pentium III (1004.83-MHz 686-class CPU)
Jul 29 15:00:15 hostname kernel: Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
Jul 29 15:00:15 hostname kernel: 
Features=0x383f9ff
Jul 29 15:00:15 hostname kernel: real memory  = 536805376 (511 MB)
Jul 29 15:00:15 hostname kernel: avail memory = 513347584 (489 MB)
Jul 29 15:00:15 hostname kernel: Pentium Pro MTRR support enabled
Jul 29 15:00:15 hostname kernel: VESA: v3.0, 32768k memory, flags:0x1, mode 
table:0xc00c52bd (c00052bd)
Jul 29 15:00:15 hostname kernel: VESA: Matrox Graphics Inc.
Jul 29 15:00:15 hostname kernel: npx0:  on motherboard
Jul 29 15:00:15 hostname kernel: npx0: INT 16 interface
Jul 29 15:00:15 hostname kernel: acpi0:  on motherboard
Jul 29 15:00:15 hostname kernel: pcibios: BIOS version 2.10
Jul 29 15:00:15 hostname kernel: Using $PIR table, 10 entries at 0xc00fdeb0
Jul 29 15:00:15 hostname kernel: acpi0: power button is handled as a fixed feature 
programming model.
Jul 29 15:00:15 hostname kernel: Timecounter "ACPI-fast"  frequency 3579545 Hz
Jul 29 15:00:15 hostname kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 
0x4008-0x400b on acpi0
Jul 29 15:00:15 hostname kernel: acpi_cpu0:  on acpi0
Jul 29 15:00:15 hostname kernel: acpi_tz0:  on acpi0
Jul 29 15:00:15 hostname kernel: acpi_button0:  on acpi0
Jul 29 15:00:15 hostname kernel: acpi_button1:  on acpi0
Jul 29 15:00:15 hostname kernel: pcib0:  port 
0x4000-0x40f7,0xcf8-0xcff on acpi0
Jul 29 15:00:15 hostname kernel: pci0:  on pcib0
Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTD is routed to irq 10
Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTC is routed to irq 11
Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTB is routed to irq 11
Jul 29 15:00:15 hostname kernel: agp0:  
mem 0xd000-0xd3ff at device 0.0 on pci0
Jul 29 15:00:15 hostname kernel: pcib1:  at device 1.0 on pci0
Jul 29 15:00:15 hostname kernel: pci1:  on pcib1
Jul 29 15:00:15 hostname kernel: pcib0: slot 1 INTA is routed to irq 11
Jul 29 15:00:15 hostname kernel: pcib1: slot 0 INTA is routed to irq 11
Jul 29 15:00:15 hostname kernel: pci1:  at device 0.0 (no driver 
attached)
Jul 29 15:00:15 hostname kernel: pcib2:  at device 30.0 on pci0
Jul 29 15:00:15 hostname kernel: pci2:  on pcib2
Jul 29 15:00:15 hostname kernel: pcib2: slot 1 INTA is routed to irq 11
Jul 29 15:00:15 hostname kernel: pcib2: slot 3 INTA is routed to irq 10
Jul 29 15:00:15 hostname kernel: bt0:  port 
0xc000-0xc003 irq 11 at device 1.0 on pci2
Jul 29 15:00:15 hostname kernel: bt0: BT-946C FW Rev. 4.25J Narrow SCSI Host Adapter, 
SCSI ID 7, 100 CCBs
Jul 29 15:00:15 hostname kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 
0xc400-0xc47f mem 0xda00-0xda7f irq 10 at device 3.0 on pci2
Jul 29 15:00:15 hostname kernel: xl0: Ethernet address: 00:01:03:45:32:a0
Jul 29 15:00:15 hostname kernel: miibus0:  on xl0
Jul 29 15:00:15 hostname kernel: ukphy0:  on 
miibus0
Jul 29 15:00:15 hostname kernel: ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, auto
Jul 29 15:00:15 hostname kernel: isab0:  at device 31.0 on pci0
Jul 29 15:00:15 hostname kernel: isa0:  on isab0
Jul 29 15:00:15 hostname kernel: atapci0:  port 
0xf000-0xf00f at device 31.1 on pci0
Jul 29 15:00:15 hostname kernel: ata0: at 0x1f0 irq 14 on atapci0
Jul 29 15:00:15 hostname kernel: ata1: at 0x170 irq 15 on atapci0
Jul 29 15:00:15 hostname kernel: uhci0:  port 0xd000-0xd01f irq 10 at device 31.2 on pci0
Jul 29 15:00:15 hostname kernel: usb0:  
on uhci0
Jul 29 15:00:15 hostname kernel: usb0: USB revision 1.0
Jul 29 15:00:15 hostname kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, 
addr 1
Jul 29 15:00:15 hostname kernel: uhub0: 2 ports with 2 removable, self powered
Jul 29 15:00:15 hostn

Re: Recommended kernel config for a dell 8450, 8 cpu, 8GB of ram.

[Terry Lambert]

Mark Sergeant wrote:
> Just seeking some general information. I've got a couple of dell 8 cpu
> boxes here running FreeBSD 5.1-RELEASE and am interested in peoples
> thoughts on the best kernel configs for this type of machine. I'm
> interested in the best way of making use of 8 cpu's and also seeing the
> whole 8GB of RAM.

For more than 4G of physical RAM, your only option is to enable
the PAE support.

In terms of other configuration options, it really depends on
your intended use.  In general, the PAE support doesn't allow
the address space of the combined user and kernel to exceed 4G;
what it does is let you have more processes resident instead of
being swapped out.  You also can't really increase your kernel
memory usage over the KVA size limit, in any case, and unless
you increase the KVA from 2G to 3G (simultaneously decreasing
the UVA available to user processses), you will likely run into
the "kmem_map too small", even if you set the hard limits up.

Doing this will reduce the maximum size of user processes, which
may not be what you want, given that the reason you have more
than 4G in the box in the first place is that you are expecting
to be able to make use of it.  8-).

One thing that would be helpful (and last time I looked, it still
wasn't easily supportable) would be to change the KVA/UVA ratio,
and deuinify the kernel and process address space.  Doing this
would have implications for the pipe code and the loopback device,
but it would also let you replace uiomove() to do map flipping to
copy data in and out, and basically that would give you the full
4G UVA and full 4G KVA, instead of being limited to UVA+KVA=4G.

This is basically what the Alpha, SPARC, and PPC platforms do.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on alpha/alpha

[Tinderbox]

TB --- 2003-07-29 04:00:04 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-29 04:00:04 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-29 04:08:19 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-07-29 05:14:03 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Jul 29 05:14:03 GMT 2003
>>> Kernel build for GENERIC completed on Tue Jul 29 05:25:52 GMT 2003
TB --- 2003-07-29 05:25:52 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-07-29 05:25:52 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Jul 29 05:25:52 GMT 2003
[...]
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/

Re: HEADSUP: USB da(4) quirks deprecated

[Andre Guibert de Bruet]

Hi,

"camcontrol inquiry" requires the pass driver, so if it's not already in
your kernel config you might want to add it when/if you add DA_OLD_QUIRKS.

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>

On Mon, 28 Jul 2003, Nate Lawson wrote:

> I have committed code to disable the USB and Firewire quirks in da(4).
> Since we now have code that should handle the common case of a failure
> after receiving 6 byte commands, most of them should no longer be
> necessary.  However, the only way to tell if a quirk is really needed is
> to test the new code with the quirks disabled.  You may have a device (USB
> camera, pen drive, hard drive, ...) that begins to get errors like "BBB
> bulk-in clear stall failed" or "Synchronize cache failed, status 0x35".
> If you get these, you can enable previous behavior by adding:
>
> options DA_OLD_QUIRKS
>
> to your kernel config and recompiling.  Once you do this, please send me
> the output of "camcontrol inquiry da0" so I can re-enable your quirk for
> good.  I'm doing this as soon as possible so the unnecessary quirks can be
> removed for 5.2.  A similar process will take place in 4-stable after 5.2
> has been released.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fixed another leak in USB code

[John-Mark Gurney]

Ok, those of you coming with panics due to kmem exhaustion w/ USB, I
have fixed another leak.  For some reason I assumed that big blocks
were being deallocated upon free, not being put back on the freelist.
(Have I mentioned how much it sucks that the USB code it self has five
different allocators?)

As mentioned in the commit message, I did some testing, and a simple
bulk transfer over aue did not increase the devbuf memory usage, while
before this patch, I got it quickly over 20megs and growing.

Sorry for the breakage.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

HEADSUP: USB da(4) quirks deprecated

[Nate Lawson]

I have committed code to disable the USB and Firewire quirks in da(4).
Since we now have code that should handle the common case of a failure
after receiving 6 byte commands, most of them should no longer be
necessary.  However, the only way to tell if a quirk is really needed is
to test the new code with the quirks disabled.  You may have a device (USB
camera, pen drive, hard drive, ...) that begins to get errors like "BBB
bulk-in clear stall failed" or "Synchronize cache failed, status 0x35".
If you get these, you can enable previous behavior by adding:

options DA_OLD_QUIRKS

to your kernel config and recompiling.  Once you do this, please send me
the output of "camcontrol inquiry da0" so I can re-enable your quirk for
good.  I'm doing this as soon as possible so the unnecessary quirks can be
removed for 5.2.  A similar process will take place in 4-stable after 5.2
has been released.

Thanks for your patience,
Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NATD question...

[Hideyuki KURASHINA]

>>> On Mon, 28 Jul 2003 18:54:17 -0400, "Paul A. Howes" <[EMAIL PROTECTED]> said:

> I typed that wrong in the e-mail, but not in my configuration file.
> 
>   redirect_port 192.168.x.x:http  
> 
> The question still stands:  Why didn't this work?

Strange.  It may take some minutes to reflect your natd config file.

If you want to take effect of your change immediately, kill -TERM
natd process and then perform "/sbin/natd -f ".

-- rushani
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: NATD question...

[Paul A. Howes]

I typed that wrong in the e-mail, but not in my configuration file.

redirect_port 192.168.x.x:http  

The question still stands:  Why didn't this work?

Thanks!

--
Paul A. Howes

-Original Message-
From: Hideyuki KURASHINA [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 28, 2003 3:53 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: NATD question...

Hi,

>>> On Mon, 28 Jul 2003 12:17:24 -0400, "Paul A. Howes"
<[EMAIL PROTECTED]> said:

> All,
> 
> I am trying to redirect a port on my FreeBSD 5.1-based firewall to an
> internal machine.  My natd configuration contains a directive:
> 
>   redirect-port 192.168.x.x:http  
> 
> I performed a "kill -HUP" on the natd process, but it doesn't work.  I can
> verify that the internal Web server is functional, and accessible to the
> internal network.  I even added ipfw rules to allow for traffic on port
> , but still nothing.
> 
> Am I missing something obvious here?  Thanks!

That's a wrong directive. Use ``redirect_port''.
^

-- rushani


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Another LOR with filedesc structure and Giant

[Kris Kennaway]

On Mon, Jul 28, 2003 at 02:53:12PM -0700, Kris Kennaway wrote:
> On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
> > 
> > On Sun, 27 Jul 2003, Kris Kennaway wrote:
> > 
> > > After upgrading last night, one of the package machines found this:
> > 
> > I've bumped into some similar problems -- it's a property of how we
> > current lock select().  We hold the file descriptor lock for the duration
> > of polling each object being "selected", and if any of those objects has
> > to grab a lock for any reason, it has to implicitly fall after the file
> > descriptor lock.  I actually run into this in some of our MAC code,
> > because I need to grab a vnode lock to authorize polling the vnode using
> > VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
> > WITNESS warning.  Unfortunately, it's not immediately clear what a better
> > locking scheme would look like without going overboard on the fine-grained
> > side.  We probably need to grab Giant before entering the select code
> > since it's highly likely something in there will require Giant -- it
> > reaches down into VFS, the device stuff, socket code, tc.
> 
> Also
> 
> lock order reversal
>  1st 0xc6a69634 filedesc structure (filedesc structure) @ 
> /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1071
>  2nd 0xc04aa120 Giant (Giant) @ 
> /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
> Stack backtrace:
> backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
> witness_lock(c04aa120,8,c0434e3d,174,246) at witness_lock+0x672
> _mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
> spec_poll(d8dfcb44,d8dfcb64,c02d119c,d8dfcb44,c04939a0) at spec_poll+0x134
> spec_vnoperate(d8dfcb44,c04939a0,c52cfa44,41,c6cfd280) at spec_vnoperate+0x18
> vn_poll(c45dc880,41,c6cfd280,c5f7a4c0,c6cfd280) at vn_poll+0x3c
> pollscan(c5f7a4c0,d8dfcbd4,2,3e7,10) at pollscan+0xb0
> poll(c5f7a4c0,d8dfcd10,c0455899,3ee,3) at poll+0x252
> syscall(2f,2f,2f,0,2) at syscall+0x273
> Xint0x80_syscall() at Xint0x80_syscall+0x1d

#8  0xc0290ed7 in witness_lock (lock=0xc04aa120, flags=8,
file=0xc0434e3d "/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c", 
line=372)
at /a/asami/portbuild/i386/src-client/sys/kern/subr_witness.c:838
#9  0xc0261f4a in _mtx_lock_flags (m=0x0, opts=0, file=0xc04d1818 "", line=-1068850912)
at /a/asami/portbuild/i386/src-client/sys/kern/kern_mutex.c:334
#10 0xc0231154 in spec_poll (ap=0xd8dfcb44)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
#11 0xc0230648 in spec_vnoperate (ap=0x0)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:122
#12 0xc02d119c in vn_poll (fp=0x0, events=0, active_cred=0xc6cfd280, td=0x0) at 
vnode_if.h:537
#13 0xc0294c50 in pollscan (td=0xc5f7a4c0, fds=0xd8dfcbdc, nfd=2)
at /a/asami/portbuild/i386/src-client/sys/sys/file.h:272
#14 0xc02948a2 in poll (td=0xc5f7a4c0, uap=0xd8dfcd10)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1001
#15 0xc03ef9b3 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 2, tf_ebp = 
-1077940448, tf_isp = -656421516, tf_ebx = 673224876, tf_edx = 139153408, tf_ecx = 
137314336, tf_eax = 209, tf_trapno = 0, tf_err = 2, tf_eip = 672942388, tf_cs = 31, 
tf_eflags = 659, tf_esp = -1077940508, tf_ss = 47})
at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1008
#16 0xc03dfbed in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---

Kris

pgp0.pgp
Description: PGP signature

buffers remaining...

[Andy Farkas]

If you boot into single user mode (boot -s), do an fsck (a full fsck, no
options), then halt(8), you will get:

syncing disks, buffers remaining... 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers

every time. Only happens with clean disks. 100% reproducable.

I have UFS1 partitions. Been happening for quite a while (since 5.0)

--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/




___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Another LOR with filedesc structure and Giant

[Kris Kennaway]

On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
> 
> On Sun, 27 Jul 2003, Kris Kennaway wrote:
> 
> > After upgrading last night, one of the package machines found this:
> 
> I've bumped into some similar problems -- it's a property of how we
> current lock select().  We hold the file descriptor lock for the duration
> of polling each object being "selected", and if any of those objects has
> to grab a lock for any reason, it has to implicitly fall after the file
> descriptor lock.  I actually run into this in some of our MAC code,
> because I need to grab a vnode lock to authorize polling the vnode using
> VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
> WITNESS warning.  Unfortunately, it's not immediately clear what a better
> locking scheme would look like without going overboard on the fine-grained
> side.  We probably need to grab Giant before entering the select code
> since it's highly likely something in there will require Giant -- it
> reaches down into VFS, the device stuff, socket code, tc.

Also

lock order reversal
 1st 0xc6a69634 filedesc structure (filedesc structure) @ 
/a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1071
 2nd 0xc04aa120 Giant (Giant) @ 
/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
Stack backtrace:
backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
witness_lock(c04aa120,8,c0434e3d,174,246) at witness_lock+0x672
_mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
spec_poll(d8dfcb44,d8dfcb64,c02d119c,d8dfcb44,c04939a0) at spec_poll+0x134
spec_vnoperate(d8dfcb44,c04939a0,c52cfa44,41,c6cfd280) at spec_vnoperate+0x18
vn_poll(c45dc880,41,c6cfd280,c5f7a4c0,c6cfd280) at vn_poll+0x3c
pollscan(c5f7a4c0,d8dfcbd4,2,3e7,10) at pollscan+0xb0
poll(c5f7a4c0,d8dfcd10,c0455899,3ee,3) at poll+0x252
syscall(2f,2f,2f,0,2) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (209), eip = 0x281c4934, esp = 0xbfbfeee4, ebp = 0xbfbfef20 ---
Debugger("witness_lock")
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db>

Kris


pgp0.pgp
Description: PGP signature

Re: SSH from host to jail

[Pat Lashley]

--On Monday, July 28, 2003 13:25:07 +0400 Artem 'Zazoobr' Ignatjev 
<[EMAIL PROTECTED]> wrote:

Errr... Random shot:
Have you told ssh on host not to listen on all addresses it'll find?
I use 'ListenAddress' directive in /etc/ssh/sshd_config
Yes, I have.  And if that were the problem, I would expect the
SSH session to connect; but to log me into the host system instead
of the jail.  My actual symptoms are more like the packets just
arent' getting there at all.  Or maybe aren't getting back...
Hmmm.   Now it's working.  I'd swear that I'm doing exactly the same
thing I was trying before; and nothing else has changed.  Sigh.  Call
it pilot error..


-Pat



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SSH from host to jail

[Pat Lashley]

--On Sunday, July 27, 2003 16:28:44 -0500 Jon Disnard 
<[EMAIL PROTECTED]> wrote:

Pat Lashley wrote:
I'm trying to set up some jails in a 5.1R system.  I've pretty much
copied a setup that was working fine in 4.8; but on 5.1 I can't seem
to SSH from the host system into one of its jails.  It acts like the
packets just aren't getting through.
I would really appreciate it if somebody would send me rc.conf fragments
that are known to work for setting up a jail's IP alias and routing on
5.1.


sure, but this isn't going to fix your problem:

ifconfig_wi0="inet 192.168.0.140 netmask 255.255.255.0"
ifconfig_wi0_alias0="inet 192.168.0.131 netmask 255.255.255.255"
jail_enable="YES"
jail_list="shiba"
jail_shiba_hostname="shiba"
jail_shiba_ip="192.168.0.131"
jail_shiba_rootdir="/usr/prison/192_168_0_130/"
jail_shiba_exec="/bin/sh /etc/rc"
Thanks, but this isn't the part I'm interested in.  It looks like
what I need is the stuff that sets up the IP alias, routing, etc.
for the jail.  The ifconfig_*_alias* and any route_* or related
rc.conf entries.

To fix your problem you should try to mount a devfs for the jail so the
tty device is available for sshd to open when you login. I simply added
one line to my /etc/rc.d/jail script to test for the "dev" mount-point in
jail. Like so:
Nope, I had a devfs set up.

Note that I'm still getting them set up; so I'm starting them by hand
instead of using the rc script.  (Well, actually, I'll use an updated
version of the script I was using on 4.8 because I have some additional
work I want done there and I don't want to start the jails until after
the stuff in /usr/local/etc/rc.d have been run.)

It could be easy to have it simply exist, or be non-null, to imply a
desire for devfs, and further checked for the existence of the
mount-point as I wrote above.
I could have a pr+patch made in 5 minutes if anybody thinks this is not a
bad idea?
Sounds good to me.  And a similar patch for procfs.

Or perhaps some more generic solution that would allow for open-ended
additional mounts?
	jail_mumble_mounts='/etc/fstab.mumble'

Then in the loop in /etc/rc.d/jail:

eval jail_fstab=\"$jail_${_jail}_mounts\"
[ -n $jail_fstab ] && mount -a -F $jail_fstab
Note that fstab.mumble is outside the jail; and should only contain
entries for devfs, procfs, and other mounts to be done on top of the
jail before starting it.


-Pat
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: device driver memory leak in 5.1-20030726?

[John-Mark Gurney]

Gary Jennejohn wrote this message on Mon, Jul 28, 2003 at 12:58 +0200:
> It appears to me that the test in usb_block_allocmem() should be
> (p->tag->parent == tag || p->tag->parent == tag->parent) and NOT
> p->tag == tag! That's because bus_dma_tag_create() uses the tag
> passed into usb_block_allocmem() as newtag->parent!
> 
> Unfortunately, bus_dma_tag is an opaque type and there's no way to
> access the parent member anywhere but in the MD busdma_machdep.c :-(
> 
> Anyway, as written there's no way that I can see that the code can
> work correctly.

You miss the code in the XXX bit that overrides the tag with the tag
passed in.  If we allocate a fullblock, the tag doesn't need to be
overwriten since we end up freeing it, but in the fragment case, we
override the tag, and we don't need to keep the tag allocated by
usb_block_allocmem since we never end up freeing the block that is
part of the fragments.

The bug fixed in rev1.2 was because of a difference in how NetBSD/OpenBSD
handles things.  We wouldn't need this if we had a size parameter to
bus_dmamem_alloc.

Please reread the code and see what I mean.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NATD question...

[Hideyuki KURASHINA]

Hi,

>>> On Mon, 28 Jul 2003 12:17:24 -0400, "Paul A. Howes" <[EMAIL PROTECTED]> said:

> All,
> 
> I am trying to redirect a port on my FreeBSD 5.1-based firewall to an
> internal machine.  My natd configuration contains a directive:
> 
>   redirect-port 192.168.x.x:http  
> 
> I performed a "kill -HUP" on the natd process, but it doesn't work.  I can
> verify that the internal Web server is functional, and accessible to the
> internal network.  I even added ipfw rules to allow for traffic on port
> , but still nothing.
> 
> Am I missing something obvious here?  Thanks!

That's a wrong directive. Use ``redirect_port''.
^

-- rushani
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: dereferencing type-punned pointer will break strict-aliasingrules

[Jake Burkholder]

Apparently, On Mon, Jul 28, 2003 at 03:59:00AM +0200,
Thomas Moestl said words to the effect of;

> On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
> > 
> > Is this caused by -oS option?
> > 
> > - in making BOOTMFS in make release
> > cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
> > -std=c99  -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/dev 
> > -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter 
> > -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL 
> > -include opt_global.h -fno-common -finline-limit=15000  -mno-align-long-strings 
> > -mpreferred-stack-boundary=2 -ffreestanding -Werror  /usr/src/sys/geom/geom_dev.c
> > /usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
> > /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will 
> > break strict-aliasing rules
> > [...]
> 
> Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
> workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
> implementation:
> 
>   #define __PCPU_GET(name) ({ \
>   __pcpu_type(name) __result; \
>   \
>   [...]
>   } else if (sizeof(__result) == 4) { \
>   u_int __i;  \
>   __asm __volatile("movl %%fs:%1,%0"  \
>   : "=r" (__i)\
>   : "m" (*(u_int *)(__pcpu_offset(name;   \
>   __result = *(__pcpu_type(name) *)&__i;  \
>   [...]
> 
> In this case, the PCPU_GET is used to retrieve curthread, causing
> sizeof(__result) to be 4, so the cast at the end of the code snippet
> is from a u_int * to struct thread *, and __i is accessed through the
> casted pointer, which violates the C99 aliasing rules.
> An alternative is to type-pun via a union, which is also a bit ugly,
> but explicitly allowed by C99. Patch attached (but only superficially
> tested).
> 
>   - Thomas
> 

...

Using a union sounds fine to me.

Jake
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Checking buildworld success from ssh

[Henry Vogt]

Hi,

you could restart the buildworld with the -DNOCLEAN  option, this would 
terminate
much faster than usual  o r  show up where it fails..

Hope this helps.
Regards
Henry
Am Montag, 28.07.03, um 15:28 Uhr (Europe/Berlin) schrieb Gregory 
Pavelcak:

Hi all,

I started a buildworld on current sources this morning, but,
foolishly, didn't redirect the output to a file. Now I have some
free time at work and would like to ssh in and do the kernel and
mergemaster. Of course, I don't want to do these things if
buildworld failed. Is there any way I can tell in the absence of
saved output?
...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.csrc/sys/dev/firewire sbp.c

[Nate Lawson]

On Mon, 28 Jul 2003, Kevin Oberman wrote:
> > From: Nate Lawson <[EMAIL PROTECTED]>
> > This is the first step to removing many of the da(4) quirks that have
> > accumulated for USB devices.  This code should remove the message:
> > "READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10." It
> > should also fix USB devices which fail when receiving 6 byte commands but
> > do not yet have a quirk.
> >
> > After this code is in both stable and current, current USB quirks will be
> > deprecated but can be re-enabled in a pinch with a kernel option.
> > Unfortunately, I only have contact information for the more recent quirks
> > that were committed and so the only way to find devices that have other
> > problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
> > for devices that still fail.  I'm doing this as early as possible before
> > 5.2 to get things sorted out and if your device fails at that point, it
> > can be returned to ordinary behavior with a kernel option until I remove
> > it from the deprecated section.
>
> This looks great to me. The entire quirks system is a royal pain. It
> really needs to be driven by an external file so that the kernel does
> not need a re-compile for every device that requires poking something
> odd, but eliminating all of the 6 bye/10 byte ones will greatly
> improve life. I know such things (like pccard.conf) are ugly, but it's
> better than patching the source and re-building the kernel all of the
> time.

An external file is unnecessary since true quirks are a one-time thing.
User finds device is broken and then a quirk is committed.  For the USB
case, "false" quirks were needed in that the devices weren't 100% broken,
just that they crash when receiving 6 byte cmds instead of returning "cmd
not supported."  The real problem was that we were sending 6 byte commands
to devices which we should have known might not be able to handle them
(i.e. USB).  I'm just fixing the "false" quirk case (which should be 90%
of our USB quirks).  These "false" quirks were adding tons of noise and
masking truly broken devices (which should be in the minority).
Committing such quirks should go faster once there is less chaff to deal
with.

> There must be a better way. Almost anything like this that I plug into
> Windows "just works". That means no driver installation or anything.
> (The USB devices almost always include software, but I seldom install
> it.) I just HATE it when Windows works better than FreeBSD, but
> hardware can be a tough nut to crack.

Linux still lists broken USB devices in a kernel file.

> Is there any hope of getting PR53094 to support the Nomad MuVo moved
> to current. It will still need a quirk as it requires both
> NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but
> was just assigned to joe@ about 10 days ago, so it may already be on
> it's way. (I am about 250 messages behind in cvs-all, so it may
> already have been committed.)

I'll look at the PR.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.cscsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.csrc/sys/dev/firewire sbp.c

[Kevin Oberman]

> Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT)
> From: Nate Lawson <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> On Sun, 27 Jul 2003, Nate Lawson wrote:
> >   Modified files:
> > sys/cam  cam_ccb.h
> > sys/cam/scsi scsi_da.c scsi_cd.c
> > sys/dev/ata  atapi-cam.c
> > sys/dev/usb  umass.c
> > sys/dev/firewire sbp.c
> >   Log:
> >   Add a PATH_INQ flag, PIM_NO_6_BYTE, which indicates the SIM never wishes to
> >   receive 6 byte commands.  Add a check for this flag to da(4) and cd(4) so
> >   that they honor it.  This is a quick workaround for many devices (especially
> >   USB) that require da(4) quirks to operate.  The more complete approach is
> >   to finish the new transport code which will be aware of the SCSI version a
> >   transport implements.
> >
> >   MFC after:  1 day
> >
> >   Revision  ChangesPath
> >   1.26  +2 -1  src/sys/cam/cam_ccb.h
> >   1.80  +8 -0  src/sys/cam/scsi/scsi_cd.c
> >   1.147 +8 -0  src/sys/cam/scsi/scsi_da.c
> >   1.18  +1 -1  src/sys/dev/ata/atapi-cam.c
> >   1.58  +1 -1  src/sys/dev/firewire/sbp.c
> >   1.88  +1 -1  src/sys/dev/usb/umass.c
> 
> This is the first step to removing many of the da(4) quirks that have
> accumulated for USB devices.  This code should remove the message:
> "READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10." It
> should also fix USB devices which fail when receiving 6 byte commands but
> do not yet have a quirk.
> 
> After this code is in both stable and current, current USB quirks will be
> deprecated but can be re-enabled in a pinch with a kernel option.
> Unfortunately, I only have contact information for the more recent quirks
> that were committed and so the only way to find devices that have other
> problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
> for devices that still fail.  I'm doing this as early as possible before
> 5.2 to get things sorted out and if your device fails at that point, it
> can be returned to ordinary behavior with a kernel option until I remove
> it from the deprecated section.

This looks great to me. The entire quirks system is a royal pain. It
really needs to be driven by an external file so that the kernel does
not need a re-compile for every device that requires poking something
odd, but eliminating all of the 6 bye/10 byte ones will greatly
improve life. I know such things (like pccard.conf) are ugly, but it's
better than patching the source and re-building the kernel all of the
time.

There must be a better way. Almost anything like this that I plug into
Windows "just works". That means no driver installation or anything.
(The USB devices almost always include software, but I seldom install
it.) I just HATE it when Windows works better than FreeBSD, but
hardware can be a tough nut to crack.

Is there any hope of getting PR53094 to support the Nomad MuVo moved
to current. It will still need a quirk as it requires both
NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but
was just assigned to joe@ about 10 days ago, so it may already be on
it's way. (I am about 250 messages behind in cvs-all, so it may
already have been committed.)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on alpha/alpha

[Tinderbox]

TB --- 2003-07-28 16:00:03 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-28 16:00:03 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-28 16:02:04 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-07-28 17:08:30 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Mon Jul 28 17:08:30 GMT 2003
>>> Kernel build for GENERIC completed on Mon Jul 28 17:20:30 GMT 2003
TB --- 2003-07-28 17:20:30 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-07-28 17:20:30 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Jul 28 17:20:30 GMT 2003
[...]
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin 
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/

Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/dev/firewire sbp.c

[Nate Lawson]

On Mon, 28 Jul 2003, Justin T. Gibbs wrote:
> > After this code is in both stable and current, current USB quirks will be
> > deprecated but can be re-enabled in a pinch with a kernel option.
> > Unfortunately, I only have contact information for the more recent quirks
> > that were committed and so the only way to find devices that have other
> > problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
> > for devices that still fail.
>
> Did you ever find the bug in the sync cache "silence errors" code that
> was the root cause for most of the quirks?

Most of the quirks were added for NO_6_BYTE.  Many of the USB devices
include NO_SYNC_CACHE also although the documentation for many of these
was lost before we began keeping PRs documenting the issue.  Many of the
devices that include NO_SYNC_CACHE were just cut/pasted from previous
quirks and no attempt was made to verify the separate need for that quirk.
I'll do my best to follow down cvs logs and things but what it comes down
to is that we'll just have to test to see what quirks are really needed.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

linksys wireless usb adapter

[Paulo Roberto]

Is there any on going work for this usb network interface?

thanks

Paulo

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

NATD question...

[Paul A. Howes]

All,

I am trying to redirect a port on my FreeBSD 5.1-based firewall to an
internal machine.  My natd configuration contains a directive:

redirect-port 192.168.x.x:http  

I performed a "kill -HUP" on the natd process, but it doesn't work.  I can
verify that the internal Web server is functional, and accessible to the
internal network.  I even added ipfw rules to allow for traffic on port
, but still nothing.

Am I missing something obvious here?  Thanks!

--
Paul A. Howes

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.cscsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.csrc/sys/dev/firewire sbp.c

[Justin T. Gibbs]

> After this code is in both stable and current, current USB quirks will be
> deprecated but can be re-enabled in a pinch with a kernel option.
> Unfortunately, I only have contact information for the more recent quirks
> that were committed and so the only way to find devices that have other
> problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
> for devices that still fail.

Did you ever find the bug in the sync cache "silence errors" code that
was the root cause for most of the quirks?

--
Justin

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: savecore options

[Chad David]

On Mon, Jul 28, 2003 at 08:24:12AM -0400, David Hill wrote:
> Hello -
> savecore and its manpage are missing options.
> 
> savecore is missing -z and -N from its usage list.
> savecore manpage is missing -N.

-z is missing, but -N is obsolete and simply results in a usage()
message.

Does anyone object to actually removing -d and -N from the getopt()
list?  Who are we trying to maintain compatability with?  If it is
with -stable then now might be a good time to get rid of them.

-- 
Chad David[EMAIL PROTECTED]
www.FreeBSD.org   [EMAIL PROTECTED]
ISSci Inc.Calgary, Alberta Canada
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: LOR with filedesc structure and Giant

[Robert Watson]

On Sun, 27 Jul 2003, Kris Kennaway wrote:

> After upgrading last night, one of the package machines found this:

I've bumped into some similar problems -- it's a property of how we
current lock select().  We hold the file descriptor lock for the duration
of polling each object being "selected", and if any of those objects has
to grab a lock for any reason, it has to implicitly fall after the file
descriptor lock.  I actually run into this in some of our MAC code,
because I need to grab a vnode lock to authorize polling the vnode using
VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
WITNESS warning.  Unfortunately, it's not immediately clear what a better
locking scheme would look like without going overboard on the fine-grained
side.  We probably need to grab Giant before entering the select code
since it's highly likely something in there will require Giant -- it
reaches down into VFS, the device stuff, socket code, tc.

> lock order reversal
>  1st 0xc6c1c334 filedesc structure (filedesc structure) @
> /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902
>  2nd 0xc04aa120 Giant (Giant) @
> /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
> Stack backtrace:
> backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
> witness_lock(c04aa120,8,c0434e3d,174,1bc) at witness_lock+0x672
> _mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
> spec_poll(d8dddaf8,d8dddb18,c02d119c,d8dddaf8,c04939a0) at spec_poll+0x134
> spec_vnoperate(d8dddaf8,c04939a0,c520b124,40,c675e300) at spec_vnoperate+0x18
> vn_poll(c44c5e14,40,c675e300,c6222d10,c675e300) at vn_poll+0x3c
> selscan(c6222d10,d8dddb98,d8dddb88,6,4) at selscan+0x13e
> kern_select(c6222d10,6,bfbff5c0,0,0) at kern_select+0x36f
> select(c6222d10,d810,c0455899,3ee,5) at select+0x66
> syscall(2f,2f,2f,8055050,bfbff5b8) at syscall+0x273
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (93), eip = 0x280ccacc, esp = 0x2832eb68, ebp = 0x2832ebc0 ---
> Debugger("witness_lock")
> Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
> 
> Kris

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Last inline offenders...

[Doug Rabson]

The code in mga_stage.c is externally maintained. Its probably not a
good idea to edit that one.

On Wed, 2003-07-23 at 19:55, Poul-Henning Kamp wrote:
> The following patch are my suggestion (already sent to maintainers)
> for inlines to remove so we can get under the 2000 limit in GCC on
> i386.
> 
> 
> Index: dev/aic7xxx/aic79xx_inline.h
> ===
> RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_inline.h,v
> retrieving revision 1.12
> diff -u -r1.12 aic79xx_inline.h
> --- dev/aic7xxx/aic79xx_inline.h  28 Jun 2003 04:43:19 -  1.12
> +++ dev/aic7xxx/aic79xx_inline.h  23 Jul 2003 16:37:59 -
> @@ -451,7 +451,7 @@
>  static __inline void ahd_set_sescb_qoff(struct ahd_softc *ahd, u_int value);
>  static __inline u_intahd_get_sdscb_qoff(struct ahd_softc *ahd);
>  static __inline void ahd_set_sdscb_qoff(struct ahd_softc *ahd, u_int value);
> -static __inline u_intahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
> +static u_int ahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
>  static __inline u_intahd_inw_scbram(struct ahd_softc *ahd, u_int offset);
>  static __inline uint32_t
>   ahd_inl_scbram(struct ahd_softc *ahd, u_int offset);
> @@ -664,7 +664,7 @@
>   ahd_outb(ahd, SDSCB_QOFF+1, (value >> 8) & 0xFF);
>  }
>  
> -static __inline u_int
> +static u_int
>  ahd_inb_scbram(struct ahd_softc *ahd, u_int offset)
>  {
>   u_int value;
> Index: dev/drm/mga_state.c
> ===
> RCS file: /home/ncvs/src/sys/dev/drm/mga_state.c,v
> retrieving revision 1.6
> diff -u -r1.6 mga_state.c
> --- dev/drm/mga_state.c   25 Apr 2003 01:18:46 -  1.6
> +++ dev/drm/mga_state.c   23 Jul 2003 18:33:33 -
> @@ -71,7 +71,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g200_emit_context( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_context( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -97,7 +97,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g400_emit_context( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_context( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -128,7 +128,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
> @@ -159,7 +159,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
> @@ -203,7 +203,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[1];
> @@ -244,7 +244,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
> +static void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   unsigned int pipe = sarea_priv->warp_pipe;
> @@ -274,7 +274,7 @@
>   ADVANCE_DMA();
>  }
>  
> -static __inline__ void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
> +static void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
>  {
>   drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   unsigned int pipe = sarea_priv->warp_pipe;
> Index: dev/drm/r128_state.c
> ===
> RCS file: /home/ncvs/src/sys/dev/drm/r128_state.c,v
> retrieving revision 1.6
> diff -u -r1.6 r128_state.c
> --- dev/drm/r128_state.c  25 Apr 2003 01:18:46 -  1.6
> +++ dev/drm/r128_state.c  23 Jul 2003 18:33:33 -
> @@ -98,7 +98,7 @@
>   ADVANCE_RING();
>  }
>  
> -static __inline__ void r128_emit_context( drm_r128_private_t *dev_priv )
> +static void r128_emit_context( drm_r128_private_t *dev_priv )
>  {
>   drm_r128_sarea_t *sarea_priv = dev_priv->sarea_priv;
>   drm_r128_context_regs_t *ctx = &sarea_priv->context_state;
> @@ -140,7 +140,7 @@
>   ADVANCE_RING();
>  }
>  
> -static __inline__ void r128_emit_masks( drm_r128_private_t *dev_priv )
> +static void r128_emit_masks( drm_r128_private_t *dev_priv )
>  {
>   drm_r128_sarea_t *sarea_priv = dev_priv->sarea_pr

Re: Checking buildworld success from ssh

[Ruslan Ermilov]

On Mon, Jul 28, 2003 at 09:28:07AM -0400, Gregory Pavelcak wrote:
> Hi all,
> 
> I started a buildworld on current sources this morning, but,
> foolishly, didn't redirect the output to a file. Now I have some
> free time at work and would like to ssh in and do the kernel and
> mergemaster. Of course, I don't want to do these things if
> buildworld failed. Is there any way I can tell in the absence of
> saved output?
> 
The last thing made is creation of the freebsd.cf file.
See if it was created in /usr/obj/usr/src/etc/sendmail.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

Re: Highly loaded machine getting slower and slower

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Lukas Ertl writes:
>Hi there,
>
>I'm having again problems with a highly loaded 5.1-current machine.  The
>box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news
>server/feeder running diablo.  It's pumping out 120+Mbit/sec over Gigabit
>without a glitch, but after some time, it's getting slower and slower,
>until it seems to completely freeze, but it's still alive, just _very_
>unresponsive and in fact has to be rebooted.

Run a shell script in cron every 5 minutes where you record
date
sysctl kern.malloc
sysctl vm.zone
swapinfo
ps -axlw

and look out for anything which just gobbles up more and more
memory.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Highly loaded machine getting slower and slower

[Lukas Ertl]

Hi there,

I'm having again problems with a highly loaded 5.1-current machine.  The
box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news
server/feeder running diablo.  It's pumping out 120+Mbit/sec over Gigabit
without a glitch, but after some time, it's getting slower and slower,
until it seems to completely freeze, but it's still alive, just _very_
unresponsive and in fact has to be rebooted.

A kernel without WITNESS checks survives a few hours, a kernel with
WITNESS and friends stays up longer, but in fact after one, two weeks it's
the same picture.

If the machine seems to be stuck again and you break into the debugger,
you always get something like this:

db> where
_mtx_lock_sleep(c03fa6f0,0,0,0,) at _mtx_lock_sleep+0x1e6
msleep(c21be0ec,c03fa6f0,44,c03ad35b,0) at msleep+0x888
acquire(e3a81a38,100,600,11000,c6f23d10) at acquire+0xbe
lockmgr(c21be0ec,2,0,c6f23d10,11000) at lockmgr+0x3f7
_vm_map_lock(c21be0b0,0,0,e3a81a7c,e3a81a84) at _vm_map_lock+0x5d
kmem_alloc_wait(c21be0b0,11000,c6f2b4b0,c1618378,120) at
kmem_alloc_wait+0x38
kern_execve(c6f23d10,bfbff410,bfbff2fc,bfbffd60,0) at kern_execve+0x219
execve(c6f23d10,e3a81d10,c,c022c1e6,3) at execve+0x30
syscall(2f,2f,2f,bfbff490,bfbff2fc) at syscall+0x2b0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (59, FreeBSD ELF32, execve), eip = 0x481132df, esp =
0xbfbff2ec, ebp = 0  378 ---

The machine is running about 250+ concurrent diablo/dnewslink processes.

Any hints or ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Checking buildworld success from ssh

[Gregory Pavelcak]

Hi all,

I started a buildworld on current sources this morning, but,
foolishly, didn't redirect the output to a file. Now I have some
free time at work and would like to ssh in and do the kernel and
mergemaster. Of course, I don't want to do these things if
buildworld failed. Is there any way I can tell in the absence of
saved output?

Thanks.

Greg

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Memory Mangement Problem in 5.1-RELEASE

[Daniel C. Sobral]

Ahmed Al-Hindawi wrote:
If your system is spending a lot of time moving data to and from swap 
when it is not memory-starved, or if it is stalling memory allocations 
that it should be able to fulfill from free RAM, that's a concern.


That is exactly it. I emphaises th words " when it is not memory-starved 
". It isn't memory starved.

Also I get 150Mb frequently of swap disk space, whilst still having a 
complete third of my memory free!!

I can understand everyones view on this, that the swap algorithim is 
swaping pre-emtively. But 150MB?? Is that what is called a low level of 
swaping??
From the set of applications you listed, 150 MB doesn't even sound all 
that much. 300MB-400MB is the footprint I'd expect for that.

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Weiner's Law of Libraries:
There are no answers, only cross references.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

savecore options

[David Hill]

Hello -
savecore and its manpage are missing options.

savecore is missing -z and -N from its usage list.
savecore manpage is missing -N.

Thanks
David
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Fwd: new search tool for FreeBSD community

[Vlad Shabanov]

Dear Sir(s),

Rambler (www.rambler.ru) developed new search tool working
with FreeBSD project mail archives. You can try it at 
 http://freebsd.rambler.ru/

Index contains messages from all mail archives including cvs commits,
bug reports, etc. We plan to update database daily.

Any comments, suggestions, bug-reports welcome.

Best regards,
Vladislav Shabanov, Rambler
e-mail: [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: broken world

[Martin Blapp]

I should sleep more !

> /usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error
> before string constant
> /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef
> *** Error code 1

Sorry for the troubles I've caused.

Martin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: broken world

[Lukas Ertl]

On Mon, 28 Jul 2003, Jan Willem Knopper wrote:

> /usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error
> before string constant
> /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef
> *** Error code 1
>
> This error also occurs in isc-dhcp/includes/dhcpd.h:45 an possibly in
> more files.
>
> The source looks like:
>
> #ifndef lint
> "$FreeBSD: src/contrib/isc-dhcp/includes/dhcpd.h,v 1.2 2003/07/28 08:30:11 mbr Exp 
> $\n";
> #endif /* not lint */

This was fixed in rev. 1.3 of src/contrib/isc-dhcp/common/dispatch.c.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

broken world

[Jan Willem Knopper]

/usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error
before string constant
/usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef
*** Error code 1

This error also occurs in isc-dhcp/includes/dhcpd.h:45 an possibly in
more files.

The source looks like:

#ifndef lint
"$FreeBSD: src/contrib/isc-dhcp/includes/dhcpd.h,v 1.2 2003/07/28 08:30:11 mbr Exp 
$\n";
#endif /* not lint */

This is with a recently cvsupped current. It is probably caused by a
commit by mbr about three hours ago.

Jilles Tjoelker,
Jan Willem Knopper
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: device driver memory leak in 5.1-20030726?

[Gary Jennejohn]

John-Mark Gurney writes:
> 
> --E/DnYTRukya0zdZ1
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> Lukas Ertl wrote this message on Mon, Jul 28, 2003 at 01:11 +0200:
> > Then I have no explanation.  I'm running the box with a WiFi card,
> > generating lots of network traffic, and the box is running fine, no
> > panics, and low devbuf allocation.  I'm running the box with the USB
> > Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM
> > link), and the box panics within half an hour in kmem_malloc, with devbuf
> > allocation up to 74MB.  It must be either in the Bluetooth code or in the
> > USB code.
> 
> Upon futher looking at the code, I have a better fix for this.  Let me
> know how things go for you.
> 

It appears to me that the test in usb_block_allocmem() should be
(p->tag->parent == tag || p->tag->parent == tag->parent) and NOT
p->tag == tag! That's because bus_dma_tag_create() uses the tag
passed into usb_block_allocmem() as newtag->parent!

Unfortunately, bus_dma_tag is an opaque type and there's no way to
access the parent member anywhere but in the MD busdma_machdep.c :-(

Anyway, as written there's no way that I can see that the code can
work correctly.

---
Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

panic: sleeping thread owns a mutex

[Kris Kennaway]

One of the alpha package machines just died with the following:

panic: sleeping thread owns a mutex
panic() at panic+0x160
propagate_priority() at propagate_priority+0x148
_mtx_lock_sleep() at _mtx_lock_sleep+0x264
_mtx_lock_flags() at _mtx_lock_flags+0x84
_vm_map_lock() at _vm_map_lock+0x40
vm_map_remove() at vm_map_remove+0x34
kmem_free() at kmem_free+0x34
pipe_free_kmem() at pipe_free_kmem+0xbc
pipeclose() at pipeclose+0x188
pipe_close() at pipe_close+0x40
fdrop_locked() at fdrop_locked+0x180
fdrop() at fdrop+0x50
closef() at closef+0x260
fdfree() at fdfree+0x3c4
exit1() at exit1+0x578
sys_exit() at sys_exit+0x58
syscall() at syscall+0x338
XentSys() at XentSys+0x64
--- syscall (1, FreeBSD ELF64, sys_exit) ---
--- user mode ---
db>

(gdb -k is still broken on alpha, so I can't do better).  The machine
is running a kernel from June 20.

Kris


pgp0.pgp
Description: PGP signature

[RESOLVED] Belkin F5D5020 PCMCIA Card/Notebook Network Card

[Nick H. - Network Operations]

I auctually got it working under FreeBSD 4.8.  Eventually (read: after next
weekend) I plan on attempting to get it working under 5.X.  Unfortunately I
need the laptop for an event that is happening this week.  Anyways, it's
working and  here's the relevant file settings used:

## FOR FREEBSD 4.X ##
/etc/rc.conf:

pccard_enable="YES"
pccard_mem="DEFAULT"
pccardd_flags=" -i 10"


the -i 10 sets the IRQ on the device to 10 (dont ask how I found it... Ive
already closed Opera ;D)

and it's using the following in the /etc/defaults/pccard.conf:

# Belkin F5D5020
card "Belkin" "F5D5020-PCMCIA-Network-Card"
config  auto "ed" ? 0x10
insert  /etc/pccard_ether $device start
remove  /etc/pccard_ether $device stop


The thing is up and running fine.  dmesg output:

pcic0: Polling mode
pccard0:  on pcic0
pccard1:  on pcic0
...
pccard: card inserted, slot 0
...
Setup PC-CARD:
 memory
 beep
 pccardd
...
Jul 28 03:55:30  pccardd[47]: Card "Belkin"("F5D5020-PCMCIA-Network-Card")
[V1]
[0] matched "Belkin" ("F5D5020-PCMCIA-Network-Card") [(null)] [(null)]
...
Jul 28 03:55:35  pccardd[47]: ed1: Belkin (F5D5020-PCMCIA-Network-Card)
inserted.
...
Jul 28 03:56:45  pccardd[47]: pccardd started


The device is running just fine.  Hopefully, this is of some help to you, as
if I understand you correctly, you're having issues with the IRQ setting.
Try the pccardd_flags=" -i ##"  where ## is the IRQ you want it to use.
Anyways, all is working well now.





Regards,
Nick H.
[EMAIL PROTECTED]

- Original Message -
From: "Brad Knowles" <[EMAIL PROTECTED]>
To: "Nick H. - Network Operations" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "M. Warner Losh" <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 3:23 AM
Subject: Re: Belkin F5D5020 PCMCIA Card/Notebook Network Card


: At 2:38 AM -0500 2003/07/28, Nick H. - Network Operations wrote:
:
: >  Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card
exist
: >  in FreeBSD 5.0-RELEASE?  According to Belkin, it does, but I have been
: >  unable to find any support for this card.  Any suggestions on the right
: >  place to look are more than welcome.
:
: Back in October of last year, I cooked up a pccard.conf entry for
: it that seemed to mostly work:
:
: # Belkin F5D5020 NE2000-compatible card (FCC ID: LXLC1LANTB)
: card "Belkin" "F5D5020-PCMCIA-Network-Card"
:  config auto "ed" ?
:  logstr "Belkin F5D5020 10/100 Base-TX Ethernet 16-bit PCMCIA
: card (NE2000-compatible)"
:  insert /etc/pccard_ether $device start
:  remove /etc/pccard_ether $device stop
:
:
: I submitted this to Warner Losh, but IIRC, I got an indication
: back that this wasn't right.  However, I don't recall that I ever got
: any correct pccard.conf setting for this device, and while I could
: get FreeBSD to see the card and use this entry to mostly recognize
: it, I could not actually get any positive network results this way.
:
: Any additional information you can find would be appreciated.
: Right now, I'm using a Linksys (EtherFast 10/100 Integrated PC Card
: (PCM100) on the machine where I was trying to use the Belkin, but it
: sticks out from the machine and blocks the second PC Card slot, so
: I'd prefer to use the Belkin (which is flush with the edge and comes
: with a dongle), if possible.
:
: If I could get them both working, or get one of them working with
: one of my various 802.11b WiFi cards, then I would have two NICs and
: could do some much more interesting things with this machine.
: Unfortunately, everything seems to want IRQ3, so even if I could get
: the individual cards working by themselves, I don't know if I could
: ever get them working together.
:
:
: I did find an interesting entry at
: ,
: at the bottom (dated April 2002) that shows the pccard.conf entry of:
:
: # Belkin F5D5020
: card "Belkin" "F5D5020-PCMCIA-Network-Card"
: config  auto "ed" ? 0x10
: insert  /etc/pccard_ether $device start
: remove  /etc/pccard_ether $device stop
:
: Which the author claims (claimed) works (worked) for him.
:
:
: You can see my posts from October of last year at
:
,
:
,
: and
:
.
: And then there's the post at
:

: from April, which also mentions this card.
:
: But still, no answers to this question.  Unfortunately, just
: Googling for "Belkin F5D5020 FreeBSD" doesn't do much good, as it
: turns up many resellers of this card which claims that it works with
: FreeBSD, or articles that happen to mention both FreeBSD and this
: card on the same page (such as
: <

Re: device driver memory leak in 5.1-20030726?

[Lukas Ertl]

On Sun, 27 Jul 2003, John-Mark Gurney wrote:

> Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200:
> > I have different core dumps and backtraces available, but they don't seem
> > to be of much use in this case. I really suspect the USB stuff to be
> > leaking.
>
> Ok, if you truely think this is the case, recompile w/ USB_DEBUG, and
> after everything is setup, and you see devbuf steadily increasing, set
> the sysctl hw.usb.debug to 7.  Take about 10k or so of that, and send
> it to me.  That should let me know if we are leaking.

You can find lots of logging at
.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Belkin F5D5020 PCMCIA Card/Notebook Network Card

[Brad Knowles]

At 2:38 AM -0500 2003/07/28, Nick H. - Network Operations wrote:

 Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist
 in FreeBSD 5.0-RELEASE?  According to Belkin, it does, but I have been
 unable to find any support for this card.  Any suggestions on the right
 place to look are more than welcome.
	Back in October of last year, I cooked up a pccard.conf entry for 
it that seemed to mostly work:

# Belkin F5D5020 NE2000-compatible card (FCC ID: LXLC1LANTB)
card "Belkin" "F5D5020-PCMCIA-Network-Card"
config	auto "ed" ?
logstr	"Belkin F5D5020 10/100 Base-TX Ethernet 16-bit PCMCIA 
card (NE2000-compatible)"
insert	/etc/pccard_ether $device start
remove	/etc/pccard_ether $device stop

	I submitted this to Warner Losh, but IIRC, I got an indication 
back that this wasn't right.  However, I don't recall that I ever got 
any correct pccard.conf setting for this device, and while I could 
get FreeBSD to see the card and use this entry to mostly recognize 
it, I could not actually get any positive network results this way.

	Any additional information you can find would be appreciated. 
Right now, I'm using a Linksys (EtherFast 10/100 Integrated PC Card 
(PCM100) on the machine where I was trying to use the Belkin, but it 
sticks out from the machine and blocks the second PC Card slot, so 
I'd prefer to use the Belkin (which is flush with the edge and comes 
with a dongle), if possible.

	If I could get them both working, or get one of them working with 
one of my various 802.11b WiFi cards, then I would have two NICs and 
could do some much more interesting things with this machine. 
Unfortunately, everything seems to want IRQ3, so even if I could get 
the individual cards working by themselves, I don't know if I could 
ever get them working together.

	I did find an interesting entry at 
, 
at the bottom (dated April 2002) that shows the pccard.conf entry of:

# Belkin F5D5020
card "Belkin" "F5D5020-PCMCIA-Network-Card"
config  auto "ed" ? 0x10
insert  /etc/pccard_ether $device start
remove  /etc/pccard_ether $device stop
	Which the author claims (claimed) works (worked) for him.

	You can see my posts from October of last year at 
, 
, 
and 
. 
And then there's the post at 
 
from April, which also mentions this card.

	But still, no answers to this question.  Unfortunately, just 
Googling for "Belkin F5D5020 FreeBSD" doesn't do much good, as it 
turns up many resellers of this card which claims that it works with 
FreeBSD, or articles that happen to mention both FreeBSD and this 
card on the same page (such as 
), but which don't 
actually provide any solutions.

--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SSH from host to jail

[Artem 'Zazoobr' Ignatjev]

28.07.2003, 00:25, Pat Lashley wrote:
> I'm trying to set up some jails in a 5.1R system.  I've pretty much
> copied a setup that was working fine in 4.8; but on 5.1 I can't seem
> to SSH from the host system into one of its jails.  It acts like the
> packets just aren't getting through.
> 
> I would really appreciate it if somebody would send me rc.conf fragments
> that are known to work for setting up a jail's IP alias and routing on
> 5.1.
Errr... Random shot: 
Have you told ssh on host not to listen on all addresses it'll find?

I use 'ListenAddress' directive in /etc/ssh/sshd_config

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: device driver memory leak in 5.1-20030726?

[Mark Blackman]

Ok, you asked for it..

Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc1c92900
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 53 bytes
Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, 
pipe=0xc1bb5480, running=0
Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480
Jul 28 10:13:02 maddog kernel: usb_allocmem: use frag=0xc18b1ec0 size=53
Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 
status=0 actlen=53
Jul 28 10:13:02 maddog kernel: usb_freemem: frag=0xc18b1ec0
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0
Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 53
Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc1c92900
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5500 xfer=0xc19acc00 
status=0 actlen=53
Jul 28 10:13:02 maddog kernel: usb_freemem: large free
Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0
Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5500, xfer=0
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 53
Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc19acc00
Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc19acc00
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 1024 bytes
Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc19acc00, flags=4, 
pipe=0xc1bb5500, running=0
Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5500
Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 1024
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free
Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5500 running=0 timeout=0
Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc1c92900
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 106 bytes
Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, 
pipe=0xc1bb5480, running=0
Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480
Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 106
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free
Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 
status=0 actlen=106
Jul 28 10:13:02 maddog kernel: usb_freemem: large free
Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0
Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 106
Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc1c92900
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5500 xfer=0xc19acc00 
status=0 actlen=106
Jul 28 10:13:02 maddog kernel: usb_freemem: large free
Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096
Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0
Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5500, xfer=0
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 106
Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc19acc00
Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc19acc00
Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 1024 bytes
Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc19acc00, flags=4, 
pipe=0xc1bb5500, running=0
Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5500
Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 1024
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1
Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free
Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5500 running=0 timeout=0
Jul 28 10:13:07 maddog kernel: usbd_alloc_xfer() = 0xc1c92900
Jul 28 10:13:07 maddog kernel: usbd_bulk_transfer: start transfer 53 bytes
Jul 28 10:13:07 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, 
pipe=0xc1bb5480, running=0
Jul 28 10:13:07 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480
Jul 28 10:13:07 maddog kernel: usb_allocmem: use frag=0xc18b1ec0 size=53
Jul 28 10:13:07 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0
Jul 28 10:13:07 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 
status=0 actlen=53
Jul 28 10:13:07 maddog kernel: usb_freemem: frag=0xc18b1ec0
Jul 28 10:13:07 maddog kernel: usb_transfer_complete: repeat=0 new head=0
Jul 28 10:13:07 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0
Jul 28 10:13:07 maddog kernel: usbd_bulk_transfer: transferred 53
Jul 28 10:13:07 mad

Belkin F5D5020 PCMCIA Card/Notebook Network Card

[Nick H. - Network Operations]

Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist
in FreeBSD 5.0-RELEASE?  According to Belkin, it does, but I have been
unable to find any support for this card.  Any suggestions on the right
place to look are more than welcome.  Here's the mfg's site:

http://catalog.belkin.com/IWCatProductPage.process?Merchant_Id=1&Product_Id=
104984#
and the page that shows FreeBSD support:
http://www.belkin.com/network/F5D5020.html

Thanks!



Regards,
Nick H.
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"