RE: mutexes and modules

2003-01-07 Thread Andrew Gallatin

John Baldwin writes:
 > 
 > On 07-Jan-2003 Andrew Gallatin wrote:
 > > 
 > > Are kernel modules pessimized in any way with respect to using
 > > mutexes as compared to statically compiled kernel code?
 > > 
 > > I seem to remember some discussion a year or more ago indicating that
 > > they would be, but I'm not seeing it in the code.
 > 
 > In the non debug case the quick cases are not inlined in modules but
 > are always function calls.  Other than that there isn't much difference.

Thanks John..

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



sparc64 tinderbox failure

2003-01-07 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
>>> Rebuilding the temporary build tree
--
>>> 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 
>/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Tue Jan  7 22:18:05 GMT 2003
--
===> ums
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ums/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/ums.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cordless Keyboard + Mouse

2003-01-07 Thread Lars Eggert
Daniel O'Connor wrote:


Hmm odd..
I don't see why vidcontrol wouldn't work..
Does it print any error messages?


Do you use a serial console? vidcontrol fails to init the mouse then.

Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature


Re: panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-07 Thread David Schultz
Thus spake [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> >And to that fact I have a question:
> >At the moment 8% of the disk is reserved. 
> >It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
> >tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
> >But is for this size of spare space such a large threshold really required??
> >And IF i would like to experiment, where do I look for the knop to turn??
> 
> Basically you don't need to reserve anything, but as you get closer to
> filling the disk the time to find a free space increases rapidly and
> your files get very fragmented.  Trouble is: they never get defragmented
> unless you copy them (or do a full dump/restore).
> 
> I'm not sure how to nail the "right" number of % down, and I'm sure
> that both Kirk and I would like to hear your numbers :-)

If someone is interested in investigating this in detail, Margo
Setzer et alii did a study a few years ago on aging filesystems in
order to measure fragmentation.  Their intent was not to measure
the effect of free space on fragmentation, but their methodology
could be applied for that purpose.  They happen to have a graph
that suggests that large file throughput drops about 20% for a
filesystem that is 75% full versus a nearly empty filesystem.

http://www.eecs.harvard.edu/~vino/fs-perf/papers/sigmetrics.ps.gz

I don't think you'll find that it's a good idea to have a
filesystem more than 90% full.  At that load factor, even a
uniform hash will take on average 2.5 probes to locate free
space, and performance can only exponentially decrease from
there.  No filesystem can avoid fragmentation and perform well
without a bit of breathing room.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cordless Keyboard + Mouse

2003-01-07 Thread Daniel O'Connor
On Wed, 2003-01-08 at 06:02, Daren Desjardins wrote:
> I do use usbd, and it starts a moused service for the mouse at startup.
> However vidcontrol does not enable the console mouse. I used 'moused -i
> all -p /dev/usm0' and it prints out usb mouse etc, so it appears to be
> detecting it.

Hmm odd..
I don't see why vidcontrol wouldn't work..
Does it print any error messages?

-- 
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 - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: font failure in X

2003-01-07 Thread Roine Thunberg
On 7 Jan 2003, Eric Anholt wrote:

> On Tue, 2003-01-07 at 13:25, Alexander Leidinger wrote:
> > On Tue, 7 Jan 2003 02:46:49 +0100 (MET)
> > Roine Thunberg <[EMAIL PROTECTED]> wrote:
> >
> > > I recently installed 5.0-RC2 and X from ports and some programs too.
> > >
> > > Now I have trouble with huge font sizes. Mainly in webbrowsers. But it's
> > > only some kind of fonts. I just can't find the options and I can't see any
> > > logs telling me what's wrong. Seems like the fonts use the size 100
> > > instead of 10 or 12 that they normally do... suggestions ?
> >
> > Sometimes I get this too. I restart X or have to reboot then and
> > everything goes back to normal operation.
> >
> > Bye,
> > Alexander.
>
> One thing good might be to check your DisplaySize (grep Display
> /var/log/XFree86.0.log), since your DPI is calculated from that and
> things are using the DPI to calculate font sizes more and more.  For
> some reason it's probed wrong on my system (2500mm x 2500mm or some
> such).  Adding the following line to my XF86Config's Monitor section
> fixed it.
>   DisplaySize 310 270
>
> If this is the problem, could you tell me what card you're using?
>


That did actually helped me. Thanks Eric.

Without "DisplaySize" it probed...

(--) ATI(0): Display dimensions: (10, 10) mm
(--) ATI(0): DPI set to (3251, 2600)

With "DisplaySize 310 270"

(**) ATI(0): Display dimensions: (310, 270) mm
(WW) ATI(0): Probed monitor is 10x10 mm, using Displaysize 310x270 mm
(**) ATI(0): DPI set to (104, 96)






(--) ATI(0): ATI 3D Rage Pro graphics controller detected.
(--) ATI(0): Chip type 4742 "GB", version 4, foundry UMC, class 0,
revision 0x01
.
(--) ATI(0): AGP bus interface detected;  block I/O base is 0xC000.
(--) ATI(0): ATI Mach64 adapter detected.
(!!) ATI(0): For information on using the multimedia capabilities
 of this adapter, please see http://gatos.sf.net.
(--) ATI(0): Internal RAMDAC (subtype 1) detected.
(==) ATI(0): RGB weight 888
(==) ATI(0): Default visual is TrueColor
(==) ATI(0): Using gamma correction (1.0, 1.0, 1.0)
(II) ATI(0): Using Mach64 accelerator CRTC.




-
Roine Thunberg


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: mutexes and modules

2003-01-07 Thread John Baldwin

On 07-Jan-2003 Andrew Gallatin wrote:
> 
> Are kernel modules pessimized in any way with respect to using
> mutexes as compared to statically compiled kernel code?
> 
> I seem to remember some discussion a year or more ago indicating that
> they would be, but I'm not seeing it in the code.

In the non debug case the quick cases are not inlined in modules but
are always function calls.  Other than that there isn't much difference.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



mutexes and modules

2003-01-07 Thread Andrew Gallatin

Are kernel modules pessimized in any way with respect to using
mutexes as compared to statically compiled kernel code?

I seem to remember some discussion a year or more ago indicating that
they would be, but I'm not seeing it in the code.

Thanks,

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Dual CPU (Intel 1.26ghz) -- Need Help Enabling

