Re: panic: bdwrite: buffer is not busy
On 10 Feb, Bruce Evans wrote:
> On Sat, 9 Feb 2002, John Baldwin wrote:
>
>> On 09-Feb-02 Mikhail Teterin wrote:
>> > While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or
>> > ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With
>> > todays or Jan 3rd kernel (my previous upgrade).
>>
>> Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite
>> is just extra garbage, the real panic is due to a NULL pointer
>> dereference:
>
> This is a well known bug in the device layer. I reported it on
> 2001/12/26 and fixed it locally a little later. See the thread in
> -current about "panic during fdisk'ing a md(4) device" for patches.
Fdisk I don't really need, but attempting to newfs the floppy caused the
same panic :-\ And mounting the already formatted floppy leads to
"invalid argument". Could we have this fixed soon, please? The inability
to access a floppy is a great setback for my local FreeBSD advocacy
efforts :-)
-mi
>> I'm guessing that devsw() is returning NULL here. You could add a
>> KASSERT() to this macro just before the call to d_strategy() along
>> the lines of
>>
>> KASSERT(devsw((bp)->bio_dev) != NULL, ("no devsw for bio"));\
>
> Right. From my original bug report:
>
> ! "fdisk /dev/fd0" now causes a null pointer panic in readdisklabel().
> ! This is because fdioctl() attempts to construct a (slightly
> ! wrong) device using dkmodpart(), but dkmodpart() only constructs a
> ! half-baked device since it only calls makedev(). The device is
> ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Sun, 10 Feb 2002, Kevin Day wrote: > > I'm the maintainer for ports/editors/joe, and just tried compiling it under > -CURRENT. > > includes which includes ucontext.h > > > cc -O -pipe -c umath.c > > In file included from b.h:6, > > from bw.h:23, > > from umath.c:5: > > rc.h:41: conflicting types for `getcontext' > > /usr/include/sys/ucontext.h:54: previous declaration of `getcontext' > > *** Error code 1 > > > > Stop in /usr/ports/editors/joe/work/joe. > > > I can rename getcontext in joe, but "getcontext" seems like a pretty common > function name, I know I've used it in projects before. Not including > signal.h isn't really an option either. > > I'm not familiar with any of the ucontext.h functions, are they complying > with some kind of standard and can't be renamed or have a prefix added to > it? Yea, getcontext is part of SUSv2 and the 2001 POSIX spec. It has been present in at least Solaris for years now, so it's kind of weird that joe hasn't had the problem when built for it [Solaris]. Hmm, includes . I'm not sure why though. bde might know. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic (runq_choose()) in today's -CURRENT
Built today's -CURRENT as usual; booted & ran a few things without incident. Issued: freebeast(5.0-C)[2] sudo boot0cfg -s 1 ad0 && sudo reboot and this showed up on the serial console: FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: Fboot() called on cpu#1 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped lock order reversal 1st 0xc0335600 sched lock @ /usr/src/sys/kern/kern_idle.c:105 2nd 0xc038ea60 sio @ /usr/src/sys/dev/sio/sio.c:3137 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0xd6820001 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a638f stack pointer = 0x10:0xd683dcd0 frame pointer = 0x10:0xd683dce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu0) kernel: type 12 trap, code=0 timeout stopping cpus Stopped at runq_choose+0x83: movl0(%edx),%eax db> trace runq_choose(c0358880,d683dd0c,c02b01ce,c01a7857,34948) at runq_choose+0x83 choosethread(c01a7857,34948,c0194f10,d682d500,77) at choosethread+0xd sw1(d682d604,d683dd34,c0194d50,0,d683dd48) at sw1+0x20 idle_proc(0,d683dd48,0,c0194f10,0) at idle_proc+0x5c fork_exit(c0194f10,0,d683dd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> I haven't seen any kernel-related commits since I did the CVSup (from 0347 - about 0356 hrs. today, US/Pacific (8 hrs. west of GMT). (Previous CVSup was 24 hrs. earilier, and the kernel built then -- which is what I was running when I built this one -- had not exhibited the symptom.) Anything else I can do to help find & resolve this? Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (runq_choose()) in today's -CURRENT
>Date: Sun, 10 Feb 2002 08:31:57 -0800 (PST)
>From: David Wolfskill <[EMAIL PROTECTED]>
>db> trace
>runq_choose(c0358880,d683dd0c,c02b01ce,c01a7857,34948) at runq_choose+0x83
>choosethread(c01a7857,34948,c0194f10,d682d500,77) at choosethread+0xd
>sw1(d682d604,d683dd34,c0194d50,0,d683dd48) at sw1+0x20
>idle_proc(0,d683dd48,0,c0194f10,0) at idle_proc+0x5c
>fork_exit(c0194f10,0,d683dd48) at fork_exit+0x9c
>fork_trampoline() at fork_trampoline+0x8
>db>
>...
>Anything else I can do to help find & resolve this?
A little more information:
* My laptop (running the same sources, though a somewhat different
kernel config and a rather different hardware config) did not exhibit
the symptoms.
* A few other things occurred to me that might be of interest with DDB:
db> show pcpu 0
cpuid= 0
curthread= 0xd682d604: pid 11 "idle: cpu0"
curpcb = 0xd683dda0
fpcurthread = none
idlethread = 0xd682d604: pid 11 "idle: cpu0"
currentldt = 0x28
spin locks held:
exclusive (spin mutex) sched lock (0xc0335600) locked @
/usr/src/sys/kern/kern_idle.c:105
db> show pcpu 1
cpuid= 1
curthread= 0xda41a604: pid 289 "reboot"
curpcb = 0xda432da0
fpcurthread = none
idlethread = 0xd682d904: pid 10 "idle: cpu1"
currentldt = 0x28
spin locks held:
exclusive (spin mutex) clk (0xc0338ee0) locked @ /usr/src/sys/i386/isa/clock.c:415
db> show locks
exclusive (spin mutex) sched lock (0xc0335600) locked @
/usr/src/sys/kern/kern_idle.c:105
db> show lockedvnodes
Locked vnodes
panic: blockable sleep lock (sleep mutex) mountlist @ /usr/src/sys/kern/vfs_subr.c:2371
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at runq_choose+0x83: movl0(%edx),%eax
db>
Cheers,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >On Sat, 9 Feb 2002, Julian Elischer wrote: > > > >> On Sun, 10 Feb 2002, Bruce Evans wrote: > >> > > >> > This is a well known bug in the device layer. I reported it on 2001/12/26 > >> > and fixed it locally a little later. See the thread in -current about > >> > "panic during fdisk'ing a md(4) device" for patches. > >> > > >> Can you commit the fix? > > > >The maintainer should be able to it better. I rarely test the devfs parts, > >but the bulk of the patch is to help devfs. My patch needs some cleanups > >(mainly non-hacked interfaces) anyway. > > The maintainer is busy rewriting that entire area of the code which will > help immensely :-) Do you mean geom? No thanks. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: final ucred patch
> After comments by jhb and bde
>
> Index: i386/i386/trap.c
> ===
> RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
> retrieving revision 1.211
> diff -u -r1.211 trap.c
> --- i386/i386/trap.c 10 Jan 2002 11:49:54 - 1.211
> +++ i386/i386/trap.c 10 Feb 2002 00:52:58 -
> @@ -256,9 +256,19 @@
> sticks = td->td_kse->ke_sticks;
> td->td_frame = &frame;
> KASSERT(td->td_ucred == NULL, ("already have a ucred"));
> - PROC_LOCK(p);
> - td->td_ucred = crhold(p->p_ucred);
> - PROC_UNLOCK(p);
> + if (td->td_ucred != p->p_ucred) {
> + if (td->td_ucred) {
> + mtx_lock(&Giant);
> + crfree(td->td_ucred);
> + td->td_ucred = NULL;
> + mtx_unlock(&Giant);
See below about placement of this unlock.
> + }
> + if (p->p_ucred) {
How can this be NULL? The old code didn't check.
> + PROC_LOCK(p);
> + td->td_ucred = crhold(p->p_ucred);
> + PROC_UNLOCK(p);
> + }
> + }
The inner block is large enough and repeated enough to turn into a function.
>
> switch (type) {
> case T_PRIVINFLT: /* privileged instruction fault */
> @@ -644,10 +654,12 @@
> userret(td, &frame, sticks);
> mtx_assert(&Giant, MA_NOTOWNED);
> userout:
> +#ifdef INVARIANTS
> mtx_lock(&Giant);
> crfree(td->td_ucred);
> - mtx_unlock(&Giant);
> td->td_ucred = NULL;
> + mtx_unlock(&Giant);
> +#endif
> out:
> return;
> }
I think moving the unlock is just an obfuscation. td_ucred isn't locked
by Giant.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Sun, 10 Feb 2002, Daniel Eischen wrote: > Hmm, includes . I'm not sure why though. > bde might know. includes for the normal namespace pollution that was needed to use sigreturn(2) (except sigreturn(2) itself isn't actually declared anywhere). Including gives the corresponding namespace pollution for using the current sigreturn(2). This is probably a mistake. (Don't believe the sigreturn man page; it documents osigreturn(2) for the i386 only.) Programs shouldn't have any problems with this, since they should define _POSIX_SOURCE if they only want the POSIX namespace ;-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
I've created a new patch to deal with a problem found during testing (thanks to David Wolfskill). This should fix sites who use sendmail_enable="NO" but still want to be able to process command line mail -- we still need a localhost-only SMTP daemon to accept command line mail. Complete details are in etc/mail/README (after patching). The updated patch is available at the same location: http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 Follow the instructions in that file and please report any successes or failures to me directly. I plan on committing the changes during or soon after BSDCon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
On Sun, Feb 10, 2002 at 12:13:05 -0800, Gregory Neil Shapiro wrote:
>
> http://people.freebsd.org/~gshapiro/CURRENT-8.12.2
--- lib/libmilter/Makefile~orig Sun Jan 20 13:58:03 2002
+++ lib/libmilter/Makefile Sun Jan 20 13:05:02 2002
@@ -0,0 +1,28 @@
+# $FreeBSD$
+
+MAINTAINER=[EMAIL PROTECTED]
+
+SENDMAIL_DIR=${.CURDIR}/../../contrib/sendmail
+.PATH: ${SENDMAIL_DIR}/libmilter ${SENDMAIL_DIR}/libsm
+
+CFLAGS+=-I${SENDMAIL_DIR}/src -I${SENDMAIL_DIR}/include -I.
+CFLAGS+=-DNETINET6 -DNOT_SENDMAIL -Dsm_snprintf=snprintf
+CFLAGS+=-pthread
^^
Why you add -pthread? IMHO it is needed only on program building 'ld'
phase and not in library building. See libc_r/Makefile
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: usdb missing detaches ???
On Sun, 2002-02-10 at 23:29, Paul van der Zwan wrote:
> > On Sun, 2002-02-03 at 15:08, Paul van der Zwan wrote:
> > >
> > > I'm experimenting with my Sony DSC S70 and USB.
> > > I can get -current to mount the stick in the camera but it won't umount
> > > the filesystem on detach.
> >
> > Just found that on lates -CURRENT my notebook keyboard not returned when
> > I have detach USB keyboard - It was working well before.
> >
> > Somebody have broke usb detaching ?
>
> The only usb device I have connected is my camera so I have no experiences
> with mice or keyboards, but yours it the first response at all at my
> message, so I still have no idea if the behaviour i see is the way it
> should be or a bug...
So, I have done some invistigations:
'usbd -d -v -v' output here with comments:
*** Attaching USB hub with mouse and combo keyboard:
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1013373305.235405000, UT-USB41 hub, Texas
Instruments:
vndr=0x0451 prdct=0x1446 rlse=0x0110 clss=0x0009 subclss=0x
prtcl=0x
device names: uhub1
usbd: Found action 'USB device' for UT-USB41 hub, Texas Instruments at
uhub1
usbd: action 0: USB device
usbd: Setting DEVNAME='uhub1'
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1013373305.813311000, Microsoft
IntelliMouse® Explorer, Microsoft:
vndr=0x045e prdct=0x001e rlse=0x0114 clss=0x subclss=0x
prtcl=0x
device names: ums0
usbd: ums0 matches ums[0-9]+
usbd: Found action 'Mouse' for Microsoft IntelliMouse® Explorer,
Microsoft at ums0
usbd: action 0: Mouse
devname: ums[0-9]+
attach='/usr/sbin/moused -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid -m 6=4 -m 7=5'
detach='kill /var/run/moused.${DEVNAME}.pid'
usbd: Setting DEVNAME='ums0'
usbd: Executing '/usr/sbin/moused -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid -m 6=4 -m 7=5'
usbd: '/usr/sbin/moused -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid -m 6=4 -m 7=5' is ok
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1013373306.424875000, Keyboard with mouse
port, Behavior Tech. Computer:
vndr=0x046e prdct=0x6782 rlse=0x0100 clss=0x subclss=0x
prtcl=0x
device names: ukbd0,ums1
usbd: Found action 'Keyboard with Mouse' for Keyboard with mouse port,
Behavior Tech. Computer
usbd: action 0: Keyboard with Mouse
vndr=0x046e prdct=0x6782 rlse=0x0100
attach='/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0'
detach='/usr/sbin/kbdcontrol -k /dev/kbd0 -r fast < /dev/ttyv0'
usbd: Executing '/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0'
kbd1
ukbd0, type:generic (0)
usbd: '/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0' is ok
*** all seems Ok, moused stared, keyboard activated
usbd: doing timeout discovery on /dev/usb0
usbd: processing event queue due to timeout on /dev/usb
*** nothing plugged/unpluget on USB bus but got this message
usbd: processing event queue on /dev/usb
usbd: driver-detach event cookie=3217028628 devname=uhub1
USB_EVENT_DRIVER_DETACH
*** this happens after detach - usbd see some detaching but not execute
*** detach scripts :(
on dmesg:
hub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2
uhub1: 4 ports with 4 removable, bus powered
ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3,
iclass 3/1
ums0: 5 buttons and Z dir.
uhub1: device problem, disabling port 2
uhub1: at uhub0 port 1 (addr 2) disconnected
ums0: detached
uhub1: detached
p.s.:
may be it is time to send PR ?
> Paul
--
SW Soft, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
>> http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 ache> +CFLAGS+=-pthread ache> ^ ache> Why you add -pthread? IMHO it is needed only on program building 'ld' ache> phase and not in library building. See libc_r/Makefile Thanks, I've changed that line to: CFLAGS+=-D_THREAD_SAFE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usdb missing detaches ???
On 10-Feb-2002 (20:42:26/GMT) Vladimir B. " Grebenschikov wrote:
I can get -current to mount the stick in the camera but it
won't umount the filesystem on detach.
> ums0: detached
> uhub1: detached
I have the same problem here: I added this to /etc/usbd.conf:
---8<---
device "Scanner Epson, modello Perfection1240 (photo)"
# Perfection1240(0x010b), EPSON(0x04b8), rev 0x0114
product 0x010b
vendor 0x04b8
release 0x0114
devname "uscanner[0-9]+"
attach "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker"
## attach "/bin/chmod 666 /dev/uscanner0 && echo L16cce > /dev/speaker"
detach "echo L16eec > /dev/speaker"
---8<---
And this happens to /var/log/messages, but I got tune played only
on device attach, not on detach (attach/detach means cycle power
to scanner, without touching usb cable).
-8<-[ /var/log/messages ]-8<-
...kernel: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2
...kernel: uscanner0: at uhub0 port 1 (addr 2) disconnected
and after usage, when power off:
...kernel: uscanner0: detached
If I understand manuals and examples attach/detach can run _any_
action I want. Or not?
Riccardo.
PS: chmod is needed to use xscanimage from my user.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Minor things: swi_net: unregistered isr number
If this might be of interest: kernel built 07.feb at boot time... | Doing initial network setup: hostname. * swi_net: unregistered isr number: 18. | xl0: flags=8843 mtu 1500 | options=3 [...] This is (probably) the dhclient being run at this time, maybe. Should I be bothered by the following? unknown: can't assign resources unknown: can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: can't assign resources unknown: can't assign resources this is after all of these have been detected and assigned (sio0, sio1, etc) ata3: at port 0x36e-0x36f,0x168-0x16f irq 10 o n isa0 Where did that come from, and why don't I know about it? I know about: ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 and -stable makes no claim I have a third ata controller... machine is ancient digital venturis 575 pc thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Mon, 11 Feb 2002, Bruce Evans wrote:
> On Sun, 10 Feb 2002, Daniel Eischen wrote:
>
> > Hmm, includes . I'm not sure why though.
> > bde might know.
>
> includes for the normal namespace
> pollution that was needed to use sigreturn(2) (except sigreturn(2)
> itself isn't actually declared anywhere). Including
> gives the corresponding namespace pollution for using the current
> sigreturn(2). This is probably a mistake. (Don't believe the
> sigreturn man page; it documents osigreturn(2) for the i386 only.)
> Programs shouldn't have any problems with this, since they should
> define _POSIX_SOURCE if they only want the POSIX namespace ;-).
Poking about on a Solaris 8 system shows that they have a
that defines the {get,set,make,swap}context
prototypes. also includes
to get the definitions for ucontext_t.
Under FreeBSD, is a link to ,
which both declare ucontext_t and {get,set,make,swap}context.
What do you recommend we do? Should we not include
from , or do what Solaris does, or just leave
everything as is?
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Unconnected files problem
I have (finally) found and fixed this problem. You need to get version 1.107 or later of /sys/ufs/ffs/ffs_softdep.c (2002/02/07). Kirk McKusick =-=-=-=-=-= Date: Tue, 28 Aug 2001 14:02:24 +0200 From: Ollivier Robert <[EMAIL PROTECTED]> To: "FreeBSD Current Users' list" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Unconnected files problem I have a script that generates index for all my mail messages (using glimpse). Sometimes, the disk is full because it has some rather big temporary files (and I have a lot of mail). It seems that we may have a softupdate-related (that's a guess from me) problem because some of these temporaty files end up as unconnected to any directory but link count is still one and they still takes space. The last time fsck ran on the filesystem, it gave me back more than 6 (!!) fragments (cf the following: -=-=- Aug 23 12:21:38 caerdonn root: /dev/da0s1g: Reclaimed: 0 directories, 22 files, 60424 fragments Aug 23 12:21:38 caerdonn root: /dev/da0s1g: 10295 files, 387087 used, 73408 free (1048 frags, 9045 blocks, 0.2% fragmentation) -=-=- lsof doesn't show them so they're not open by any process. The mtime of the files are exactly when the glimpseindex command is run. We know that SU has some issues when a filesystem is full but this is quite a problem because as you can see below, I'm losing a lot of space till the next reboot... UNREF FILE I=1081 OWNER=roberto MODE=100600 SIZE=523 MTIME=Aug 28 00:46 2001 CLEAR? no UNREF FILE I=18498 OWNER=roberto MODE=100600 SIZE=230665 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=18508 OWNER=roberto MODE=100600 SIZE=11225707 MTIME=Aug 23 20:02 2001 RECONNECT? no CLEAR? no UNREF FILE I=18530 OWNER=roberto MODE=100600 SIZE=28322748 MTIME=Aug 24 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18573 OWNER=roberto MODE=100600 SIZE=28326193 MTIME=Aug 25 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18575 OWNER=roberto MODE=100600 SIZE=18684173 MTIME=Aug 24 20:08 2001 RECONNECT? no CLEAR? no UNREF FILE I=19204 OWNER=roberto MODE=100600 SIZE=13771800 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=19353 OWNER=roberto MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08 2001 RECONNECT? no CLEAR? no ** Phase 5 - Check Cyl groups 10223 files, 446324 used, 74595 free (1019 frags, 9197 blocks, 0.2% fragmentation) fsdb (inum: 2)> inode 19353 current inode: regular file I=19353 MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08:18 2001 [0 nsec] CTIME=Aug 25 20:08:18 2001 [0 nsec] ATIME=Aug 25 20:08:11 2001 [0 nsec] OWNER=roberto GRP=staff LINKCNT=1 FLAGS=0 BLKCNT=8ec0 GEN=4c2a6c10 -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Sun, 10 Feb 2002, Daniel Eischen wrote:
> On Mon, 11 Feb 2002, Bruce Evans wrote:
> > includes for the normal namespace
> > pollution that was needed to use sigreturn(2) (except sigreturn(2)
> > itself isn't actually declared anywhere). Including
> > gives the corresponding namespace pollution for using the current
> > sigreturn(2). This is probably a mistake. (Don't believe the
> > sigreturn man page; it documents osigreturn(2) for the i386 only.)
> > Programs shouldn't have any problems with this, since they should
> > define _POSIX_SOURCE if they only want the POSIX namespace ;-).
>
> Poking about on a Solaris 8 system shows that they have a
> that defines the {get,set,make,swap}context
> prototypes. also includes
> to get the definitions for ucontext_t.
is just as nonstandard as .
> Under FreeBSD, is a link to ,
> which both declare ucontext_t and {get,set,make,swap}context.
The link part is intentional. We have to have for
use in the kernel, so it is simpler not to have a separate user
header. The only advantage of the Solaris implementation is that
it punishes applications that include the nonstandard header.
> What do you recommend we do? Should we not include
> from , or do what Solaris does, or just leave
> everything as is?
Don't include from , and fix whatever
breaks. I think applications that use the new sigreturn can be required
to include both and . There should be fewer
of them than there used to be -- they can now use setcontext(). The
old sigcontext/sigreturn stuff should be cleaned up too (don't export
it to userland).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
"Andrey A. Chernov" wrote: > +CFLAGS+=-pthread > ^^ > > Why you add -pthread? IMHO it is needed only on program building 'ld' > phase and not in library building. See libc_r/Makefile -D_THREAD_SAFE -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
