RE: mutexes and modules
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
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
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...
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
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
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
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
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
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?
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
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
-- >>> 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
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?
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?
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 (?)
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
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?
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?
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
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?
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?
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?
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?
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?
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
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...
> 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£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: font failure in X
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...
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?
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
[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?
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?
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...
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...
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
-- >>> 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?
"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