2003-01-07 Thread Nick H. -- Technical Support Engineer
Hey guys/gals,

Ive run into a little snag here that Im needing some help with.  Ive enabled
SMP and APIC_IO in the kernel of a 4.7-RELEASE-p3 machine (cvsup'd yesterday
and installed all) yet everything is still showing just one cpu.  Im
positive it's a dual machine cause when I built it I tossed 2 CPUs in =P
Does anyone have any ideas on how to get the second one enabled?

Email me if you wish to see the system information (phpSysInfo) and any
other information you care to see to assist me.  Thanks for the help ;)


Regards,
Nick "Harm" Hale
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Proper -current if_attach locking?

2003-01-07 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Andrew Gallatin <[EMAIL PROTECTED]> writes:
: 
: M. Warner Losh writes:
:  > In message: <[EMAIL PROTECTED]>
:  > Andrew Gallatin <[EMAIL PROTECTED]> writes:
:  > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
:  > : list of ifnet structs to ensure that no devices are removed or added
:  > : while something may be using it.  There is one ifnet list in the system.
:  > 
:  > So this means that only the locking in attach is bogus, and similar
:  > locking in detach is also bogus because they produce lock order
:  > reversals as the global lock is held to insert/remove if interfaces.
: 
: Yes.  Though I haven't looked at if_dc myself, there may be other
: locking problems.  I've only been commenting on the ones that you
: brought up.
: 
: But back to an earlier point.  Somebody (you?) validly pointed out
: that the driver should not be callable and should not generate
: interrupts until its finished attaching.  The lock in its attach was
: probably a somewhat misguided attempt at that.  

Yes.  That was me.  There are some drivers that have separated
front/back ends that makes this harder, but most of them don't.

: The first point can be accomplished by doing the ether_ifattach()
: last, but the second may be harder.  I do that by poking a bit on my
: card which prevents it from generating interrupts while the device is
: being setup.  Not sure if a similar bit exists on tulip cards.

All PCI cards have to be able to turn off their interrupt sources,
otherwise interrupt storms result.  At least that's my understanding.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cordless Keyboard + Mouse

2003-01-07 Thread Daren Desjardins
On Mon, 2003-01-06 at 21:10, Daniel O'Connor wrote:
> On Tue, 2003-01-07 at 12:16, Daren Desjardins wrote:
> > > > ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1
> > > > ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1
> > > 
> > > Mine shows us as a ps/2 mouse.  Is this a USB setup?  Mine's a normal
> > > non-USB setup.
> > 
> > Single wire coming out that splits into a PS/2 connector and a USB
> > connector. If I plug just the USB connector in, dmesg shows both devices
> > however the kb doesnt work. Plugging in just the ps/2 plug I get kb
> > support but dmesg doesnt show the mouse. So I plug both in and have both
> > devices listed.
> > 
> > I also tried configuring xfree to use /dev/ums0 directly but it still
> > dies with no core pointer.
> 
> Personally I'd run usbd and let it run moused for you and then do..
> 
> vidcontrol -m on
> 
> And see if the mouse works there. Check that usbd is running and that it
> started moused.
> 

I do use usbd, and it starts a moused service for the mouse at startup.
However vidcontrol does not enable the console mouse. I used 'moused -i
all -p /dev/usm0' and it prints out usb mouse etc, so it appears to be
detecting it.

> The keyboard won't work unless you tell usbd to change the console
> keyboard using 'kbdcontrol -k devname' I believe (I have never used a
> USB keyboard)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



i386 tinderbox failure

