Re: UDMA interfering with install
> > > > That's good enough. :) Thanks > > > > Maybe _that_ will keep that ata code from over-riding > > the bios to disable dma (or maybe the bios just wasn't > > doing it's job right ;) > > > This won't work. What do you mean with this? The procedure that I described (barring typos) do work here and was used here to install and run FreeBSD on a silly A+ motherboard. Without disabling the DMA the install would fail and even if I installed with DMA disabled, but rebooted afterwards with DMA enabled, it would corrupt the filesystem to an almost unusable state. > > Someone was having the same problem the other day, and > I suggested the same soloution, but after probe, the > damn driver enabled UDMA at attach time anyway. > > So we removed it from the kernel config... and the damn > thing enabled it again. > > I don't know if the #ifdef was intended to only guard > in the boot case, but it doesn't help, because there > are several missign guards around the code, if that's > the case, and at least four places in the code ignore > the tuning variable, as well, if it isn't commented > out of the kernel at build time (thus disabling one of > the places). > > Look for the #ifdef, and then look for the function > call to do the enable, and the problem will be obvious. I'm not sure where the #ifdef comes into play. I didn't even recompile anything, so whatever #ifdef can be whatever it likes to be. Jun 5 18:42:51 d-5-71 /boot/kernel/kernel: ad0: 4104MB [8896/15/63] at ata0-master PIO4 John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: > Jonathan Smith wrote: > > > > That's good enough. :) Thanks > > > > Maybe _that_ will keep that ata code from over-riding > > the bios to disable dma (or maybe the bios just wasn't > > doing it's job right ;) > > This won't work. > > Someone was having the same problem the other day, and > I suggested the same soloution, but after probe, the > damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma="0" in /boot/loader.conf and it will not enabled DMA.. > So we removed it from the kernel config... and the damn > thing enabled it again. There is nothing in the config file that affects DMA... > I don't know if the #ifdef was intended to only guard > in the boot case, but it doesn't help, because there > are several missign guards around the code, if that's > the case, and at least four places in the code ignore > the tuning variable, as well, if it isn't commented > out of the kernel at build time (thus disabling one of > the places). > > Look for the #ifdef, and then look for the function > call to do the enable, and the problem will be obvious. You lost me here, what version of FreeBSD are we talking about ? I thought it was 4.3 but that doesn't contain any ifdef's about DMA at all -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UDMA interfering with install
Jonathan Smith wrote: > > That's good enough. :) Thanks > > Maybe _that_ will keep that ata code from over-riding > the bios to disable dma (or maybe the bios just wasn't > doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. So we removed it from the kernel config... and the damn thing enabled it again. I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
In message <[EMAIL PROTECTED]> Bruce Evans writes: : The first "ls" should create about 8000 new tun devices by first accessing : them via stat(2), but there is some garbage collection, so the second "ls" : may show that some of the devices have magically unappeared. I just want to see the disk slices that are availabe. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD and -current
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : I make a short patch to sharing IRQ between a PCIC and a PC Card when using : PCI IRQ routing. : #Does this patch help you? Yes. It does. Thank you! Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD and -current
I make a short patch to sharing IRQ between a PCIC and a PC Card when using
PCI IRQ routing.
#Does this patch help you?
---
YAMAMOTO ShigeruInternet Initiative Japan Inc.
<[EMAIL PROTECTED]> Network Engineering Div.
Index: pcic.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/pccard/pcic.c,v
retrieving revision 1.141
diff -u -r1.141 pcic.c
--- pcic.c 2001/06/04 03:29:06 1.141
+++ pcic.c 2001/06/13 04:18:17
@@ -805,8 +805,13 @@
/*
* If we're routing via pci, we can share.
*/
- if (sc->func_route == pci_parallel && type == SYS_RES_IRQ)
+ if (sc->func_route == pci_parallel && type == SYS_RES_IRQ) {
flags |= RF_SHAREABLE;
+ if (sc->irqres) {
+ start = rman_get_start(sc->irqres);
+ end = rman_get_start(sc->irqres);
+ }
+ }
return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
count, flags));
Index: pcic_pci.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/pccard/pcic_pci.c,v
retrieving revision 1.48
diff -u -r1.48 pcic_pci.c
--- pcic_pci.c 2001/06/09 07:34:17 1.48
+++ pcic_pci.c 2001/06/13 04:26:52
@@ -446,9 +446,10 @@
sc->flags = PCIC_PD_POWER;
num6729++;
} else {
+ device_printf(dev, "MEMORY mapped device!\n");
sc->memrid = CB_PCI_SOCKET_BASE;
sc->memres = bus_alloc_resource(dev, SYS_RES_MEMORY,
- &sc->memrid, 0, ~0, 1, RF_ACTIVE);
+ &sc->memrid, 0, ~0, 0x1000, RF_ACTIVE);
if (sc->memres == NULL && pcic_pci_get_memory(dev) != 0)
return (ENOMEM);
sp->getb = pcic_pci_getb2;
NFS v4
Do somebody works on it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe freebsd-current = My homepage: http://mojo.myftp.org __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
unsubscribe
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
Folks, I have a new version of the patch for you to test. It's up: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff (same place as before). The difference is that I have removed the HUGE src/sys sweep for #include's and have removed the need to include before . This had the added effect of effectively nuking the allocation/deallocation macros in sys/mbuf.h, which is good because what was previously there was a pessimization. The reason it was a pessimization was because callers that used the macros would only pay the cost of one function call but callers that used the function equivalents would pay the cost of two function calls, even in the best case scenario. With these changes, all callers do one function call per allocation. Bruce: Would you please glance over these changes (particularily the mbuf.h and the bottom of subr_mbuf.c - m_get() and downward)? I think it fixes the problem you brought up to me earlier today. :-) Matt Jacob: If you have already started testing the other diff, that's okay, nothing much has changed functionally. However, if you haven't or if you have extra time, please consider backing it out and applying this one. Sorry for the inconvenience. Cheers, Bosko. On Wed, Jun 13, 2001 at 01:07:44AM -0400, Bosko Milekic wrote: > > Hi -current && -alpha, > > If you run -CURRENT on multiprocessor alpha, please > please please read this! :-) > > The final version (or next to final, depending on how > this final testing stage goes) of the new mbuf allocator which > I have been working on for the past 1.5 months and which I've > already mentionned on -arch is now ready. > I plan to commit the new bits within the next week. > However, as is usually the case with commits of this magnitude, > I'd like a few more tests to be run by a few more people. > I've been testing the allocator myself (in several different > ways, mainly resource exhaustion simulations) for the past > couple of weeks and have been able to catch and fix a couple > of bugs. > Also, jake, jlemon, and Silby (Mike Silbersack) have > provided me with some reviews, all of which have been integrated > into the latest version of the patch (below). > > The latest version of the "mb_alloc" code, applying > to -CURRENT as of 5 minutes ago can be found here: > > http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff > > People who have the following hardware are needed to help > test the patch: > > 1- UP -CURRENT systems (Intel && Alpha) > 2- SMP -CURRENT systems (Intel) > 3- SMP -CURRENT systems (Alpha) *** Especially important *** > who are *not* using the if_vx.c driver [*] > > [*] The if_vx.c driver is broken for the Alpha, and is marked so > by this patch. Before committing this, I plan to first fix > the driver but, obviously, for now, if you are > using if_vx, you won't be able to help with testing. :-( > > To test the patch: apply, build, reboot, do network-related > things, check stats with `netstat -m', etc. > > For those looking at the code: > > Finally, a few things should be noted about the code > itself (if you're just helping test, feel free to skip this > part): > > - I disabled mbtypes[] related statistics _FOR NOW_. This is >because if I were to presently enable them, I wouldn't be >able to consistently update them (unless I do it atomic()ally, >which is not so good for overall performance). I plan to >re-enable them later on, but would prefer to wait and >go over them (perhaps clean them up - add/remove types as >needed - many are if 0'd anyway) rather than rush and waste >time doing it now. > > - The patch is big. sys/mbuf.h includes need to also #include > _BEFORE_ because sys/mbuf.h requires >MALLOC_DECLARE() to be defined. > > - counters for m_ext objects are now all malloc()ed. This will >likely eventually change for what concerns clusters (I am >looking at storing the cluster counter in the cluster 2 >region itself). For other object types, I plan to leave >malloc() as the standard allocator for the counters, seeing >as how the external objects are not allocated in a PCPU >fashion anyway. > > That's it! This patch also sets up the way to more > mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c > code with uipc_mbuf2.c code, and ridding ourselves of the latter, > etc.). It also moves a bundle of mbuf related things out of > sys/conf/param.c and into subr_mbuf.c, where they will now > belong. :-) > > Best Regards and PLEASE help test (especially if you have alpha > hardware!!!), > -- > Bosko Milekic > [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP - linker sets in -current (and gensetdefs)
Peter Wemm wrote: > Two things have turned up: > > 1: make sure you rerun config. This should go without saying, but some > people have been forgetting. You must rerun config(8) *EVERY* time that > you do a 'cvs update' or 'cvsup' in checkout mode that touches any of the > files in sys/conf/* (like this commit did). gensetdefs and gensetdefs.pl have now been removed. Your kernel builds will now fail if you neglect to rerun config, rather han just give perl warnings. > 2: I broke the pam build in userland. *blush*. Fixing now. Should be fixed. src/ is now gensetdefs-free. There are still some doc/ references though. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
On Wed, 13 Jun 2001, Garrett Wollman wrote: > < said: > > > 3. Provide an alternative to qsort() that takes an comparison function > >that takes an additional function pointer arg (use this arg to avoid > >the global in (1)). > > Actually, doing this would solve a number of similar problems, and it > doesn't look to be too difficult to do. I would make the additional > argument a `void *'; fts's comparison trampoline function could use > this as a `FTS *' to look up the comparison function. (I think this > is more general than passing any kind of function pointer.) Good idea. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP - linker sets in -current
Two things have turned up: 1: make sure you rerun config. This should go without saying, but some people have been forgetting. You must rerun config(8) *EVERY* time that you do a 'cvs update' or 'cvsup' in checkout mode that touches any of the files in sys/conf/* (like this commit did). 2: I broke the pam build in userland. *blush*. Fixing now. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: worklist_remove panic
I have checked in revision 1.99 to ffs_softdep.c which
builds on the change in revision 1.98 by [EMAIL PROTECTED]
The symptom being treated in 1.98 was to avoid freeing a
pagedep dependency if there was still a newdirblk dependency
referencing it. That change is correct and no longer prints
the warning message ``handle_written_filepage: active pagedep''
when it occurs. The other part of revision 1.98 was to panic
with ``deallocate_dependencies: active pagedep'' when a
newdirblk dependency was encountered during a file truncation.
This fix removes that panic and replaces it with code to find
and delete the newdirblk dependency so that the truncation can
succeed. This delta should clear up the recent problems that
folks have been having with soft updates.
Kirk McKusick
=-=-=-=-=
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: worklist_remove panic
From: Dag-Erling Smorgrav <[EMAIL PROTECTED]>
Date: 26 May 2001 21:25:32 +0200
No dump (dumps seem to have been broken for about a month now), but a
stacktrace from DDB:
kernel: type 12 trap, code=0
Stopped at worklist_remove+0x1c: cmpw$0,0xa(%ecx)
db> trace
worklist_remove(deadc0de) at worklist_remove+0x1c
free_diradd(deadc0de) at free_diradd+0x26
free_newdirblk(c2e45cd0) at free_newdirblk+0x32
handle_written_inodeblock(c287b200,c6323480) at handle_written_inodeblock+0x2b2
softdep_disk_write_complete(c6323480) at softdep_disk_write_complete+0x6a
bufdone(c6323480,cf2c7f54,c014de93,c6323480,c258b280) at bufdone+0x101
bufdonebio(c6323480) at bufdonebio+0xe
ad_interrupt(c2c5f940,c2564300,cf2c7f7c,c01ba6e4,c258b280) at ad_interrupt+0x3ef
ata_intr(c258b280) at ata_intr+0xae
ithread_loop(c258b200,cf2c7fa8) at ithread_loop+0x424
fork_exit(c01ba2c0,c258b200,cf2c7fa8) at fork_exit+0xf4
fork_trampoline() at fork_trampoline+0x8
db> panic
panic: from debugger
Debugger("panic")
Stopped at worklist_remove+0x1c: cmpw$0,0xa(%ecx)
db>
panic: from debugger
Uptime: 1d0h12m13s
dumping to dev ad0b, offset 131104
dump ata0: resetting devices .. panic: witness_restore: lock (sleep mutex) Giant not
locked
Uptime: 1d0h12m13s
Dump already in progress, bailing...
Automatic reboot in 15 seconds - press a key on the console to abort
des@des ~% gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) exec-file /boot/kernel/kernel
(kgdb) symbol-file /sys/compile/DES/kernel.debug
Reading symbols from /sys/compile/DES/kernel.debug...done.
(kgdb) l *(worklist_remove+0x1c)
0xc0261750 is in worklist_remove (../../ufs/ffs/ffs_softdep.c:432).
427 struct worklist *item;
428 {
429
430 if (lk.lkt_held == -1)
431 panic("worklist_remove: lock not held");
432 if ((item->wk_state & ONWORKLIST) == 0) {
433 FREE_LOCK(&lk);
434 panic("worklist_remove: not on list");
435 }
436 item->wk_state &= ~ONWORKLIST;
(kgdb) l *(free_diradd+0x26)
0xc02640fa is in free_diradd (../../ufs/ffs/ffs_softdep.c:2601).
2596#ifdef DEBUG
2597if (lk.lkt_held == -1)
2598panic("free_diradd: lock not held");
2599#endif
2600WORKLIST_REMOVE(&dap->da_list);
2601LIST_REMOVE(dap, da_pdlist);
2602if ((dap->da_state & DIRCHG) == 0) {
2603pagedep = dap->da_pagedep;
2604} else {
2605dirrem = dap->da_previous;
(kgdb) l *(free_newdirblk+0x32)
0xc026345e is in free_newdirblk (../../ufs/ffs/ffs_softdep.c:2033).
2028 */
2029pagedep = newdirblk->db_pagedep;
2030pagedep->pd_state &= ~NEWBLOCK;
2031if ((pagedep->pd_state & ONWORKLIST) == 0)
2032while ((dap = LIST_FIRST(&pagedep->pd_pendinghd)) != NULL)
2033free_diradd(dap);
2034/*
2035 * If no dependencies remain, the pagedep will be freed.
2036 */
2037for (i = 0; i < DAHASHSZ; i++)
After this panic, fsck complained of bad superblocks on all file
systems.
By the way, fsck is intolerably slow these days: more than twenty
minutes for 'fsck -y' of a 5.5 GB filesystem (roughly 380,000 files)
on a recent and far from sluggish IBM IDE drive. Most (nearly all) of
that time is spent in phase 2.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new ipv6 causes panic
At Wed, 13 Jun 2001 15:45:03 + (UTC), Michael Harnois wrote: > Building the kernel without INET6 makes this error go away. cvsup as > of about two hours ago. Do you define WITNESS or not? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pthread programing
I was looking for thread-safe version of gethostbyname (), but I didn't find it. Can someone tell me, does such a function exsist ? Tomasz Paszkowski -- "Existen dos productos importantes que salieron de Berkeley: LSD y UNIX. No creemos que esto sea una coincidencia." -- Jeremy Anderson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
Salve, Con DirectLine potrai riferirti ad un unico operatore per tutte le tue chiamate urbane, interurbane, internazionali e verso cellulari a tariffe MAI VISTE... Segnalando il servizio ai tuoi amici, arriverai ad eliminare del tutto la bolletta telefonica, e se gli amici sono tanti... potrai addirittura guadagnare denaro! la DirectLine è lieto di annunciarLe nuovi ribassi di tariffe in vigore dal 1 Maggio 2001 NUOVE TARIFFE IN VIGORE DAL 1 Maggio 2001 +--+---+-+ | Destinazione| Fascia | Fascia | | |Ord. | Rid.| +--+---+-+ |Italia " Urbano " | 50 | 40 | |Italia " Inter. " | 85 | 70 | |Italia Cell. | 450 | 450| +--+---+-+ TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! IL GIRO DEL MONDO CON POCHE LIRE +--+---+ | Destinazione| Tariffa | | | al min/Lre| +--+---+ |Francia | 170 | |Germania | 170 | |Grecia| 399 | |Hong Kong | 349 | |Ungheria | 349 | |Irelanda | 170 | |Israele | 539 | |Giappone | 349 | |Korea del Sud | 399 | |Olanda| 259 | |Filippine | 1049| |Polonia | 500 | |Portogallo| 419 | |Spain | 170 | |Svizzera | 170 | |U.S.A | 170 | |UK| 170 | |Venezula | 699 | |Canada| 170 | |Brazil| 699 | |Argentina | 699 | +--+---+ per visualizzare la tabella, impostare il carattere Courier INOLTRE SONO PREVISTE SCONTI APPLICABILI SULLE DESTINAZIONI PIU' CHIAMATE TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! Cordiali saluti ISCRIZIONE - Per iscrizione al servzio invia un messaggio a : mailto:[EMAIL PROTECTED]?Subject=SIGN-UP ed indicato il suo recapito telefonico ed sarete contattati °° ° DirectLine° ° NUMERO VERDE 800 787085 ° ° NUMERO VERDE 800 787086 ° ° mailto:[EMAIL PROTECTED]° °° +-+ |Questo messaggio e' stato inviato in seguito alla vostra | |iscrizione alla newsletter e se pertanto | |non avete richiesto informazioni al rigurado c'e' la possibilita'| |che qualcuno abbia inserito in errore il suo indirizzo email | | | +-+ Per cancellarVi dalla lista mandateci un e-mail all`indirizzo: mailto:[EMAIL PROTECTED]?Subject=cancel ed invia l'email Volete ricevere in futuro maggiori informazioni via email ? mailto:[EMAIL PROTECTED]?Subject=informazioni directline ed sarete contattati FINE NEWSLETTER dULTRA_v01.1_0613 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
Salve, Con DirectLine potrai riferirti ad un unico operatore per tutte le tue chiamate urbane, interurbane, internazionali e verso cellulari a tariffe MAI VISTE... Segnalando il servizio ai tuoi amici, arriverai ad eliminare del tutto la bolletta telefonica, e se gli amici sono tanti... potrai addirittura guadagnare denaro! la DirectLine è lieto di annunciarLe nuovi ribassi di tariffe in vigore dal 1 Maggio 2001 NUOVE TARIFFE IN VIGORE DAL 1 Maggio 2001 +--+---+-+ | Destinazione| Fascia | Fascia | | |Ord. | Rid.| +--+---+-+ |Italia " Urbano " | 50 | 40 | |Italia " Inter. " | 85 | 70 | |Italia Cell. | 450 | 450| +--+---+-+ TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! IL GIRO DEL MONDO CON POCHE LIRE +--+---+ | Destinazione| Tariffa | | | al min/Lre| +--+---+ |Francia | 170 | |Germania | 170 | |Grecia| 399 | |Hong Kong | 349 | |Ungheria | 349 | |Irelanda | 170 | |Israele | 539 | |Giappone | 349 | |Korea del Sud | 399 | |Olanda| 259 | |Filippine | 1049| |Polonia | 500 | |Portogallo| 419 | |Spain | 170 | |Svizzera | 170 | |U.S.A | 170 | |UK| 170 | |Venezula | 699 | |Canada| 170 | |Brazil| 699 | |Argentina | 699 | +--+---+ per visualizzare la tabella, impostare il carattere Courier INOLTRE SONO PREVISTE SCONTI APPLICABILI SULLE DESTINAZIONI PIU' CHIAMATE TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! Cordiali saluti ISCRIZIONE - Per iscrizione al servzio invia un messaggio a : mailto:[EMAIL PROTECTED]?Subject=SIGN-UP ed indicato il suo recapito telefonico ed sarete contattati °° ° DirectLine° ° NUMERO VERDE 800 787085 ° ° NUMERO VERDE 800 787086 ° ° mailto:[EMAIL PROTECTED]° °° +-+ |Questo messaggio e' stato inviato in seguito alla vostra | |iscrizione alla newsletter e se pertanto | |non avete richiesto informazioni al rigurado c'e' la possibilita'| |che qualcuno abbia inserito in errore il suo indirizzo email | | | +-+ Per cancellarVi dalla lista mandateci un e-mail all`indirizzo: mailto:[EMAIL PROTECTED]?Subject=cancel ed invia l'email Volete ricevere in futuro maggiori informazioni via email ? mailto:[EMAIL PROTECTED]?Subject=informazioni directline ed sarete contattati FINE NEWSLETTER dULTRA_v01.1_0613 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
> On Wed, 13 Jun 2001 14:15:53 -0400
> Bosko Milekic <[EMAIL PROTECTED]> said:
> Yup, current KAME is based on 4.3-RELEASE which doesn't have
> mtx_lock() issue. It is my mistake during merging it into 5-CURRENT.
> The fix looks good to me. If there is no objection, I'll commit it.
bmilekic> Nope, no objection here. :-)
I just committed. Thanks!!
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
On Thu, Jun 14, 2001 at 03:12:06AM +0900, Hajimu UMEMOTO wrote: > > On Wed, 13 Jun 2001 13:42:51 -0400 > > Bosko Milekic <[EMAIL PROTECTED]> said: > > bmilekic> Yes, I certainly didn't write that. I think it was KAME. > > Yup, current KAME is based on 4.3-RELEASE which doesn't have > mtx_lock() issue. It is my mistake during merging it into 5-CURRENT. > The fix looks good to me. If there is no objection, I'll commit it. Nope, no objection here. :-) Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
On Thu, 14 Jun 2001, Hajimu UMEMOTO wrote: > > On Wed, 13 Jun 2001 13:42:51 -0400 > > Bosko Milekic <[EMAIL PROTECTED]> said: > > bmilekic> Yes, I certainly didn't write that. I think it was KAME. > > Yup, current KAME is based on 4.3-RELEASE which doesn't have > mtx_lock() issue. It is my mistake during merging it into 5-CURRENT. > The fix looks good to me. If there is no objection, I'll commit it. > Works for me. I haven't completed building a new kernel and testing though. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
> On Wed, 13 Jun 2001 13:42:51 -0400
> Bosko Milekic <[EMAIL PROTECTED]> said:
bmilekic> Yes, I certainly didn't write that. I think it was KAME.
Yup, current KAME is based on 4.3-RELEASE which doesn't have
mtx_lock() issue. It is my mistake during merging it into 5-CURRENT.
The fix looks good to me. If there is no objection, I'll commit it.
bmilekic> On Wed, Jun 13, 2001 at 10:37:22AM -0700, Matthew Jacob wrote:
>
> A recent change to the MFREE macro was made as noted below:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> ++if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> ++m_freem(_mm->m_pkthdr.aux); \
> ++_mm->m_pkthdr.aux = NULL; \
> ++} \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> } while (0)
>
>
> Unfortunately, m_freem also calls MFREE. Tsk. Now, it seems to me that even in
> cases where you *could* allow recursive locks, the right idea here would be to
> change it to:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> struct mbuf *_aux; \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> _aux = _mm->m_pkthdr.aux; \
> _mm->m_pkthdr.aux = NULL; \
> } else {\
> _aux = NULL;\
> } \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> if (_aux) \
> m_freem(_aux); \
> } while (0)
>
>
> Comments?
>
> -matt
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
bmilekic> --
bmilekic> Bosko Milekic
bmilekic> [EMAIL PROTECTED]
bmilekic> To Unsubscribe: send mail to [EMAIL PROTECTED]
bmilekic> with "unsubscribe freebsd-current" in the body of the message
To Unsubsc
Re: MBUF locking- this can't be right, can it?
Yes, I certainly didn't write that. I think it was KAME.
On Wed, Jun 13, 2001 at 10:37:22AM -0700, Matthew Jacob wrote:
>
> A recent change to the MFREE macro was made as noted below:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> ++if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> ++m_freem(_mm->m_pkthdr.aux); \
> ++_mm->m_pkthdr.aux = NULL; \
> ++} \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> } while (0)
>
>
> Unfortunately, m_freem also calls MFREE. Tsk. Now, it seems to me that even in
> cases where you *could* allow recursive locks, the right idea here would be to
> change it to:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> struct mbuf *_aux; \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> _aux = _mm->m_pkthdr.aux; \
> _mm->m_pkthdr.aux = NULL; \
> } else {\
> _aux = NULL;\
> } \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> if (_aux) \
> m_freem(_aux); \
> } while (0)
>
>
> Comments?
>
> -matt
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
MBUF locking- this can't be right, can it?
A recent change to the MFREE macro was made as noted below:
/*
* MFREE(struct mbuf *m, struct mbuf *n)
* Free a single mbuf and associated external storage.
* Place the successor, if any, in n.
*
* we do need to check non-first mbuf for m_aux, since some of existing
* code does not call M_PREPEND properly.
* (example: call to bpf_mtap from drivers)
*/
#define MFREE(m, n) do {\
struct mbuf *_mm = (m); \
\
KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
if (_mm->m_flags & M_EXT) \
MEXTFREE(_mm); \
mtx_lock(&mbuf_mtx);\
mbtypes[_mm->m_type]--; \
++if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
++m_freem(_mm->m_pkthdr.aux); \
++_mm->m_pkthdr.aux = NULL; \
++} \
_mm->m_type = MT_FREE; \
mbtypes[MT_FREE]++; \
(n) = _mm->m_next; \
_mm->m_next = mmbfree.m_head; \
mmbfree.m_head = _mm; \
MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
mtx_unlock(&mbuf_mtx); \
} while (0)
Unfortunately, m_freem also calls MFREE. Tsk. Now, it seems to me that even in
cases where you *could* allow recursive locks, the right idea here would be to
change it to:
/*
* MFREE(struct mbuf *m, struct mbuf *n)
* Free a single mbuf and associated external storage.
* Place the successor, if any, in n.
*
* we do need to check non-first mbuf for m_aux, since some of existing
* code does not call M_PREPEND properly.
* (example: call to bpf_mtap from drivers)
*/
#define MFREE(m, n) do {\
struct mbuf *_mm = (m); \
struct mbuf *_aux; \
\
KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
if (_mm->m_flags & M_EXT) \
MEXTFREE(_mm); \
mtx_lock(&mbuf_mtx);\
mbtypes[_mm->m_type]--; \
if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
_aux = _mm->m_pkthdr.aux; \
_mm->m_pkthdr.aux = NULL; \
} else {\
_aux = NULL;\
} \
_mm->m_type = MT_FREE; \
mbtypes[MT_FREE]++; \
(n) = _mm->m_next; \
_mm->m_next = mmbfree.m_head; \
mmbfree.m_head = _mm; \
MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
mtx_unlock(&mbuf_mtx); \
if (_aux) \
m_freem(_aux); \
} while (0)
Comments?
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
On Wed, Jun 13, 2001 at 12:48:14AM -0700, Mike Smith wrote: > > The reason I said "in the next week" is actually because on Sat. June 23rd > > (not this upcoming one, but the one after), I should be flying off to > > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > > gone for 3 weeks and seeing as how maintaining this huge diff is a real > > (especially given the state of -CURRENT, as I'm sure you know :-)), > > I realise that maintaining the diff is a major pain, but this is *not* a > good reason to be rushing it now, *especially* when you're going to be > gone for three weeks. I'm not rushing it. > I appreciate the extra work involved, but please take this as an > extremely serious request to defer your commit until it's had some more > testing, and until you're in a position to support it for more than 36 > hours after you commit. This is likely going to happen anyway, following some discussions with Bruce, in order to improve the situation of sys/mbuf.h :-) However, testing should still continue as none of the planned changes affect any of the conceptual/functional bits. > Thanks. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] >V I C T O R Y N O T V E N G E A N C E Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FW: Snapshot Log
World broke? -FW: <[EMAIL PROTECTED]>- Date: Wed, 13 Jun 2001 08:37:39 -0700 (PDT) From: Deimos Root <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Snapshot Log cc -nostdinc -O -pipe -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/include -I/usr/src/lib/libpam/libpam/../../ ../contrib/libpam/libpam_misc/include -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpamc/include -I. -I/usr/src/lib/ libpam/libpam -DDEFAULT_MODULE_PATH=\"/usr/lib/\" -DLIBPAM_VERSION_MAJOR=0 -DLIBPAM_VERSION_MINOR=75 -I/usr/obj/usr/src/i386/ usr/include -c /usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/pam_static.c -o pam_static.o ld -o _pam_static_modules.o -r --whole-archive ../modules/pam_deny/libpam_deny.a ../modules/pam_ftp/libpam_ftp.a ../modules/pam _nologin/libpam_nologin.a ../modules/pam_opie/libpam_opie.a ../modules/pam_permit/libpam_permit.a ../modules/pam_radius/libpam_ radius.a ../modules/pam_rootok/libpam_rootok.a ../modules/pam_securetty/libpam_securetty.a ../modules/pam_tacplus/libpam_tacplu s.a ../modules/pam_unix/libpam_unix.a ../modules/pam_wheel/libpam_wheel.a /usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/pam_handlers.c: In function `_pam_add_handler': /usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/pam_handlers.c:557: warning: assignment makes pointer from integer wi thout a cast gensetdefs _pam_static_modules.o gensetdefs _pam_static_modules.o gensetdefs _pam_static_modules.o cc -nostdinc -O -pipe -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/include -I/usr/src/lib/libpam/libpam/../../ ../contrib/libpam/libpam_misc/include -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpamc/include -I. -I/usr/src/lib/ libpam/libpam -DDEFAULT_MODULE_PATH=\"/usr/lib/\" -DLIBPAM_VERSION_MAJOR=0 -DLIBPAM_VERSION_MINOR=75 -I/usr/obj/usr/src/i386/ usr/include -c setdef0.c -o setdef0.o cc -nostdinc -O -pipe -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/include -I/usr/src/lib/libpam/libpam/../../ ../contrib/libpam/libpam_misc/include -I/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpamc/include -I. -I/usr/src/lib/ libpam/libpam -DDEFAULT_MODULE_PATH=\"/usr/lib/\" -DLIBPAM_VERSION_MAJOR=0 -DLIBPAM_VERSION_MINOR=75 -I/usr/obj/usr/src/i386/ usr/include -c setdef1.c -o setdef1.o /usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/pam_static.c: In function `_pam_open_static_handler': /usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/pam_static.c:28: invalid use of undefined type `struct linker_set' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Stop in /usr/src/release. release started at 06:00:00 on 06/13/01 release died at 08:36:38 on 06/13/01 --End of forwarded message- -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: diskcheckd.conf
In message <[EMAIL PROTECTED]>, Andrew Bliz nak writes: > >After CURRENT update I see this in /var/log/messages: > >>Jun 12 18:50:48 pyvo diskcheckd[204]: open /etc/diskcheckd.conf failure: >>No such file or directory > >I saw this commit message: > >> revision 1.267 >> date: 2001/06/03 20:15:10; author: phk; state: Exp; lines: +9 -1 >> Add diskcheckd to /etc/rc with a knob in rc.conf. >> >> Make the default setting YES for now to get some experience with it. >> >> Note: If people starts seeing disk errors because of this then it >> should not be backed. >> > >But where diskcheckd.conf ? My bad, forgot to add diskcheckd.conf to src/etc/Makefile. Done now. -- 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
diskcheckd.conf
After CURRENT update I see this in /var/log/messages: >Jun 12 18:50:48 pyvo diskcheckd[204]: open /etc/diskcheckd.conf failure: >No such file or directory I saw this commit message: > revision 1.267 > date: 2001/06/03 20:15:10; author: phk; state: Exp; lines: +9 -1 > Add diskcheckd to /etc/rc with a knob in rc.conf. > > Make the default setting YES for now to get some experience with it. > > Note: If people starts seeing disk errors because of this then it > should not be backed. > But where diskcheckd.conf ? * * 1 * -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
< said: > Why not do something like the rpc code does? Check if threaded, if > so cons up a thread specific key otherwise use a global. The Standard does not appear to say whether qsort() is reentrant, but I believe that it ought to be. fts() was clearly intended to be reentrant. (I don't know what good it would do, but let's not make things worse than they already are, hey?) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
* Garrett Wollman <[EMAIL PROTECTED]> [010613 11:51] wrote: > < said: > > > How should we call this function? > > (I'll implement this tomorrow.) > > I was would call it `qsort_with_arg' or something similar. There is a > namespace issue here; reserves very little namespace for > the implementation, so anything we add will have to be hidden from > strictly-compliant applications. If we don't want to make it a public > interface, __qsort would be best (and is probably the choice of least > resistance). Why not do something like the rpc code does? Check if threaded, if so cons up a thread specific key otherwise use a global. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
< said: > How should we call this function? > (I'll implement this tomorrow.) I was would call it `qsort_with_arg' or something similar. There is a namespace issue here; reserves very little namespace for the implementation, so anything we add will have to be hidden from strictly-compliant applications. If we don't want to make it a public interface, __qsort would be best (and is probably the choice of least resistance). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new ipv6 causes panic
Building the kernel without INET6 makes this error go away. cvsup as
of about two hours ago.
recursed on non-recursive lock (sleep mutex) mbuf free list lock @
../../kern/uipc_mbuf.c:582
first acquired @ ../../kern/uipc_mbuf.c:582
panic:recurse
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db> t
Debugger(c036a77b) at Debugger+0x45
panic(c036d3e8,1,c0b85a00,c0b85b00,0) at panic+0x70
witness_lock(c0425ae0,8,c036fac2,246) at witness_lock+0x356
m_freem(c0b85b00,c0eec540,c0fb5bc0,c0b87840,c7f6aeb8) at m_freem+0x342
m_freem(c0b85a00,c0b85a00,0,18,c029dab6) at m_freem+0x365
mld6_input(c0b85a00,30) at mld6_input+0x350
icmp6_input(c7f6af44,c7f6af2c,3a,c0b85c00,4) at icmp6_input+0x8d6
ip6_input(c0b85c00) at ip6_input+0x13bd
ip6intr(c0b3c1c0,c0b34600,c7f6af7c,c020a444,0) at ip6intr_0x13e
swi_net(0) at swi_net+0x38
ithread_loop(c0b34600,c7f6afa8) at ithread_loop+0x2c0
fork_exit(c020a184,c0b34600,c7f6afa8) at fork_exit+0xb6
fork_trampoline() at fork_trampoline+0x8
db> show locks
exclusive (sleep mutex) mbuf free list lock (0xc0425ae0) locked @
../../kern/uipc_mbuf.c:582
exclusive (sleep mutex) Giant (oxc0429d40) locked @ ../.../kern/kern_intr.c:520
db> show r
cs 0x8
ds 0xc03f0010 w_shilddata+0x3bb0
es 0x10
fs 0xc03e0018 harrvestring+0x7358
ss 0x10
eax 0x12
ecx 0x20
edx 0xc03894af db_lengths+0x1d7
ebx 0x202
esp 0xc7f6ae14
ebp 0xc7f6ae20
esi 0x100
edi 0xc040e8ac
eip 0xc03175e1
efl 0x46
Debugger+0x45: pushl %ebx
--
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church Washburn, Iowa
An infallible method of conciliating a tiger
is to allow oneself to be devoured. -- Konrad Adenauer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
On Wed, Jun 13, 2001 at 11:16:57AM -0400, Garrett Wollman wrote: > < said: > > > 3. Provide an alternative to qsort() that takes an comparison function > >that takes an additional function pointer arg (use this arg to avoid > >the global in (1)). > > Actually, doing this would solve a number of similar problems, and it > doesn't look to be too difficult to do. I would make the additional > argument a `void *'; fts's comparison trampoline function could use > this as a `FTS *' to look up the comparison function. (I think this > is more general than passing any kind of function pointer.) > How should we call this function? (I'll implement this tomorrow.) -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
< said: > 3. Provide an alternative to qsort() that takes an comparison function >that takes an additional function pointer arg (use this arg to avoid >the global in (1)). Actually, doing this would solve a number of similar problems, and it doesn't look to be too difficult to do. I would make the additional argument a `void *'; fts's comparison trampoline function could use this as a `FTS *' to look up the comparison function. (I think this is more general than passing any kind of function pointer.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fts_open() (was: Re: Patch to restore WARNS feature)
On Wed, 13 Jun 2001, Ruslan Ermilov wrote: > Should I commit the attached patch then? I don't like changing the documented interface of fts_open() but all the alternatives that I can think of aren't appealing: 1. Provide a glue function that converts what qsort expects to the documented interface. This seems to require saving sp->fts_compare in a global variable so that it can be accessed in the glue function. 2. Provide an alternative to qsort() that takes an fts-compatible comparison function. 3. Provide an alternative to qsort() that takes an comparison function that takes an additional function pointer arg (use this arg to avoid the global in (1)). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
close a PR !!
Guys, We've been doing pretty well on the PR/Gnats front since we started our little "Close a PR" drive, but now is not the time to loose steam. http://phk.freebsd.dk/Gnats/ We're at the same level of unclosed PR's as we were half a year ago, down 500 from when we began the drive, but still 2653 to go... So please, everybody (committers and non-committers alike!) take a peek at the PR list here and close a couple of stale PR's for us: http://www.FreeBSD.org/cgi/query-pr-summary.cgi Committers close PR's with "edit-pr" on freefall. Non-committers by submitting a followup which contains an explanation and the grep(1)'able line: This PR can be closed Remember: Each open PR is a pissed off contributor... -- 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
fts_open() (was: Re: Patch to restore WARNS feature)
Should I commit the attached patch then?
On Tue, Jun 12, 2001 at 02:35:39PM +1000, Bruce Evans wrote:
> > For those interested, here's the missing patch.
>
> Index: lib/libc/gen/fts.c
> ===
> RCS file: /home/ncvs/src/lib/libc/gen/fts.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 fts.c
> --- lib/libc/gen/fts.c2001/06/01 21:53:50 1.18
> +++ lib/libc/gen/fts.c2001/06/11 18:20:17
> @@ -936,7 +936,8 @@ fts_sort(sp, head, nitems)
> }
> for (ap = sp->fts_array, p = head; p; p = p->fts_link)
> *ap++ = p;
> - qsort((void *)sp->fts_array, nitems, sizeof(FTSENT *), sp->fts_compar);
> + qsort((void *)sp->fts_array, nitems, sizeof(FTSENT *),
> + (int (*) __P((const void *, const void *)))sp->fts_compar);
> for (head = *(ap = sp->fts_array); --nitems; ++ap)
> ap[0]->fts_link = ap[1];
> ap[0]->fts_link = NULL;
>
> This just hides the bug that fts's comparison function is not suitable
> for use by qsort().
>
> Bruce
On Tue, Jun 12, 2001 at 02:38:13PM -0400, Garrett Wollman wrote:
> < said:
>
> > + qsort((void *)sp->fts_array, nitems, sizeof(FTSENT *),
> > + (int (*) __P((const void *, const void *)))sp->fts_compar);
>
> This is wrong. The declaration of the comparison function should be
> fixed, rather than papering over the mistake here.
>
> (This is arguably a deficiency in the C standard. qsort() should take
> an additional state parameter for the comparison function, but
> doesn't.)
>
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: include/fts.h
===
RCS file: /home/ncvs/src/include/fts.h,v
retrieving revision 1.3
diff -u -p -r1.3 fts.h
--- include/fts.h 1997/05/07 19:59:58 1.3
+++ include/fts.h 2001/06/13 12:17:31
@@ -45,7 +45,8 @@ typedef struct {
int fts_rfd;/* fd for root */
int fts_pathlen;/* sizeof(path) */
int fts_nitems; /* elements in the sort array */
- int (*fts_compar)();/* compare function */
+ int (*fts_compar) /* compare function */
+ __P((const void *, const void *));
#defineFTS_COMFOLLOW 0x001 /* follow command line symlinks */
#defineFTS_LOGICAL 0x002 /* logical walk */
@@ -120,7 +121,7 @@ __BEGIN_DECLS
FTSENT *fts_children __P((FTS *, int));
int fts_close __P((FTS *));
FTS*fts_open __P((char * const *, int,
- int (*)(const FTSENT **, const FTSENT **)));
+ int (*)(const void *, const void *)));
FTSENT *fts_read __P((FTS *));
int fts_set __P((FTS *, FTSENT *, int));
__END_DECLS
Index: lib/libc/gen/fts.3
===
RCS file: /home/ncvs/src/lib/libc/gen/fts.3,v
retrieving revision 1.12
diff -u -p -r1.12 fts.3
--- lib/libc/gen/fts.3 2001/02/01 16:29:34 1.12
+++ lib/libc/gen/fts.3 2001/06/13 12:17:32
@@ -45,7 +45,7 @@
.Fd #include
.Fd #include
.Ft FTS *
-.Fn fts_open "char * const *path_argv" "int options" "int (*compar)(const FTSENT **,
const FTSENT **)"
+.Fn fts_open "char * const *path_argv" "int options" "int (*compar)(const void *,
+const void *)"
.Ft FTSENT *
.Fn fts_read "FTS *ftsp"
.Ft FTSENT *
@@ -462,9 +462,9 @@ The argument
specifies a user-defined function which may be used to order the traversal
of the hierarchy.
It
-takes two pointers to pointers to
-.Fa FTSENT
-structures as arguments and
+takes two pointers as arguments (which need to be cast to
+.Vt "FTSENT **"
+inside the function's body) and
should return a negative value, zero, or a positive value to indicate
if the file referenced by its first argument comes before, in any order
with respect to, or after, the file referenced by its second argument.
Index: lib/libc/gen/fts.c
===
RCS file: /home/ncvs/src/lib/libc/gen/fts.c,v
retrieving revision 1.18
diff -u -p -r1.18 fts.c
--- lib/libc/gen/fts.c 2001/06/01 21:53:50 1.18
+++ lib/libc/gen/fts.c 2001/06/13 12:17:35
@@ -85,7 +85,7 @@ FTS *
fts_open(argv, options, compar)
char * const *argv;
register int options;
- int (*compar) __P((const FTSENT **, const FTSENT **));
+ int (*compar) __P((const void *, const void *));
{
register FTS *sp;
register FTSENT *p, *root;
Index: bin/cp/cp.c
===
RCS file: /home/ncvs/src/bin/cp/cp.c,v
retrieving revision 1.26
diff -u -p -r1.26 cp.c
--- bin/cp/cp.c 2001/06/11 13:57:54 1.26
+++ bin/cp/cp.c 2001/0
Re: msdosfs can't mount Extended partition. Any ideas?
On Tue, 12 Jun 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Szilveszter Adam writes: > : > Thanks, it works. I was confused by 'devfs' this time which not show ad0s5 > : > slice under /dev until it is actualy mounted. > : > : Yes, devfs really takes some getting used to in the beginning, at least it > : has for me:-) > > I'm not sure I like this whole magically appearing on first access > device thing :-( I'm sure I don't like it :-). Do you like cd /dev ls $(jot -w tun 8000 0) # 8000 = big, but not too big for ARG_MAX ls tun* The first "ls" should create about 8000 new tun devices by first accessing them via stat(2), but there is some garbage collection, so the second "ls" may show that some of the devices have magically unappeared. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Terminal line discipline is broken [sorta]
On Sun, 10 Jun 2001, Valentin Nechayev wrote: > Thu, Jun 07, 2001 at 12:04:10, bde (Bruce Evans) wrote about "Re: Terminal line >discipline is broken [sorta]": > > > This may be a bug in tcsh. > > Do you really think that shell should not modify signal handling policy > which he obtained as legacy from login? And application which resets > them to appropriate position is buggy? Non-interactive shells certainly shouldn't unblock/unignore blocked/ignored signals. I think it doesn't matter much for interactive shells. Login would only change the system defaults if it is broken. > My ktracing of bash (2.04) shows that it isn't really set procmask > to own values, but uses legacy value. Maybe I'm wrong, but this seems > that sh & bash are buggy, not tcsh. Bash does much more initialization for signals than sh. Maybe it knows what it is doing :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)
[Crawling out of hiding again] -On [20010611 19:30], Andrey A. Chernov ([EMAIL PROTECTED]) wrote: >I agree, but just imagine that I have assumption that Peter already >resolve this issue with Nick (since he do repo copy) and you'll find >a reason to not be extra-cautious. First lesson I learned when playing in the real world is to never assume anything get verification from anyone in writing. Besides, with source repositories one always needs to be cautious, at least in my humble opinion. No critique, just, hopefully, helpful comments. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/ Conscience is God's presence in man... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
> The reason I said "in the next week" is actually because on Sat. June 23rd > (not this upcoming one, but the one after), I should be flying off to > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > gone for 3 weeks and seeing as how maintaining this huge diff is a real > (especially given the state of -CURRENT, as I'm sure you know :-)), I realise that maintaining the diff is a major pain, but this is *not* a good reason to be rushing it now, *especially* when you're going to be gone for three weeks. I appreciate the extra work involved, but please take this as an extremely serious request to defer your commit until it's had some more testing, and until you're in a position to support it for more than 36 hours after you commit. Thanks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
