RE: COW and mprotect on non-shared memory
> For that reason, when you mprotect an area of non-shared, anonymous
> memory to no access and then back to writable, Linux has no way of
> knowing that the memory wasn't set for COW before you make it
> unwritable. It goes ahead and makes all the pages in the area COW.
>
> That means that if I do this:
>
> for (i = 0; i < n; ++i) {
> assert(!mprotect(p, pgsiz, PROT_NONE));
> assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
> p[i] = i & 0xff;
> }
>
> ... I get n minor page faults! Pretty amazing, but I guess they
> figured nobody does that.
>
> More surprising is that the same test program has the same behavior on
> FreeBSD. (At least, the "/usr/bin/time -l ..." output shows the
> number of page reclaims increasing at the same rate that I increase
> the value of n in the loop.)
>
> I thought that in FreeBSD any COW area would have its own vm_map_entry
> with the MAP_ENTRY_COW bit set. That way, you could run this test
> without any minor faults at all. Now I suspect I was incorrect.
> Could anyone help clarify the situation for me?
>
> Thanks.
>
> --
> --Ed L Cashin| PGP public key:
> [EMAIL PROTECTED]| http://noserose.net/e/pgp/
>
The first mprotect() removes the physical mapping from the page table,
the second mprotect() doesn't do anything because the mapping isn't
there. So when the page is accessed, a fault is needed to insert the
mapping back to the page table.
-lq
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: kern/40611 linux compatibility fix
> Dear Hackers, > > Is there any chance that the patch given in kern/40611 could be > committed to the 4-STABLE tree? It has the desirable effect of making > eg. the linux-sun-jdk14 port usable as a non-root user. This would > appear to my untutored eye to be a sub-set of the differences already > existing between the HEAD and RELENG_4 versions of > src/sys/posix4/p1003_1b.c > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks > Savill Way > PGP: http://www.infracaninophile.co.uk/pgpkey Marlow > Tel: +44 1628 476614 Bucks., SL7 1TH UK > I've a similar but more complete patch. It handles both get and set cases, and also takes into account jailed environment. It should have identical semantics to -current (except for the see_other_uids flag), at least at the time when I created the patch. You may inspect the patch at http://people.freebsd.org/~luoqi/p1003_1b.diff I didn't know there're so many people running linux apps under emulation. I've a couple of other linux related patches for -stable, among them backport of linux ptrace from -current, anyone interested? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Network connection problem: SIS, miibus
> From: [EMAIL PROTECTED] > [mailto:owner-freebsd-hackers@;FreeBSD.ORG]On Behalf Of Paul Everlund > Sent: Tuesday, November 12, 2002 10:42 AM > To: [EMAIL PROTECTED] > Subject: Network connection problem: SIS, miibus > > > Hi all! > > Did try questions, without any reply, so I'm trying here... > > I have a friend who decided to try FreeBSD 4.6.2 and it works just > fine except one thing, his connection to the internet. > > He has a sis network card, which is compiled into the kernel, with > miibus that is required. > Could you post the output from the `pciconf -l | grep sis' command? I have a couple of machines with integrated sis ethernet controllers (sis962 south bridge), and the if_sis driver would not work without some tweaking. If your friend is using something similar, I could send a patch for him to try. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Int 0x15 and VM86 question
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:owner-freebsd-hackers@;FreeBSD.ORG]On Behalf Of Matthew Dillon > Sent: Friday, November 08, 2002 2:08 AM > To: [EMAIL PROTECTED] > Subject: Int 0x15 and VM86 question > > > I've been pulling my hair out all night trying to figure out how > the hell the VM86 code is able to issue an int 0x15 to the BIOS. > I can't find where it gets the interrupt descriptor table entry > for int 0x15. My assumption is that it copies it from the idt > supplied by the BIOS but I don't see where. As far as I can tell > FreeBSD loads a pristine IDT that does not have a record for > int 0x15. So how can the VM86 code issue an int 0x15 and have it > find the BIOS? > > If anyone knows the answer to this, I'm all ears! > > -Matt > > When iopl is less than 3 (that's what our kernel is running at), the soft interrupts in vm86 are not dispatched through the normal protective mode idt vector. Depending on your vme setting and interrupt redirection bitmap, it either triggers a general protection fault (vme clear and redir bit set), or directly jumps to vector at low memory as in real mode (vme set and redir bit clr). IIRC vme is available for P5 or later processors. So for you it most likely is the direct jump. The first page of physical memory (which contains the BIOS vectors) is not touched by the kernel, and is mapped at address 0 in the vm86 process space. Does this answer your question, Matt? It has been quite a while since I looked at the stuff, some of the descriptions might not be accurate. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Atheros 802.11a chipset driver
Hi, Does anyone know if someone is working on the driver for Atheros 802.11a chipset? I heard from Atheros there're people actively developing driver for Linux/FreeBSD and would probably be ready in "a few months", but couldn't get any more detail. A few more months is probably more than I'm willing to wait. So I'd like to get in touch with people who are working on this and maybe help to speed up the process. If there is no such person, I've have to start writing one on my own. Thanks -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Processes, context switching in kernel...
> All, > > I'm working on the emulator for OSF1/Mach for FreeBSD/Alpha, and I need > some help understanding how to do some things in the FreeBSD kernel--if anyone > can answer any of the following questions, it would be greatly appreciated: > > 1) How do you create a process in the kernel (i.e., you fork in > user-space...what's the analogue for kernel-space)? > fork1(), see kern_fork.c > 2) How do you clone a process in kernel-space (i.e., in user-space, you would > fork and then share the entire process's memory space--how would you do such a > thing in kernel-space)? > fork1() with RFMEM flag. > 3) What needs to be done to perform a context switch (from within the kernel), > and are there any MP considerations when doing this? > Do the following, s = splhigh(); setrunqueue(p); p->p_stats->p_ru.ru_nivcsw++; mi_switch(); splx(s); nothing special for MP yet, but that's going to change soon... > 4) In what files do the proc and the u-area structures reside? > If you mean header files, they are and . > Thanks, > Andrew Miklic > -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lock-ups due to the scheduler
> There may be additional issues with the scheduler, though they may not > be related to the issue you have. Check www.freebsd.org/~dick/sched.descr > I was under the impression that Peter Dufault had re-assumed this matter, > but not much has happened on most of the issues. > Could you add the this problem to your list: p_rqindex does not encode which queue a process is on? Consider this scenario, we are lowering a process' priority from realtime to normal. This process is in runnable state on one of the run queues while another process is changing its p_rtprio, after it's done, a clock intr comes and the scheduler decides the process should go to another run queue, so it tries to remove process on the p_rqindex'th normal priority run queue and results in data corruption. When changing a process from one scheduling class to another, we should also move it to the apprioriate run queue (if it's in runnable state). When that's done, we will start getting reports about corrupted run queues... -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lock-ups due to the scheduler
> The deeper problem seems to be that for whatever the process does, it
> never accrues enough estcpu to classify it as hoggy, as a process I
> start with a niceness of -20 cycles through priorities 10 (in the
> very beginning) and 27 at the very highest. This _shouldn't_ be too
> much of a problem, but it never gets to 50 and thus never gets
> rescheduled properly... and this seems to be most of what's causing the
> lockups.
>
Even with max estcpu, the process will have a priority of PUSER - 4, which
puts it at least one run queue higher than all user mode processes, therefore
no user mode processes get a chance to run and the system is locked up.
> > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> > > NICE_WEIGHT * p->p_nice;
> > We should probably offset p->p_nice by PRIO_MIN,
> > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> > > NICE_WEIGHT * (p->p_nice - PRIO_MIN);
> >
> > To fully utilize the 20 out of 32 run queues for user priorities, we might
> > want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to
> > #define ESTCPULIM(e) \
> > min((e),
> > INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \
> > INVERSE_ESTCPU_WEIGHT - 1)
> > so that a cpu hog at nice 0 would have about the same priority as a low
> > cpu usage nice +20 process.
>
> Yes, this seems right. It seems that the niceness making the priority dip
> below 50 is a bad idea. I think that if we make that modification (which
> is another thing I tried) of niceness values subtracting PRIO_MIN to
> prevent any values less than PUSER, this would fix the bugs we have.
> I missed, when I did it, changing ESTCPULIM, so that probably explains
> why things didn't (I believe) lock up, but (I believe) seemed veerrry
> bad... Also, decreasing NICE_WEIGHT would be a good idea, so I'll try
> all of this out, and report later.
>
Would you try the patch below? I have shown it to Bruce and he approved
it in principle. If it solves your problem, I will probably commit it
sometime tomorrow.
-lq
Index: kern/kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.89
diff -u -r1.89 kern_synch.c
--- kern/kern_synch.c 2000/03/28 18:06:42 1.89
+++ kern/kern_synch.c 2000/04/27 20:01:19
@@ -916,7 +916,7 @@
if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
- NICE_WEIGHT * p->p_nice;
+ NICE_WEIGHT * (p->p_nice - PRIO_MIN);
newpriority = min(newpriority, MAXPRI);
p->p_usrpri = newpriority;
}
Index: sys/param.h
===
RCS file: /home/ncvs/src/sys/sys/param.h,v
retrieving revision 1.63
diff -u -r1.63 param.h
--- sys/param.h 2000/03/27 21:29:33 1.63
+++ sys/param.h 2000/04/27 19:19:59
@@ -111,7 +111,7 @@
#definePCONFIG 32
#definePLOCK 36
#definePPAUSE 40
-#definePUSER 50
+#definePUSER 46
#defineMAXPRI 127 /* Priorities range from 0 through MAXPRI. */
#definePRIMASK 0x0ff
Index: sys/proc.h
===
RCS file: /home/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.102
diff -u -r1.102 proc.h
--- sys/proc.h 2000/04/16 18:53:29 1.102
+++ sys/proc.h 2000/04/27 14:33:23
@@ -405,10 +405,10 @@
* the range 100-256 Hz (approximately).
*/
#defineESTCPULIM(e) \
-min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_MAX - PPQ) + \
+min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN)) + \
INVERSE_ESTCPU_WEIGHT - 1)
#defineINVERSE_ESTCPU_WEIGHT 8 /* 1 / (priorities per estcpu level) */
-#defineNICE_WEIGHT 2 /* priorities per nice level */
+#defineNICE_WEIGHT 1 /* priorities per nice level */
#definePPQ (128 / NQS) /* priorities per queue */
extern u_long ps_arg_cache_limit;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: lock-ups due to the scheduler
This is quite interesting. I'm no scheduler expert, but my understanding
is priority < PUSER won't degrade and is only set in kernel mode after
waking up from a sleep. In user mode, processes should always have priority
p_usrpri >= PUSER, it is obviously not true for a negative nice value:
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * p->p_nice;
We should probably offset p->p_nice by PRIO_MIN,
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * (p->p_nice - PRIO_MIN);
To fully utilize the 20 out of 32 run queues for user priorities, we might
want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to
#define ESTCPULIM(e) \
min((e),
INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \
INVERSE_ESTCPU_WEIGHT - 1)
so that a cpu hog at nice 0 would have about the same priority as a low
cpu usage nice +20 process.
-lq
> I dropped hints that there may be issues about 3 weeks ago, as my machine
> had locked up for apparently no reason, and I had no idea why until
> recently. It seems that it has everything to do with running things that
> use lots of CPU at a very high priority (I use -20).
>
> I've been struggling for a few days with this... and what happens is that
> the kernel never executes any user processes (or does so so very rarely
> that I really can't detect it at all, in any application, the execution).
>
> I'm not really sure what's happening, but it definitely is with the
> scheduler: if I cap the scheduler's priority computation on the lower
> end to keep user processes from not executing with a p_priority < PUSER,
> the system can get slightly unresponsive, but it does not lock up.
> The modifications I made to allow prevention of this follow my signature.
>
> This is a deadlock-type situation, and I can reproduce it at will, so I'll
> try to explain the steps I can reproduce it with.
>
> 1. start XMMS at -20 priority, and play something
> 2. XMMS is decoding audio and other random things, nothing huge, but at
>about 15-20% CPU. XMMS sends decoded mp3 (archives of CDs I own) to
>the EsounD daemon (esd), which takes 2-3% cpu or so, and XFree86
>itself takes a good 5-10% cpu.
> 3. Start a "Visualization" plugin, which basically takes XMMS to full
>CPU usage (as much as it can get), and things lock up. XMMS is the
>curproc for every single time I've polled it (using DDB, for example),
>and I stop hearing audio. XFree86 would be doing the X11 servering,
>and esd would mostly be writing to the audio device or reading from its
>socket, so usually in PRIBIO or PSOCK.
>
> At this point, the system is really locked up, and there's nothing I can
> do. I can, however, get a coredump and have the entire system state at
> this point. I'm certain that that other people here will be able to try
> the same tests, of course on 5.0-CURRENT, and possibly reproduce them
> exactly the same as it happens for me. I can grovel in a coredump to
> get information about the system as it was running at the time, so if
> anyone can provide hints as to where to check for what happened that
> makes things lock up nowadays, I'll be grateful, and I'll be able to
> try almost anything to get this fixed.
>
> If you're familiar with the scheduler area of the system, please help.
> I have noone's arm to twist or anything of the sort, so I'm really
> going out on a limb hoping someone will be able to try to help me fix
> this. Note that I've taken my HZ=1000 line out of my kernel config,
> so I'm running at a standard hz = 100 and a kern.quantum of 2.
>
> --
> Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> [EMAIL PROTECTED]`--'
>
> Index: kern_synch.c
> ===
> RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.89
> diff -u -u -r1.89 kern_synch.c
> --- kern_synch.c 2000/03/28 18:06:42 1.89
> +++ kern_synch.c 2000/04/27 00:55:21
> @@ -903,6 +903,10 @@
> maybe_resched(p);
> }
>
> +static int priority_lower_cap = 0;
> +SYSCTL_INT(_debug, OID_AUTO, enable_priority_lower_cap, CTLFLAG_RW,
> + &priority_lower_cap, 0, "");
> +
> /*
> * Compute the priority of a process when running in user mode.
> * Arrange to reschedule if the resulting priority is better
> @@ -917,6 +921,12 @@
> if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
> newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> NICE_WEIGHT * p->p_nice;
> + if (priority_lower_cap && newpriority < PUSER) {
> + if (p == curproc)
> + uprintf("kernel: tried to use priority %d\n",
> + newpriority);
> + newpriority = PUSER;
> +
Yahoo under attack
Just saw it in the news, http://abcnews.go.com/sections/tech/DailyNews/yahoo000207.html Does anyone know the detail? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
> I think it is difficult to implement such conversion because: > > - Not only bus space stuff also resource manager stuff need to > perform such conversion. Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be opaque types. Resource manager needs not know the implementation details. > - The type of the bus_space_handle_t can by determined only by the > bus tag. The isa_alloc_resourcev (new function) cannot modify bus > tag because what it does is only to allocate resources and it > cannot register the address to the bus_space_handle_pc98. But > allocated resources must be stored into bus_space_handle_pc98. > We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and return a fake resource record, in which we store I386_BUS_PIO_IND as bus tag and address of bus_space_handle_pc98 as bus handle. And in isa_release_resource(), we first release the underlying resources stored in the bus_space_handle_pc98 record and then free the fake resource record itself. It should be safe as long as we don't manipulate this resource by direct resource manager calls, which we shouldn't do anyway. (or we should implement it at the root bus level, if pci devices in pc98 systems also use discrete port addresses). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
> > Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
> > able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.
>
> Because they are different in the type of bus_space_tag_t from each
> other. It is the u_long in PC/AT and the structure in PC-98. For
> example, bus_space_read_1()s of them are:
>
> PC/AT:
> bus_space_read_1(...)
> {
> ...
> return (inb(handle + offset));
> ...
> }
>
> PC-98:
> bus_space_read_1(...)
> {
> ...
> return (inb(bsh.bsh_iat[offset]));
> ...
> }
>
You could set the handle to point to the structure instead:
bus_space_read_1(...)
{
if (tag == I386_BUS_PIO) {
return (inb(handle + offset));
} else if (tag == I386_BUS_PIO_IND) {
struct bus_space_handle_pc98 *bsh = handle;
return (inb(bsh->bsh_iat[offset]));
} else if (tag == I386_BUS_MEMIO) {
...
}
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
> Do you have any comment anout the patch? If there isn't any big > problem, I hope to commit it to current. > > Thank you. > > > I wrote: > > Do you remember this topic? I have revised the indirection support > > patch. What I have changed are: > > - to make diff files more readable > > - introduce the bus_simple_create_bsh() that creates > > a bus_space_handle_tag from a base address. > > > We shouldn't need bus_simple_create_bsh(). All drivers ought to use rman_get_bushandle()/rman_get_bustag() to retrieve the bus handle and tag, and use them in bus_space_read/write calls to perform device io. Drivers that don't do that should be fixed. Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing user data from kernel
> When the kernel wants to access any user data, it either copies them into > the kernel or maps them into kernel address space. Can anyone tell me the > reasons why this is done? When a process enters the kernel mode, the > page tables are not changed. > > I have taken this for granted for a long time without knowing the reasons. > > Thanks, > > -Zhihui > In theory, the kernel and user address spaces are separate. But in practice, for performance reasons, the kernel address space is always mapped at the top of user address space, so the kernel can directly access the current process' address space (copyin/copyout are just normal bcopy with bound check and guard against page fault). Under certain circumstances, you might want them to be truely separate, for example, if you have to use the full 4G in a user process, the tradeoff of course is the user/kernel context switch overhead. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
> > Matthew Dillon <[EMAIL PROTECTED]> wrote: > > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > > > :following simple program is coredumping: > > > You cannot call rfork() with RFMEM directly from a C program. You > > > have to use assembly (has anyone created a native clone() call yet > > > to do all the hard work?). > > OK, I'd like to propose another option to rfork to make it a little more > usable for mortals. The option is RFSTACK. This will cause rfork to work > like my original version, in that the stack segment (all memory from > USERSTACK and up) will be cloned. > > This would really make a big improvement in rfork usability. > > Comments? > > ron > It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Post a signal within an interrupt handler
> While reading the code vfs_aio.c, I find out some comments saying it is > not safe to post a signal from the interrupt handler aio_physwakeup(). So > it calls timeout(9) within that handler and let the timeout routine to > post the signal. I do not understand this. Isn't the timeout mechanism > also driven by an interrupt (clock)? > > Any enlightment is appreciated. > > -Zhihui > AFAIK it is safe to post a signal in an interrupt context. Maybe it has more to do with reducing interrupt latency than safety. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-4.0 on SMP
> Hi,
> I have a 4-processor machine but I want to configure FreeBSD-4.0
> to only use 1 of the processors for some tests. In addition I want the
> local APIC to be enabled. It seems currently that the APIC is only enabled
> when the kernel is compiled with the SMP option. However, when I specify
> NCPU to be 1, the kernel panics. So the question is - is there a way to
> just use one processor and still keep the APIC enabled ?
>
>
>
> - Mohit
>
Try again with the following patch,
Index: i386/mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.112
diff -u -r1.112 mp_machdep.c
--- i386/mp_machdep.c 1999/11/27 12:32:20 1.112
+++ i386/mp_machdep.c 2000/01/05 08:28:40
@@ -1097,7 +1097,7 @@
processor_entry(proc_entry_ptr entry, int cpu)
{
/* check for usability */
- if ((cpu >= NCPU) || !(entry->cpu_flags & PROCENTRY_FLAG_EN))
+ if (!(entry->cpu_flags & PROCENTRY_FLAG_EN))
return 0;
/* check for BSP flag */
@@ -1109,11 +1109,13 @@
}
/* add another AP to list, if less than max number of CPUs */
- else {
+ else if (cpu < NCPU) {
CPU_TO_ID(cpu) = entry->apic_id;
ID_TO_CPU(entry->apic_id) = cpu;
return 1;
}
+
+ return 0;
}
Index: include/mpapic.h
===
RCS file: /home/ncvs/src/sys/i386/include/mpapic.h,v
retrieving revision 1.12
diff -u -r1.12 mpapic.h
--- include/mpapic.h1999/08/28 00:44:19 1.12
+++ include/mpapic.h2000/01/05 08:24:58
@@ -98,6 +98,8 @@
static __inline int
all_but_self_ipi(int vector)
{
+ if (mp_ncpus <= 1)
+ return 0;
return apic_ipi(APIC_DEST_ALLESELF, vector, APIC_DELMODE_FIXED);
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-i386 and GS selector register
> Hi > > I have the next question. > The FreeBSD on i386 don't use GS register, even kernel DDB don't show > it. And at the time when kernel loaded and operational GS didn't > initialized yet and have some garbage value (something like 0x1f, i.e. > pointed to the LDT). But because no one don't touch that all working fine. > 0x1f is not garbage, it's (FreeBSD) standard user data segment. > Question. > The some driver had code like this: > push%gs <--- OK 0x1f saved on the stack > ... > calldo_big_deal > ... > pop %gs <--- Restore 0x1f and have a fault, probably Double Fault > It could only be that the driver code changed the LDT descriptor and didn't restore it upon return. > I can't change that code. When I found this problem, I did simple hack, > before call that code I'm clear GS. But I want to know may be exist > a better solution? > > -- > Vladimir Silyaev > -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is part of user stack always mapped?
> I was under the impression that this was a no-no & one should use > copyin/copout & friends to access memory on users's stacks. Although > this appears to work on the i386, if I try this on the alpha I take a > fatal trap when accessing *set. > > So -- how does this work on the i386? Is the user's stack always > mappeped into the kernel's address space? Should it also work on the > alpha? > On i386, under the current implementation, the kernel can directly access curproc's address space (not just the stack, stack is used because we're sure the spare space won't/shouldn't be used by the user application). I don't know if the same is true for alpha, but this should definitely be considered an implementation dependent feature. I wish there were some other ways to bypass copyin/out in ioctls. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Granularity of disk I/O
> :Thanks. It seems to me that for a filesystem, a block (or a fragment) is > :the unit of I/O. Even if a single byte is modified, an entire block > :probably consisting of multiple sectors must be written back to the disk. > :As you said, there is no differnce whether we write this block one sector > :at a time or in a single transfer. If so, I wonder whether the atomicity > :of a sector I/O required by a directory file is necessary any more. > : > :-Zhihui > > The directory blocking is there for a different reason. Atomicy does not > have much to do with it though perhaps it did at some point in the past. > I think atomicity is still the reason. The basic block size of a directory is still a 512-byte sector, and chances are we might write directory blocks one sector at a time (4k/512 formatted fs), so we have to guarantee directory entries don't cross the 512-byte sector boundary. On a 8k/1k fs, you probably could get away with crossing the odd 512-byte sector boundary though. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read kills machine
> I am working on a small threaded program > that uses aio_read(). In my first attempt > to run the program it killed my machine > instantly. The second time it only locked > it solid. I get no messages, warnings, or > errors. > > I am certain that my program is not correct > (besides the obvious consiquence of running > it :) ), but I would also like to determine > why it kills the machine. I was not root > either time I ran the code. > > I could provide additional debugging information, > and the source to anybody who cares about this. > I am not sure up front what would be helpful. > > The machine is a dual 400 with 512Mg ram, running > 3.3-stable as of Sept 28 with SMP enabled. > > Thanks in advance. > > Chad > [EMAIL PROTECTED] > You need to go to -current for this. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: zalloci/pv_entry problem (Was: Weird sockname errors with -current and apache)
> Well I FINALLY got one of my crashing CGI machines to drop into > the debugger, and the results were interesting. I'm not a DDB expert, but > I tried to get some relevant info. I think the following is the most > interesting: > > db> trace > zalloci(c02698c0,deb59e58,c01f24c3,dd196964,8752000) at zalloci+0x33 > get_pv_entry(dd196964,8752000,ffc21d48,0,deb59e90) at get_pv_entry+0x4a > pmap_insert_entry(dd196964,8752000,c08952d0,77cb000) at > pmap_insert_entry+0x1f > pmap_copy(dd196964,de0ec264,80c6000,1d7e000,80c6000) at pmap_copy+0x1a0 > vm_map_copy_entry(de0ec200,dd196900,dd31aac8,de780208) at > vm_map_copy_entry+0xdf > vmspace_fork(de0ec200,dd191840,dd191840,bfbfddbc,deb59f30) at > vmspace_fork+0x1d3 > vm_fork(de09f080,dd191840,14) at vm_fork+0x2f > fork1(de09f080,14,deb59f48,de09f080,9) at fork1+0x621 > fork(de09f080,deb59f80,805b36c,30,bfbfddbc) at fork+0x16 > syscall(bfbf002f,bfbf002f,bfbf002f,bfbfddbc,30) at syscall+0x19e > Xint0x80_syscall() at Xint0x80_syscall+0x31 > > The full output of what I got is available at > http://doug.simplenet.com/DDB1.txt. > If you have a crash dump, could you look at the 4 longwords starting at address 0xc02698c0? It seemed to be an accouting problem. Do you by any chance use any kld module? zalloc() calls from within a module do not lock the vm_zone data structure, which is fine for UP but dangerous for SMP. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
> The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. > > Any help is appreciated. > > -- > Zhihui Zhang. Please visit http://www.freebsd.org > -- > It is created almost exclusively for fsck (and similar programs) to update the in core image of the superblock (of / in single user mode) after the on disk version has been modified. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
> The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. > > Any help is appreciated. > > -- > Zhihui Zhang. Please visit http://www.freebsd.org > -- > It is created almost exclusively for fsck (and similar programs) to update the in core image of the superblock (of / in single user mode) after the on disk version has been modified. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
> If you boot single-user, root will be mounted read-only and you should > be able to 'tunefs -n enable /dev/rda0a' and reboot. > > -Matt > Matthew Dillon > > It's a little bit simpler than that: in single user mode, tunefs -n enable / no reboot is necessary (tunefs reloads the fs after it makes changes on disk). -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
> If you boot single-user, root will be mounted read-only and you should > be able to 'tunefs -n enable /dev/rda0a' and reboot. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > It's a little bit simpler than that: in single user mode, tunefs -n enable / no reboot is necessary (tunefs reloads the fs after it makes changes on disk). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repeatable kernel panic for 3.2-RELEASE NFS server
> Is there anything I can do on my end (we have a complete CVS repository, > synced every 4 hours. I would like to use the *exact* same gdb that we > compiled the world from if possible, I am affraid of using a more recent > gdb will result in not being able to read the core (I am unable to use > a 3.1-STABLE gdb to read the core from a 3.2-STABLE system). > > -- > David Cross | email: cro...@cs.rpi.edu > Systems Administrator/Research Programmer | Web: > http://www.cs.rpi.edu/~crossd > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science| Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > I just backed out changes I made that shouldn't be in the 3.x branch, you may cvsup again. If you can't wait, you may back out the changes yourself, they are -j1.16 -j1.15 /usr/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c, -j1.20 -j1.19 /usr/src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c (cvs update -j doesn't seem to work, I had to get the diff and patch myself). -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Repeatable kernel panic for 3.2-RELEASE NFS server
> I have tried gdb from 3.2-BETA, 3.2-RELEASE, and 3.2-STABLE, as well as the > gdb that was built from the exact same CVS checkout as the kernel owas from, > they all give the same error. > > -- > David Cross | email: cro...@cs.rpi.edu > Systems Administrator/Research Programmer | Web: > http://www.cs.rpi.edu/~crossd > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science| Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > Some of the gdb source files were incorrectly tagged for 3.2 branch, I'll fix it. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Repeatable kernel panic for 3.2-RELEASE NFS server
> gdb -k kernel.1 vmcore.1 > 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"... > (no debugging symbols found)... > IdlePTD 2998272 > > kernel symbol `gd_curpcb' not found. > (kgdb) > > Any ideas? > You need to use gdb comes with 3.2-RELEASE. > -- > David Cross | email: cro...@cs.rpi.edu > Systems Administrator/Research Programmer | Web: > http://www.cs.rpi.edu/~crossd > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science| Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD native xanim (was Re: Native Applixware for FreeBSD -- When? )
> > On a related note, I don't know if people use xanim, a movie viewer in
> > the ports collection, but it's recently been upgraded to support
> > dynamically loadable codecs. The problem is that none of the codecs
> > are compiled for FreeBSD, although there are three Linux versions :-).
> > To use them (really to use the program at all) you have to compile a
> > Linux version of xanim and run under emulation (which works really well,
> > thanks
> > emulation guys!).
> >
> > Yes, I've tried using the Linux codecs on the FreeBSD binary. No dice.
> >
> > The author is perfectly willing to compile these codecs for FreeBSD,
> > but because he's under NDA for the codecs he can only release compiled
> > versions. He's only willing to compile versions for other OSes under
> > Linux (i.e. compile the codecs for FreeBSD on his Linux machine) or on
> > a donated machine. (His reasoning for this, which IMHO is rational,
> > is on http://xanim.va.pubnix.com/xa_dlls.html )
> >
> > Given that he's running Linux, is a "cross-compiling environment" any
> > more complex than having him link against our libc? If not can
> > someone give me an idea what he does need.
> >
> > I'm delighted to act as a contact point and a tester for the xanim
> > author, but I just don't know enough about our link environment.
> >
> > Anyone want to enlighten me? (I tried this on multimedia, and got no
> > response).
> >
> > - --
> > Ted Faberfa...@isi.edu
> > USC/ISI Computer Scientist http://www.isi.edu/~faber
> > (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc
> >
> The only reason some of the linux codecs are not useable on FreeBSD is
> the reference of symbol __IO_stderr, it should be quite easy to convert
> them to references to &__sF[2].
>
> -lq
>
Compile this little program, use it to process the linux .xa files, and they
should be useable on FreeBSD.
-lq
#include
#include
#include
#include
#include
#include
main(int argc, char **argv)
{
int fd, i;
void *addr;
Elf_Ehdr *eh;
Elf_Phdr *ph;
Elf_Dyn *ed;
Elf_Rel *reltab, *er;
Elf_Sym *symtab;
char *strtab, *name;
int relsz, relent;
struct stat stb;
if (argc < 2)
exit(1);
fd = open(argv[1], O_RDWR);
if (fd < 0)
err(1, "%s", argv[1]);
if (fstat(fd, &stb) < 0) {
close(fd);
err(-1, "fstat: %s", argv[1]);
}
addr = mmap(0, stb.st_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);
if ((int)addr == -1)
err(-1, "mmap");
eh = (Elf_Ehdr *)addr;
if (!IS_ELF(*eh))
err(1, "%s: not an ELF file", argv[1]);
ph = (Elf_Phdr *)((unsigned)addr + eh->e_phoff);
for (i = 0; i < eh->e_phnum; i++, ph++) {
if (ph->p_type == PT_DYNAMIC)
break;
}
if (i >= eh->e_phnum)
err(-1, "no dynamic section");
ed = (Elf_Dyn *)((unsigned)addr + ph->p_offset);
for (; ed->d_tag != DT_NULL; ed++) {
if (ed->d_tag == DT_STRTAB)
strtab = (char *)((unsigned)addr + ed->d_un.d_val);
if (ed->d_tag == DT_SYMTAB)
symtab = (Elf_Sym *)((unsigned)addr + ed->d_un.d_val);
if (ed->d_tag == DT_REL)
reltab = (Elf_Rel *)((unsigned)addr + ed->d_un.d_val);
if (ed->d_tag == DT_RELSZ)
relsz = ed->d_un.d_val;
if (ed->d_tag == DT_RELENT)
relent = ed->d_un.d_val;
}
for (i = 0, er = reltab; i < relsz / relent; i++, er++) {
name = &strtab[symtab[ELF_R_SYM(er->r_info)].st_name];
if (strcmp("_IO_stderr_", name))
continue;
strcpy(name, "__sF");
*(unsigned long *)((unsigned)addr + er->r_offset) +=
(unsigned)stderr - (unsigned)stdin;
}
munmap(addr, stb.st_size);
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD native xanim (was Re: Native Applixware for FreeBSD -- When? )
> On a related note, I don't know if people use xanim, a movie viewer in > the ports collection, but it's recently been upgraded to support > dynamically loadable codecs. The problem is that none of the codecs > are compiled for FreeBSD, although there are three Linux versions :-). > To use them (really to use the program at all) you have to compile a > Linux version of xanim and run under emulation (which works really well, > thanks > emulation guys!). > > Yes, I've tried using the Linux codecs on the FreeBSD binary. No dice. > > The author is perfectly willing to compile these codecs for FreeBSD, > but because he's under NDA for the codecs he can only release compiled > versions. He's only willing to compile versions for other OSes under > Linux (i.e. compile the codecs for FreeBSD on his Linux machine) or on > a donated machine. (His reasoning for this, which IMHO is rational, > is on http://xanim.va.pubnix.com/xa_dlls.html ) > > Given that he's running Linux, is a "cross-compiling environment" any > more complex than having him link against our libc? If not can > someone give me an idea what he does need. > > I'm delighted to act as a contact point and a tester for the xanim > author, but I just don't know enough about our link environment. > > Anyone want to enlighten me? (I tried this on multimedia, and got no > response). > > - -- > Ted Faberfa...@isi.edu > USC/ISI Computer Scientist http://www.isi.edu/~faber > (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc > The only reason some of the linux codecs are not useable on FreeBSD is the reference of symbol __IO_stderr, it should be quite easy to convert them to references to &__sF[2]. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