2003-01-07 Thread Dag-Erling Smorgrav
--
>>> Rebuilding the temporary build tree
--
>>> 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/i386/obj/local0/scratch/des/src/i386/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Tue Jan  7 09:37:38 PST 2003
--
>>> Kernel build for GENERIC completed on Tue Jan  7 10:29:04 PST 2003
--
>>> Kernel build for LINT started on Tue Jan  7 10:29:05 PST 2003
--
===> vesa
"Makefile", line 5396: warning: duplicate script for target "geom_bsd.o"  [...]
"Makefile", line 5399: warning: duplicate script for target "geom_mbr.o"  [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_TH [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `Acp [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cas [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: c [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MO [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_M [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acp [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acp [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment disca [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1254: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1266: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ie_readframe':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1312: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `iestart':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1412: warning: passing arg 2 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1425: warning: cast discards q [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `check_ie_present':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1479: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1488: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1491: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie

Re: font failure in X

2003-01-07 Thread Eric Anholt
On Tue, 2003-01-07 at 13:25, Alexander Leidinger wrote:
> On Tue, 7 Jan 2003 02:46:49 +0100 (MET)
> Roine Thunberg <[EMAIL PROTECTED]> wrote:
> 
> > I recently installed 5.0-RC2 and X from ports and some programs too.
> > 
> > Now I have trouble with huge font sizes. Mainly in webbrowsers. But it's
> > only some kind of fonts. I just can't find the options and I can't see any
> > logs telling me what's wrong. Seems like the fonts use the size 100
> > instead of 10 or 12 that they normally do... suggestions ?
> 
> Sometimes I get this too. I restart X or have to reboot then and
> everything goes back to normal operation.
> 
> Bye,
> Alexander.

One thing good might be to check your DisplaySize (grep Display
/var/log/XFree86.0.log), since your DPI is calculated from that and
things are using the DPI to calculate font sizes more and more.  For
some reason it's probed wrong on my system (2500mm x 2500mm or some
such).  Adding the following line to my XF86Config's Monitor section
fixed it.
DisplaySize 310 270

If this is the problem, could you tell me what card you're using?

-- 

Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/dri/ [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Proper -current if_attach locking?

2003-01-07 Thread Andrew Gallatin

M. Warner Losh writes:
 > In message: <[EMAIL PROTECTED]>
 > Andrew Gallatin <[EMAIL PROTECTED]> writes:
 > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
 > : list of ifnet structs to ensure that no devices are removed or added
 > : while something may be using it.  There is one ifnet list in the system.
 > 
 > So this means that only the locking in attach is bogus, and similar
 > locking in detach is also bogus because they produce lock order
 > reversals as the global lock is held to insert/remove if interfaces.

Yes.  Though I haven't looked at if_dc myself, there may be other
locking problems.  I've only been commenting on the ones that you
brought up.

But back to an earlier point.  Somebody (you?) validly pointed out
that the driver should not be callable and should not generate
interrupts until its finished attaching.  The lock in its attach was
probably a somewhat misguided attempt at that.  

The first point can be accomplished by doing the ether_ifattach()
last, but the second may be harder.  I do that by poking a bit on my
card which prevents it from generating interrupts while the device is
being setup.  Not sure if a similar bit exists on tulip cards.

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Proper -current if_attach locking?

2003-01-07 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Andrew Gallatin <[EMAIL PROTECTED]> writes:
: The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
: list of ifnet structs to ensure that no devices are removed or added
: while something may be using it.  There is one ifnet list in the system.

So this means that only the locking in attach is bogus, and similar
locking in detach is also bogus because they produce lock order
reversals as the global lock is held to insert/remove if interfaces.

: The lock in IF_PREPEND() (and more commonly used in drivers,
: IF_DEQUE()) is per-ifq, to protect against multiple accesses 
: to a single  ifq.  There are many ifqs in the system.

I knew I must have been missing something really fundamental last
night.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Sound playback problem with Maestro3.c (?)

2003-01-07 Thread Michael Ferguson

Hi all,

I'm experiencing a small issue with the sound output on the
Maestro3 in my Dell Inspiron 8000 laptop. Every few seconds, the sound
is briefly "interrupted", and the last few ms of audio are looped for
about a quarter of a second. I've noticed that this can happen
independently on either channel; often it will pause/loop on the left
channel, then shortly thereafter on the right, or visa versa. Other
times it will pause/loop on both channels at the same time.

I've also noticed this condition can be exaggerated by moving
the mouse while moused is running; the sound pause/loops much more
frequently (although not for as long), and the music becomes noticeably
slower. This happens both when moving the built-in PS/2 touchpad mouse
and on a USB mouse, if I plug one in. My only ignorant guess would be
that this is some kind of interrupt polling issue, but since I am new to
BSD and I have no clue about the driver architecture or PCM, I can only
venture a guess. :/

I was experiencing this in the 4.7-release kernel also (this bug
is actually why I upgraded to -current :P). Some other users appear to
be having the same problems (even when porting the driver to NetBSD?).
Here are some links:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF8&threadm=a6u7p
2%24vlc%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1&prev=/groups%3Fq%3DFreeBSD
%2BMaestro3%2Bpopping%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF8%26selm%
3Da6u7p2%2524vlc%25241%2540FreeBSD.csie.NCTU.edu.tw%26rnum%3D1

http://mail-index.netbsd.org/current-users/2001/08/23/0004.html

I tried compiling without PNP and APM in the 4.7-release kernel,
but I still saw the same issues, so I don't think they're entirely tied
to that (especially since I'm running ACPI now in -current, without any
apmd). My laptop is running the latest bios (A21), and the sound card
has ID card=0x00a41028 chip-0x1998125d rev=0x10; my dmesg and pciconf
output are also at ftp://129.110.23.84/.

On a probably-unrelated side note, when I was running Linux on
the same laptop (ducks), I had issues with the OS clock getting quickly
out of sync with the HW clock; typically I would loose five minutes or
more every hour. Although I haven't experienced the same thing with
FreeBSD, I wonder if there is just something odd about interrupt
handling or timing on the Inspiron 8000 line? 

Best regards,



-- mcf




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



sparc64 tinderbox failure

2003-01-07 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
>>> Rebuilding the temporary build tree
--
>>> 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 
>/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Tue Jan  7 16:18:02 GMT 2003
--
===> unionfs
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/unionfs/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/unionfs.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread Soeren Schmidt
It seems [EMAIL PROTECTED] wrote:
>  | man atacontrol :)
> 
> I did that but it sounded too easy :)  

It actually is :)

>  | However if you want to use RAID1+0 and you want to be able to
>  | boot from it you *need* a RAID capable controller BIOS, there is
>  | no way to make a stock BIOS boot from a RAID0...
>  | If you need it on install you probably also need at RAID capable
>  | controller, if you define the RAID BIOS there, it will show up
>  | in sysinstall..
> 
> The solution that pops into my mind is to have a small ad0 for boot 
> and / partition. and ad1,ad2,ad3 as raid0+1 or ad1 and 2 as raid1
> raid1 should solve my problem.  Would either of these be configurable 
> on sysinstall to have the /var and /usr partitions on the raid disks?
> If not that should be easy enough after a minimal install and reboot
> on ad0.

You need 4 disks for RAID0+1, and if you want to see the RAID's in
sysinstall you need to have them created first, either by having
a "real" ATA RAID controller, or having made it beforehand on the
disks in possibly another machine or from a minimal install.
Once the RAID's has been setup, sysinstall will pick them up..
(Maybe one can boot the fixit thingy and run atacontrol from the
live filesystem, havn't tried)...

>  | No, the RAID part of the ATA driver has nothing to do with vinum.
>  | Vinum has several limitations that make it useless in this context.
>  | Mainly that the RAID config layout on disk need to be of different
>  | formats depending on what controller BIOS we have, and there is no
>  | place to put all the extra volume stuff that vinum needs.
>  | The ATA RAID code is very generic instead, with backends that converts
>  | the internal RAID info to/from the needed info on disk depending
>  | on controller type.
> 
> Thanks for the clarification, Søren.  Please forgive my basic, uninitiated
> questions.  I really should probably have been paying more attention as 
> these features were being added.

No problem, feel free to ask, we add so many features to FreeBSD all
the time it can be hard to follow them all...

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread eculp
Quoting Soeren Schmidt <[EMAIL PROTECTED]>:

 | man atacontrol :)

I did that but it sounded too easy :)  

 | 
 | However if you want to use RAID1+0 and you want to be able to
 | boot from it you *need* a RAID capable controller BIOS, there is
 | no way to make a stock BIOS boot from a RAID0...
 | If you need it on install you probably also need at RAID capable
 | controller, if you define the RAID BIOS there, it will show up
 | in sysinstall..

The solution that pops into my mind is to have a small ad0 for boot 
and / partition. and ad1,ad2,ad3 as raid0+1 or ad1 and 2 as raid1
raid1 should solve my problem.  Would either of these be configurable 
on sysinstall to have the /var and /usr partitions on the raid disks?
If not that should be easy enough after a minimal install and reboot
on ad0.

 | 
 | > I haven't used vinum because of the root partition limitations and
 | > the complexity of the first configuration although I have been on the
 | > verge several times.  BTW, is this an integration of vinum?  To not
 | > have to be limited to hw raid by having similar flexibility and ease
 | > of use with software raid will be/is, IMO, fantastic.
 | 
 | No, the RAID part of the ATA driver has nothing to do with vinum.
 | Vinum has several limitations that make it useless in this context.
 | Mainly that the RAID config layout on disk need to be of different
 | formats depending on what controller BIOS we have, and there is no
 | place to put all the extra volume stuff that vinum needs.
 | The ATA RAID code is very generic instead, with backends that converts
 | the internal RAID info to/from the needed info on disk depending
 | on controller type.

Thanks for the clarification, Søren.  Please forgive my basic, uninitiated
questions.  I really should probably have been paying more attention as 
these features were being added.

ed


-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/s

2003-01-07 Thread John Baldwin

On 06-Jan-2003 ryan beasley wrote:
> On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote:
>> I'm including a GDB capture including traceback and some locking
>> information.  Anyone have any ideas?  Is there any other data I should
>> grab and submit?
> 
> I'm really sorry for following up to myself again, but the following
> might be useful:
> 
> (gdb)
>#8  0xc01bce28 in enroll (description=0xc02e3718 "vnode interlock",
> lock_class=0xc0300fc0)
> at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985
> 985 if (w->w_name == description || (w->w_refcount > 0 &&
> Current language:  auto; currently c
> (gdb) p *w
> $16 = {w_name = 0xc16fd8fe ,
>   w_class = 0xc0300fc0, w_list = {stqe_next = 0xc032fa50}, w_typelist = {
> stqe_next = 0xc032fa50}, w_children = 0x0, w_file = 0x0, w_line = 0,
>   w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0',
>   w_other_squawked = 0 '\0', w_same_squawked = 0 '\0'}
> 
> This is the instruction where the page fault occurred.  As to how w_name
> was clobbered, I have no idea.

Your 3rd party registered a lock somehow?  Does it do mtx_init() and not
do mtx_destroy() when being unloaded?

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread Soeren Schmidt
It seems [EMAIL PROTECTED] wrote:
>  | Doing "stuff" to your root filesystems is always dangerous, so you
>  | have been warned :)
> 
> Thanks, Søren.  Indeed I have:-)  I'll give it a try over the coming 
> weekend after backing up everything:).  Will this patch be committed to 
> the tree, before then?

Maybe, I'm still thinking about if I should make it an option in
atacontrol to do the mirror rebuild on create...

> This is really great news.  I sometimes feel like I live under a
> rock, I didn't realize that atacontrol raid was working so well.  
> Do you know of any documentation on setting it up on a new system
> install, especially atacontrol RAID1+0?  

man atacontrol :)

However if you want to use RAID1+0 and you want to be able to
boot from it you *need* a RAID capable controller BIOS, there is
no way to make a stock BIOS boot from a RAID0...
If you need it on install you probably also need at RAID capable
controller, if you define the RAID BIOS there, it will show up
in sysinstall..

> I haven't used vinum because of the root partition limitations and 
> the complexity of the first configuration although I have been on the
> verge several times.  BTW, is this an integration of vinum?  To not 
> have to be limited to hw raid by having similar flexibility and ease 
> of use with software raid will be/is, IMO, fantastic.

No, the RAID part of the ATA driver has nothing to do with vinum.
Vinum has several limitations that make it useless in this context.
Mainly that the RAID config layout on disk need to be of different
formats depending on what controller BIOS we have, and there is no
place to put all the extra volume stuff that vinum needs. 
The ATA RAID code is very generic instead, with backends that converts
the internal RAID info to/from the needed info on disk depending
on controller type.

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread eculp
Quoting Soeren Schmidt <[EMAIL PROTECTED]>:


 | Doing "stuff" to your root filesystems is always dangerous, so you
 | have been warned :)
 | 

Thanks, Søren.  Indeed I have:-)  I'll give it a try over the coming 
weekend after backing up everything:).  Will this patch be committed to 
the tree, before then?

This is really great news.  I sometimes feel like I live under a
rock, I didn't realize that atacontrol raid was working so well.  
Do you know of any documentation on setting it up on a new system
install, especially atacontrol RAID1+0?  

I haven't used vinum because of the root partition limitations and 
the complexity of the first configuration although I have been on the
verge several times.  BTW, is this an integration of vinum?  To not 
have to be limited to hw raid by having similar flexibility and ease 
of use with software raid will be/is, IMO, fantastic.

Thanks,

ed


-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread Soeren Schmidt
It seems [EMAIL PROTECTED] wrote:
> Søren,
> 
> This is a real temptation.  Let me be sure that I'm understanding 
> correctly.  I have an old machine, but running today's current, with only 
> one disk, ad0. Could I do the following?
> 
>   o- Add ad2
>   o- run atacontrol create RAID1 ad0 ad2 source ad0
>   o- change ad0s1a to ar0s1a through ad0s1f to ar0s1f in fstab
>   o- reboot and enjoy my new mirror.

Exactly, modulo the "source ad0" bit which is not in atacontrol (yet),
it will always the the first disk (ad0 here) in the mirror as the
master to make the mirror from.

> If ar0 were to die, I would just take it out connect ar2 and boot as ?
> I could then do the same with a new mirror, I suppose?

If one of the disks die, you can boot on the degraded mirror, one
caveat is that your BIOS might not want to boot from "ad2" just
from "ad0", if thats the case swap the drives, and boot...
Then when you are up, atacontrol detach the failed device, swap
it with a new one, atacontrol attach, atacontrol rebuild, voila...

Another way is to boot the degraded mirror, then when its up you
do a atacontrol delete to get rid of the mirror, remember to change
your fstab back to adX instead of arX, and reboot...

> If I'm understanding correctly, I could use any disk > ad0 as the mirror.
> Is that correct?  

Yes, as it is currently it must be on another non-RAID controller, or
the BIOS on there will get mighty confused only having part of a
RAID config on it :)

> One last question, what prompted you to preceed the patch with 
> "For those that are brave enough to play with this", where could
> it come back and bit me? :-)

Doing "stuff" to your root filesystems is always dangerous, so you
have been warned :)

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Proper -current if_attach locking?

2003-01-07 Thread Andrew Gallatin

M. Warner Losh writes:
<..>
 > However in if_slowtimo we have:
 > 
 > if_slowtimo(arg)
 > {
 > ...  IFNET_RLOCK();
 > ...  if (ifp->if_watchdog)
 >  (*ifp->if_watchdog)(ifp);
 > ...  IFNET_RUNLOCK();
 > }
 > 
 > and dc_watchdog does a DC_LOCK/UNLOCK pair).  This is a Lock Order
 > Reversal, and not a LotR :-)
 > 
 > What's worse is that dc_intr does:
 > 
 > DC_LOCK
 > ...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing)
 > DC_UNLOCK
 > 
 > So even if we remove the one from attach, it looks like we have others
 > lurking in the code.
 > 
 > Either that, or it is too late for me to be looking at code like this
 > :-(
 > 

I think its too late at night ;)

The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
list of ifnet structs to ensure that no devices are removed or added
while something may be using it.  There is one ifnet list in the system.

The lock in IF_PREPEND() (and more commonly used in drivers,
IF_DEQUE()) is per-ifq, to protect against multiple accesses 
to a single  ifq.  There are many ifqs in the system.

FWIW, I've been running my 3rd party Myrinet driver Giant-free and
have had no problems, and no lock order reversals.  I don't do bogus
locking in my attach routine, though :)

FWIW2: Running Giant-free brings -current TCP performance up to nearly
63% of -stable performance (from 39%), and udp xmit perf up to 87% of
-stable.  (testing w/o WITNESS).

Drew



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread eculp
Quoting Soeren Schmidt <[EMAIL PROTECTED]>:

 | It seems Soeren Schmidt wrote:
 | >
 | > It should work on 4.7 forward, but its been a while since I played with
 | it.
 | > Another thing is that its a pain to make a mirror on an already running
 | > system (which is often wanted), so I plan to add an option to atacontrol
 | > to tell where to get the master from, and then do an automatic rebuild
 | > during the create phase ie:
 | >
 | > atacontrol create RAID1 ad0 ad2 source ad0
 | >
 | > This will create a mirror using ad0 and ad2, and start a rebuild to
 | > build the master with data from ad0. This way you can do a normal
 | > install, add a second (identical or bigger) disk, and make a
 | > mirror out of those. You just have to change your fstab before
 | > rebooting (ad0 -> ar0) in order to boot...
 | 
 | For those that are brave enough to play with this I just created the
 | following small change to ata-raid.c. Now it will always rebuild the
 | array on creation, using the first disk as the master image. This
 | allows you to turn any set of ATA disks into a mirror on the fly..
 | Remember to rename you filesystems in fstab before booting :)
 | 
 | Index: ata-raid.c
 | ===
 | RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.c,v
 | retrieving revision 1.50
 | diff -u -r1.50 ata-raid.c
 | --- ata-raid.c  2 Oct 2002 07:44:17 -   1.50
 | +++ ata-raid.c  7 Jan 2003 10:02:50 -
 | @@ -374,7 +374,14 @@
 |  rdp->flags |= AR_F_READY;
 | 
 |  ar_table[array] = rdp;
 | +
 | +/* kick off rebuild here */
 | +if (setup->type == 2) {
 | +   rdp->disks[1].flags &= ~AR_DF_ONLINE;
 | +   rdp->disks[1].flags |= AR_DF_SPARE;
 | +}
 |  ar_attach_raid(rdp, 1);
 | +ata_raid_rebuild(array);
 |  setup->unit = array;
 |  return 0;
 |  }

Søren,

This is a real temptation.  Let me be sure that I'm understanding 
correctly.  I have an old machine, but running today's current, with only 
one disk, ad0. Could I do the following?

  o- Add ad2
  o- run atacontrol create RAID1 ad0 ad2 source ad0
  o- change ad0s1a to ar0s1a through ad0s1f to ar0s1f in fstab
  o- reboot and enjoy my new mirror.

If ar0 were to die, I would just take it out connect ar2 and boot as ?
I could then do the same with a new mirror, I suppose?

If I'm understanding correctly, I could use any disk > ad0 as the mirror.
Is that correct?  

One last question, what prompted you to preceed the patch with 
"For those that are brave enough to play with this", where could
it come back and bit me? :-)

Thanks,

ed


-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cordless Keyboard + Mouse

2003-01-07 Thread Philip Paeps
On 2003-01-06 15:22:21 (-0500), Daren Desjardins <[EMAIL PROTECTED]> wrote:
> Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless
> kb/mouse combos to work?

Yes.  I have a Logitech Cordless Desktop and a Cordless TrackMan.  Both work
very happily.  I use the PS/2 plugs though, not the USB ones.  Don't know why,
just never occured to me to try the USB :-)

 - Philip

-- 
Philip Paeps  Please don't CC me, I am
[EMAIL PROTECTED]   subscribed to the list.

  It's always darkest before ... daylight saving time.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-07 Thread Willem Jan Withagen
> File get quite fragmented (enough to lose a factor of 2 or so of the
> disk's bandwidth) even when the disk is almost empty.  Then they don't
> get defragmented unless you copy them, etc.  The Real Fragmentation
> that occurs when a disk is nearly full loses a much larger factor of
> the disk's bandwidth.
> 
> > I'm not sure how to nail the "right" number of % down, and I'm sure
> > that both Kirk and I would like to hear your numbers :-)
> 
> I postprocess output from Kirk's block number printing program to
> produce fragmentation estimates.  All (non-null) seeks are considered
> to be fragmentation.  A (logical) non-null seek seems to be normal for
> about 10% of (logical) i/o's even in the favourable case of files
> created by copying to an initially empty filesystem (this is for
> small files like the ones in FreeBSD's src tree).

I'd be interested in that block number printing program too
After some discussion offline with Poul-Henning that was exactly what is one of the 
basic needs to do any analysis in this area: 
A way to determing a fragmentation degree/index.
Poul suggested then bean-counting in fsck, so I started looking there. But the 'block 
number printing' would generate even better data.

I'm building a system just for running some of these test on it.
Feel free to suggest or discuss the approach.

--WjW

èR{.nÇ+‰·¬zwfj)m¢f£¢·hškyàRŠàÂ+aº{.nÇ+‰·Ÿ­ç›±×.®·§¶)í…æèw*¶¦zˁ


Re: font failure in X

2003-01-07 Thread Alexander Leidinger
On Tue, 7 Jan 2003 02:46:49 +0100 (MET)
Roine Thunberg <[EMAIL PROTECTED]> wrote:

> I recently installed 5.0-RC2 and X from ports and some programs too.
> 
> Now I have trouble with huge font sizes. Mainly in webbrowsers. But it's
> only some kind of fonts. I just can't find the options and I can't see any
> logs telling me what's wrong. Seems like the fonts use the size 100
> instead of 10 or 12 that they normally do... suggestions ?

Sometimes I get this too. I restart X or have to reboot then and
everything goes back to normal operation.

Bye,
Alexander.

-- 
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-07 Thread Bruce Evans
On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote:

> In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes:
> >I was able to copy the full 100+Gb.
> >Next I'm going to try and fill the disk to the max as user, but i guess it'll not 
>trigger this bug.
> >
> >And to that fact I have a question:
> >At the moment 8% of the disk is reserved.
> >It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
> >tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
> >But is for this size of spare space such a large threshold really required??
> >And IF i would like to experiment, where do I look for the knop to turn??
>
> Basically you don't need to reserve anything, but as you get closer to
> filling the disk the time to find a free space increases rapidly and
> your files get very fragmented.  Trouble is: they never get defragmented
> unless you copy them (or do a full dump/restore).

File get quite fragmented (enough to lose a factor of 2 or so of the
disk's bandwidth) even when the disk is almost empty.  Then they don't
get defragmented unless you copy them, etc.  The Real Fragmentation
that occurs when a disk is nearly full loses a much larger factor of
the disk's bandwidth.

> I'm not sure how to nail the "right" number of % down, and I'm sure
> that both Kirk and I would like to hear your numbers :-)

I postprocess output from Kirk's block number printing program to
produce fragmentation estimates.  All (non-null) seeks are considered
to be fragmentation.  A (logical) non-null seek seems to be normal for
about 10% of (logical) i/o's even in the favourable case of files
created by copying to an initially empty filesystem (this is for
small files like the ones in FreeBSD's src tree).

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mirrored root fs?

2003-01-07 Thread Soeren Schmidt
It seems Soeren Schmidt wrote:
> 
> It should work on 4.7 forward, but its been a while since I played with it. 
> Another thing is that its a pain to make a mirror on an already running
> system (which is often wanted), so I plan to add an option to atacontrol
> to tell where to get the master from, and then do an automatic rebuild
> during the create phase ie:
> 
> atacontrol create RAID1 ad0 ad2 source ad0
> 
> This will create a mirror using ad0 and ad2, and start a rebuild to
> build the master with data from ad0. This way you can do a normal
> install, add a second (identical or bigger) disk, and make a
> mirror out of those. You just have to change your fstab before
> rebooting (ad0 -> ar0) in order to boot...

For those that are brave enough to play with this I just created the
following small change to ata-raid.c. Now it will always rebuild the
array on creation, using the first disk as the master image. This
allows you to turn any set of ATA disks into a mirror on the fly..
Remember to rename you filesystems in fstab before booting :)

Index: ata-raid.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.c,v
retrieving revision 1.50
diff -u -r1.50 ata-raid.c
--- ata-raid.c  2 Oct 2002 07:44:17 -   1.50
+++ ata-raid.c  7 Jan 2003 10:02:50 -
@@ -374,7 +374,14 @@
 rdp->flags |= AR_F_READY;
 
 ar_table[array] = rdp;
+
+/* kick off rebuild here */
+if (setup->type == 2) {
+   rdp->disks[1].flags &= ~AR_DF_ONLINE;
+   rdp->disks[1].flags |= AR_DF_SPARE;
+}
 ar_attach_raid(rdp, 1);
+ata_raid_rebuild(array);
 setup->unit = array;
 return 0;
 }

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Added volume stepping to mixer

2003-01-07 Thread Dan Lukes
[EMAIL PROTECTED] wrote, On 01/06/03 18:53:

Last week I modified the mixer to support volume stepping. Having a



Sample usage:

Increasing:
[daren@wee mixer]$mixer -i 5:5
Increasing the mixer vol from 40:40 to 45:45.
[daren@wee mixer]$

Decreasing:
[daren@wee mixer]$mixer -d vol 10
Decreasing the mixer vol from 45:45 to 35:35.
[daren@wee mixer]$


	Mixer can change volume for more than one device within one invocation.
So, what about more generic way to implement stepping ?

You may want to increase volume on one input simultaneously decreasing
the volume on another input. Your can't do it in one step.

Let's implement stepping according to followint example:
[dan@~]$mixer vol 40:40 line1 +15:+15 line2 -10

Set volume for 'vol' to absolute value 40:40, increase line1's volume by
15 and decreasing line2's volume by 10 (both channel).

	It seems to be more generic way to me ...

	The change is backward compatible with current command line format.

	The patch for manual page should be reviewed by someone with better
knowledge of english.


	The patch can be applied to stable also.


	Dan


--
Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206
root of  FIONet, KolejNET,  webmaster  of www.freebsd.cz
AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED]


*** mixer.c.ORIGTue Aug  7 20:15:10 2001
--- mixer.c Tue Jan  7 10:48:06 2003
***
*** 23,41 
  #include 
  #include 
  #include 
  
  const char *names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES;
  
  void usage(int devmask, int recmask);
  int res_name(const char *name, int mask);
  void print_recsrc(int recsrc);
  
  void
  usage(int devmask, int recmask)
  {
int i, n;
  
!   printf("usage: mixer [-f device] [-s] [[dev [voll[:volr]] | recsrc | 
{^|+|-|=}rec recdev] ... ]\n");
printf(" devices: ");
for (i = 0, n = 0; i < SOUND_MIXER_NRDEVICES; i++)
if ((1 << i) & devmask)  {
--- 23,43 
  #include 
  #include 
  #include 
+ #include 
  
  const char *names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES;
  
  void usage(int devmask, int recmask);
  int res_name(const char *name, int mask);
  void print_recsrc(int recsrc);
+ int get_vol(char *string, int *l, int *r, int *dl, int *dr);
  
  void
  usage(int devmask, int recmask)
  {
int i, n;
  
!   printf("usage: mixer [-f device] [-s] [[dev [[+|-]voll[:[+|-]volr]] | recsrc | 
{^|+|-|=}rec recdev] ... ]\n");
printf(" devices: ");
for (i = 0, n = 0; i < SOUND_MIXER_NRDEVICES; i++)
if ((1 << i) & devmask)  {
***
*** 84,96 
fprintf(stderr, "\n");
  }
  
  int
  main(int argc, char *argv[])
  {
int foo, bar, baz, dev;
int devmask = 0, recmask = 0, recsrc = 0, orecsrc;
int dusage = 0, drecsrc = 0, shortflag = 0;
!   int l = 0, r = 0, t = 0;
char ch;
  
char *name;
--- 86,158 
fprintf(stderr, "\n");
  }
  
+ #define PLUSSIGN  '+'
+ #define MINUSSIGN '-'
+ #define DELIMITER ':'
+ int
+ get_vol(char *string, int *l, int *r, int *dl, int *dr)
+ {
+   char *sptr = string;
+   char *endptr;
+   long int value;
+   
+   while(isspace(*sptr))
+   sptr++;
+ 
+   /* if dl==NULL revert to old (non [+|-]) syntax */
+   if (dl != NULL) {
+   if (*sptr == PLUSSIGN) {
+   *dl = 1;
+   sptr++;
+   } else if  (*sptr == MINUSSIGN) {
+   *dl = -1;
+   sptr++;
+   } else
+   *dl = 0;
+   }
+   /* catch strings like '+-10' '++3' or '+ 2'*/
+   if (!isdigit(*sptr))
+   return(0);
+   value=strtol(sptr, &endptr, 10);
+   if (*endptr != '\0' && *endptr != DELIMITER && !isspace(*endptr))
+   return(0);
+ 
+   *l=(int)value;
+   sptr=endptr;
+ 
+   if (*sptr!=DELIMITER)
+   return(1);
+ 
+   sptr++;
+   if (dr != NULL) {
+   if (*sptr == PLUSSIGN) {
+   *dr = 1;
+   sptr++;
+   } else if  (*sptr == MINUSSIGN) {
+   *dr = -1;
+   sptr++;
+   } else
+   *dr = 0;
+   }
+   /* catch strings like '+-10' '++3' or '+ 2'*/
+   if (!isdigit(*sptr))
+   return(1);
+   value=strtol(sptr, &endptr, 10);
+   if (*endptr != '\0' && !isspace(*endptr))
+   return(1);
+ 
+   *r=(int)value;
+ 
+   return(2);
+ }
+ 
  int
  main(int argc, char *argv[])
  {
int foo, bar, baz, dev;
int devmask = 0, recmask = 0, recsrc = 0, orecsrc;
int dusage = 0, drecsrc = 0, shortflag = 0;
!   int l = 0, r = 0, t = 0, dl = 0, dr = 0;
char ch;
  
char *name;
***
*** 181,187 
continue;
}
  

Re: Proper -current if_attach locking?

2003-01-07 Thread M. Warner Losh
I was right (and I think you are too).  We do have lock issues.

dc_attach does approximately:

DC_LOCK
ether_attach()  (which does a IFNET_WLOCK/UNLOCK pair)
DC_UNLOCK

(this sets the lock order to be DC_LOCK, IFNET_WLOCK).

However in if_slowtimo we have:

if_slowtimo(arg)
{
... IFNET_RLOCK();
... if (ifp->if_watchdog)
(*ifp->if_watchdog)(ifp);
... IFNET_RUNLOCK();
}

and dc_watchdog does a DC_LOCK/UNLOCK pair).  This is a Lock Order
Reversal, and not a LotR :-)

What's worse is that dc_intr does:

DC_LOCK
...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing)
DC_UNLOCK

So even if we remove the one from attach, it looks like we have others
lurking in the code.

Either that, or it is too late for me to be looking at code like this
:-(

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Proper -current if_attach locking?

2003-01-07 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > In message: <[EMAIL PROTECTED]>
: > Nate Lawson <[EMAIL PROTECTED]> writes:
: > : I was looking into some "could sleep messages" and found some bogus
: > : locking in the attach routine of many drivers.  Several init a mtx in
: > : their softc and then lock/unlock it in their attach routine.  This, of
: > : course, does nothing to provide exclusive access to a device.  I assume
: > : there is going to be a global IF_LOCK or something to be used in attach
: > : routines.  Can someone fill me in on the intended design?
: > 
: > The locking in the attach routines is generally bogus.  Locking is
: > only needed when you have more than one thread of execution.  You
: > don't have more than one thread of execution until after you establish
: > the ISR and turn on interrupts.  We should likely not be enabling
: > interrupts until very late in the attach routine so that we don't need
: > any locking in them.
: 
: I looked at this.  It seems to me that it's not quite that
: simple (sorry).  I think that there are issues with locking
: because you don't know if this is a driver that's getting
: loaded well after the system has booted, or if this is a
: PCCARD or other "hot plug" device that has just arrived in
: the system.

That doesn't mattar at all.  If it is a new device that's just
arrived, the attach still won't be interrupted *by other code in the
driver* until after it has setup its ISR and told the hardware to
start generating interrupts.  No device locking is needed in the
attach routine until after interrupts are enabled in the hardware.

: It also seems to me that the "reversal" problems that would
: result by simply inserting locking have to do with the fact
: that the code is relatively schitzophrenic on deciding whether
: it's locking data, or it's locking a critical path.

The reversal is because of the bogus locking.  The first time through
it locks the device then the interface.  However, after that it locks
the interface and then the device, which can be bad.  It does point to
a problem, however, in that sometimes we'll take out the locks in one
order and other times other orders depending on the code path if we
aren't careful.  I should go look at the new code more closely.

I worry that in the non interrupt case we get things in the IF, DEV
order (because the IF locks, then calls the callback routines, which
then call the DEV lock).  But in the interrupt case we get the DEV
lock first, then try to queue data and that somehow causes the IF
locks to be grabbed.

But you are right, I do need to go look at the code to see what,
exactly, is happening and how the new interface locking code is
interacting with the semi-bogus locking than many of the wpaul drivers
have in them now.

: I can't be the only one who finds FreeBSD 5.x to be in such a state
: of flux that it's almost impossible to know what a correct
: implementation is supposed to look like, for a given subsystem
: and/or device driver, list, etc..

There we agree.  It takes a lot to keep up, and even then I fall
behind when something new happens behind my back.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-07 Thread phk
In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes:
>I was able to copy the full 100+Gb.
>Next I'm going to try and fill the disk to the max as user, but i guess it'll not 
>trigger this bug.
>
>And to that fact I have a question:
>At the moment 8% of the disk is reserved. 
>It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
>tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
>But is for this size of spare space such a large threshold really required??
>And IF i would like to experiment, where do I look for the knop to turn??

Basically you don't need to reserve anything, but as you get closer to
filling the disk the time to find a free space increases rapidly and
your files get very fragmented.  Trouble is: they never get defragmented
unless you copy them (or do a full dump/restore).

I'm not sure how to nail the "right" number of % down, and I'm sure
that both Kirk and I would like to hear your numbers :-)

-- 
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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-07 Thread Willem Jan Withagen
I was able to copy the full 100+Gb.
Next I'm going to try and fill the disk to the max as user, but i guess it'll not 
trigger this bug.

And to that fact I have a question:
At the moment 8% of the disk is reserved. 
It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
But is for this size of spare space such a large threshold really required??
And IF i would like to experiment, where do I look for the knop to turn??

Thanx for the support,
--WjW

> In message <03a701c2b38c$8e3ad990$471b3dd4@dual>, "Willem Jan Withagen" writes:
> >Which seems a problem sticking up it's head once so often.
> >I had it happen to me now 3 times over the last day. It just drops into the 
>debugger.
> >And I've foun little extra info in the archive.
> >
> >What dows this actually mean? Is something leaking in the kernel.
> >IF so how do I help it go away.
> >
> >I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
> >Current is as of 28 dec...
> 
> Please try to move up to current as of today.  On Dec 29th I commited
> code to make the desiredvnodes a limit rather than a vague suggestion
> and that should solve your problem I hope.
> 
> -- 
> 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.
> 
> ¡Iì¹»®&Þ±éݙ¨¥¶‰šŽŠÝ¢j­çH:+ƒ­†éì¹»®&Þ~·žnÇ\ººÞžØ§¶›¡Ü¨~Ø^™ë,j


i386 tinderbox failure

2003-01-07 Thread Dag-Erling Smorgrav
--
>>> Rebuilding the temporary build tree
--
>>> 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/i386/obj/local0/scratch/des/src/i386/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Mon Jan  6 22:52:32 PST 2003
--
>>> Kernel build for GENERIC completed on Tue Jan  7 00:07:38 PST 2003
--
>>> Kernel build for LINT started on Tue Jan  7 00:07:39 PST 2003
--
===> vesa
"Makefile", line 5396: warning: duplicate script for target "geom_bsd.o"  [...]
"Makefile", line 5399: warning: duplicate script for target "geom_mbr.o"  [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_TH [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `Acp [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cas [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: ` [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_T [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_ [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: c [...]
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: c [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MO [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_M [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acp [...]
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acp [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment disca [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1254: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1266: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ie_readframe':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1312: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `iestart':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1412: warning: passing arg 2 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1425: warning: cast discards q [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `check_ie_present':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1479: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1488: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1491: warning: passing arg 1 o [...]
/local0/scratch/des/src/sys/dev/ie/if_ie

Re: Proper -current if_attach locking?

2003-01-07 Thread Terry Lambert
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : I was looking into some "could sleep messages" and found some bogus
> : locking in the attach routine of many drivers.  Several init a mtx in
> : their softc and then lock/unlock it in their attach routine.  This, of
> : course, does nothing to provide exclusive access to a device.  I assume
> : there is going to be a global IF_LOCK or something to be used in attach
> : routines.  Can someone fill me in on the intended design?
> 
> The locking in the attach routines is generally bogus.  Locking is
> only needed when you have more than one thread of execution.  You
> don't have more than one thread of execution until after you establish
> the ISR and turn on interrupts.  We should likely not be enabling
> interrupts until very late in the attach routine so that we don't need
> any locking in them.

I looked at this.  It seems to me that it's not quite that
simple (sorry).  I think that there are issues with locking
because you don't know if this is a driver that's getting
loaded well after the system has booted, or if this is a
PCCARD or other "hot plug" device that has just arrived in
the system.

It also seems to me that the "reversal" problems that would
result by simply inserting locking have to do with the fact
that the code is relatively schitzophrenic on deciding whether
it's locking data, or it's locking a critical path.

The entire idea of lock order reversals (please, don't use the
abbreviation "LOR": my mind keeps telling me that Legolas just
got his commit bit) is predicated, I think, on the idea that
there is an order of operation that has to be adhered to because
we are talking not about data object locking, we are in fact
talking about (theoretically independent) code path locking, and
what happens on a reentry during a sleep.  Basically, this means
that for code that can't result in a sleep, there's no such thing
as a lock order reversal -- there's only locking at the wrong
functional layer.

In this particular case, we're talking about a interface list,
and we're talking about a device instance, and the events that
get a device on or off the list are *not* independent and they
*are* mutually exclusive, based on state.

Given all that, it seems to me that this would be an ideal
place for a "critical section" lock -- or, at least, a lock
that's asserted on the list of interfaces, and which doesn't
have any witness registration (per Bruce's earlier suggestion).
My preference (if it's not obvious) would be a critical section
lock, but a data lock on a list held over the same operations is
functionally the same thing, anyway.

Perhaps it's time to step back, and look over the overall locking
philosophy that everyone is supposed to be implementing to, and
the implementation assumptions that that philosophy makes necessary
for things to work?  I think that some of the assumptions are
themselves mutually exclusive with current implementation, and it
would be nice to know, up front, what needs to be rewritten, and
what *should* be rewritten, to conform to the new philosophy.

I can't be the only one who finds FreeBSD 5.x to be in such a state
of flux that it's almost impossible to know what a correct
implementation is supposed to look like, for a given subsystem
and/or device driver, list, etc..

If someone were to "lay down the law", we could at least discuss it,
and come to some conclusions that would let people know what to do --
even if there's no change in "the law" as a result, it's a useful
exercise, since people can then just "code to the spec.", and not
have to have in depth knowledge of the overall design (if there is
one) to deal with all the related issues... they can just copy the
changes into every other driver/whatever that's in the same niche,
ecologically.  Parallel progress is a Good Thing(tm).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message