Re: which function
In the last episode (May 22), Maslan said: > what and where is the function that is responsible for printing the > bsd logo on startup? sorry for than question but i'm a new in hacking > the bsd and my time is very limited. If you're talking about the ascii-art before the kernel loads, you can disable it by putting "beastie_disable=yes" in /boot/loader.conf. The code that actually prints it is in /boot/beastie.4th . -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI Device Driver
ok, thanks the advise. On Fri, 2005-05-20 at 06:12 -0700, Julian Elischer wrote: > Scott Long wrote: > > Luís Vitório Cargnini wrote: > > > >> Hi i need to write a device driver for a PCI board. I read the > >> developers book see the exemples and i'm starting to write the device > >> driver. I'm writeing a device driver for a board with SAA713X TV chipset > >> from Phillips. I did theskeleton example, but whe i catch the example of > >> PCI driver from developers book and tried to compilate i receive the > >> following: > >> (forgive me for the long paste, but i need some answers and i need to > >> give the details) > >> > >> > >> PASTE of ERORS: > > > > > > Yes, the skeleton driver is very out of date. Would anyone object > > to me updating it and tossing out the ISA code? > > sure go ahead (this is /usr/share/examples/drivers right? > > Warner said recently that he was going ot update it after he had > finished some changes to the bus code, so check with him too. > > > > > Scott > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Porting on FreeBSD 53
[severely trimmed] On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote: > On Fri, 13 May 2005, Hervé Kergourlay wrote: >> Seán C. Farley a écrit : >>> On Thu, 12 May 2005, Seán C. Farley wrote: On Thu, 12 May 2005, Hervé Kergourlay wrote: > 4) wait() API > > 2 problems, the first is a ECHILD error on a wait call after a fork > fork The code is generic for most of unix system. Is there any > specific problems to manage the fork and wait APIs ? the second > problem with calls is a blocking wait() call in the same condition > but this time the son process is finished but the wait call in the > father stays blocked, again it's a generic Unix code > > If there is no evidence, ask me for more informations The second problem sounds like what I am encountering (http://www.freebsd.org/cgi/query-pr.cgi?pr=77818) with zsh for my shell. You did suspend (sigsuspend()) SIGCHLD before the fork? By >>> >>> >>> Ah ha! I see the problem that has been causing me this problem and >>> probably you too. Signal suspensions (only these?) are not being >>> copied with a double fork(). Here is an example program[1] to >>> illustrate. They do get copied on FreeBSD-4.10 and Linux. I just do >>> not know if they are supposed to be copied. >> >> I test your sample >> >> it's working on Linux and FreeBSD 4.0 but failing on FreeBDS 5.2 et >> 5.3. the process stays blocked on the suspend call >> >> I rewrite another sample with the same model, joined here, as we wrote >> it in our main program. It's working also on Linux but failing on all >> FreeBSD included FreeBSD 4.0, 5.2 et 5.3 >> >> ... >> >> the wait call return with an errno ECHILD ?? > > The children are exiting before the parents (due to sleep()'s) get to > their wait()'s. > >> did you have any idea if the problem will be solve by the FreeBSD team >> or not ? > > I updated my bug report and tried to notify David Xu but the e-mail > server rejected the e-mail (too many "Received" headers). I am also > Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in > February. Now that I've had time to look at it, both problems appear to be related to signals, but that's about as far as it goes. I wouldn't expect any connection unless it's a general signal race condition. Greg -- See complete headers for address and phone numbers. pgpzBmvixO1u4.pgp Description: PGP signature
Re: PCI Device Driver
Thanks for all answers, i'm still working, but i founded some problems like: Peter Jeremy: Thansk by the links, but hte author is not only generating a kernel device driver, ant they're sources i don't looked wheel but have some changes to be made, second the author put the pci*.h on they're sources, but the sources have this files why it's not installing it ??? like others .h ?? this is the problems of @/sys/bus.h:455:23: device_if.h: No such file or directory i have received an answer about using "config MYKERNEL ..." the old method to compile your kernel, i'm not tested at all, i'll try i promisse, but as i said bsd has a minor problem, or look have, because the author in the link sof Peter needed to put the headers on sources dir. i'll still working on it i'll publish the future work results and Peter i contacted the drivers by mail, i promisse put the conversation result on list. For now thanks for all and if someone find an explanation of why i having problems with pci headers please advise me, thanks for all. On Fri, 2005-05-20 at 00:23 -0300, Luís Vitório Cargnini wrote: > Hi i need to write a device driver for a PCI board. I read the ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI Device Driver
BTW, thanks for the link i'll try this On Fri, 2005-05-20 at 18:28 +1000, Peter Jeremy wrote: > On Fri, 2005-May-20 00:23:46 -0300, Luís Vitório Cargnini wrote: > >driver. I'm writeing a device driver for a board with SAA713X TV chipset > >from Phillips. > > Before expending too much effort on this, you might like to study > http://www.purpe.com/download/ > > BTW, where did you find programming information for the 713x? > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: snapshots and innds
[ OK, there's a lot of text in here, but I have definitively found a deadlock between ffs_mksnap and msync(). ] Waaay back on Dec 18, 17:39, I wrote: } Subject: snapshots and innds } I'm getting a strong hunch that snapshots and inn don't get along } well, presumably having something to do with inn's extensive use } of mmap(). } } Just for an example, my system panic()ed earlier today (different } problem) and during the reboot, I'm stuck with an fsck_ufs on wchan } "ufs" and innd on wchan "suspfs", and neither of them responding } in any way. And I have been seeing hangs periodically since December that all seem to implicate innd(msync()) arguing with dump(mksnap_ffs). The system is 5.4-STABLE, updated last on the (PDT) morning of 2 May. Finally, this morning, I got a kernel core dump that I can do useful stuff with. The system was mostly operating normally, except that any attempt to access the /news partition (which has articles, tradspool.map, overviews, and incoming/outgoing data) would get stuck in "suspfs". So I forced a dump from ddb. The mount point does (as one would expect) have MNTK_SUSPEND set. I see mksnap_ffs sitting waiting for "ufs" (really vnode 0xc19af318), which it got to via: (kgdb) info stack #0 sched_switch (td=0xc1ede780, newtd=0xc146f480, flags=1) at /usr/src/sys/kern/sched_4bsd.c:882 #1 0xc0662ad0 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:355 #2 0xc067a9e4 in sleepq_switch (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:406 #3 0xc067ab9e in sleepq_wait (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:518 #4 0xc06627b6 in msleep (ident=0xc19af3c4, mtx=0xc095e4cc, priority=80, wmesg=0xc08a3f13 "ufs", timo=0) at /usr/src/sys/kern/kern_synch.c:228 #5 0xc06505d6 in acquire (lkpp=0xd02df680, extflags=16777280, wanted=1536) at /usr/src/sys/kern/kern_lock.c:161 #6 0xc0650a14 in lockmgr (lkp=0xc19af3c4, flags=16842754, interlkp=0x0, td=0xc1ede780) at /usr/src/sys/kern/kern_lock.c:389 #7 0xc07bd6e3 in ufs_lock (ap=0xd02df6bc) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2007 #8 0xc07be380 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2828 #9 0xc06c0501 in vn_lock (vp=0xc19af318, flags=65538, td=0xc1ede780) at vnode_if.h:1013 #10 0xc06b4195 in vget (vp=0xc19af318, flags=65538, td=0x0) at /usr/src/sys/kern/vfs_subr.c:2028 #11 0xc07af408 in ffs_sync (mp=0xc15e5c00, waitfor=1, cred=0xc2953080, td=0xc1ede780) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1151 #12 0xc06c0840 in vfs_write_suspend (mp=0xc15e5c00) at /usr/src/sys/kern/vfs_vnops.c:1084 #13 0xc079db18 in ffs_snapshot (mp=0xc15e5c00, snapfile=0xbfbfef1b ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:317 #14 0xc07ad5d8 in ffs_omount (mp=0xc15e5c00, path=0xc2a8c380 "/news", data=0x0, td=0xc1ede780) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:313 #15 0xc06af787 in vfs_domount (td=0xc1ede780, fstype=0xc1eea730 "ffs", fspath=0xc2a8c380 "/news", fsflags=18944000, fsdata=0xbfbfe7d4, compat=1) at /usr/src/sys/kern/vfs_mount.c:861 #16 0xc06aef16 in mount (td=0x0, uap=0xd02dfd04) at /usr/src/sys/kern/vfs_mount.c:620 #17 0xc0828553 in syscall (frame= [ snip ] And inn is sitting waiting for the suspended filesystem: (kgdb) info stack #0 sched_switch (td=0xc1c16c00, newtd=0xc1ede780, flags=1) at /usr/src/sys/kern/sched_4bsd.c:882 #1 0xc0662ad0 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:355 #2 0xc067a9e4 in sleepq_switch (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:406 #3 0xc067ab9e in sleepq_wait (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:518 #4 0xc06627b6 in msleep (ident=0xc15e5c6c, mtx=0x0, priority=159, wmesg=0xc08a5c44 "suspfs", timo=0) at /usr/src/sys/kern/kern_synch.c:228 #5 0xc06c06b8 in vn_start_write (vp=0x0, mpp=0xc15e5c00, flags=1) at /usr/src/sys/kern/vfs_vnops.c:995 #6 0xc07daeb4 in vnode_pager_putpages (object=0xc1990b58, m=0x0, count=4096, sync=12, rtvals=0x0) at /usr/src/sys/vm/vnode_pager.c:969 #7 0xc07d2f42 in vm_pageout_flush (mc=0xd022bac0, count=1, flags=12) at vm_pager.h:147 #8 0xc07cd84b in vm_object_page_collect_flush (object=0xc1990b58, p=0xc10ddc40, curgeneration=1, pagerflags=12) at /usr/src/sys/vm/vm_object.c:958 #9 0xc07cd2a3 in vm_object_page_clean (object=0xc1990b58, start=628, end=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_object.c:761 #10 0xc07cda77 in vm_object_sync (object=0xc1990b58, offset=2572288, size=4096, syncio=0, invalidate=0) at /usr/src/sys/vm/vm_object.c:1026 #11 0xc07c9267 in vm_map_sync (map=0xc147a384, start=676794368, end=676798464, syncio=0, invalidate=0) at /usr/src/sys/vm/vm_map.c:2149 #12 0xc07cb4e1 in msync (td=0x0, uap=0x0) at /usr/src/sys/vm/vm_mmap.c:465 #13 0xc0828553 in syscall (frame= [ snip ] (Interesting kgdb buglet on line 9 of that trace, by the way.) Based on a bit more snooping, it's a basic deadlock. The sync() is trying to lock the vnode at 0xc19af318. That vnode
Re: Determine location of LD_PRELOAD'ed shared libraries/functions.
Marcin wrote: Hello Hackers, I'd like to find locations of functions exported by shared lib loaded into the running ptrace'd process via LD_PRELOAD. I want do determine this from tracing process. For shared libraries linked with a program i can just open the program file and search for relocation sections, which eventually point to the plt function entries. My problem is that i cannot figure out how to start searching for symbols which are loaded with LD_PRELOAD. I can see where the library is mapped in /proc/*/map (isn't there a better, less freebsd-specific place to search for this info?) but I'm not quite sure how to interpret the mmapped pages. Searching Elf doc's just makes me run in circles; usually the LD_PRELOAD option is just mentioned as it was obvious; I't isn't quite. Sections describing program memory image are in program file. LD_PRELOAD'ed lib is only in the memory, to which programs sections do not apply. Libraries sections can't know to what address they will be mmapped to, so where to search? Program has relocation entries, but there is no spare space there for something unexpected like LD_PRELOADed library (?) Please point me to right direction, because i've got only one idea left: grep dynamic loader for LD_PRELOAD ;). I think you will need to use the linkmap created by rtld. I guess you need the address of the dynamic linker to find it, I've only ever done this on core dumps before. Its in r_debug.r_map in rtld's bss, a linked list of link_map structures. This tells you the filename and relocation address of what was actually loaded into memory, regardless of what the binary says (which may be modified with libmap, etc). Jake ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with new the "contigmalloc" routine
On Sunday 22 May 2005 18:06, Scott Long wrote:
> >
> > When I worked with USB I ran into some synchronization problems with
> > callbacks that leaded me to writing to the stack of another thread, which
> > I hope is OK.
>
> No, it's not ok. Kernel stacks can be swapped out while sleeping.
> Writing to a swapped out stack will cause a VM panic.
OK, maybe I have to create a bitmap in "struct thread" where I can store that
information, though that will limit the maximum number of context exits to a
constant.
And then change things a little bit. I assume that "curthread" points to the
currently active thread and is always set? But the principle will be exactly
the same. Please read through my previous e-mail and the function below
again!
#define CONTEXT_MAX (8*8)
struct thread
{
...
u_int8_t context_index;
u_int8_t context_bitmap[(CONTEXT_MAX+7)/8];
...
};
struct context
{
struct mtx *mtx;
u_int8_t *done_p;
u_int8_t done_index;
};
void
callback_thread():
{
retry:
#define max_callback 16
#if (max_callback >= CONTEXT_MAX)
#error "out of contexts"
#endif
struct callback * callbacks[max_callback];
struct mtx * mtxs[max_callback];
int x = 0;
int repeat = 0;
int retry = 0;
u_int8_t index = curthread->context_index;
if(index >= (CONTEXT_MAX - max_callback))
{
panic("out of contexts\n");
}
mtx_lock(&global_callback_lock);
while(1)
{
callbacks[x] = GET_NEXT_CALLBACK();
if(callbacks[x] == NULL)
{
break;
}
if(callbacks[x]->ctx.done_p)
{
/* another thread is calling callback
* ERROR
*/
continue;
}
/* clear bit */
curthread->context_bitmap[index / 8] &= ~(1 << (index % 8));
callbacks[x]->ctx.done_p = &curthread->context_bitmap[0];
callbacks[x]->ctx.done_index = index;
mtxs[x] = callbacks[x]->ctx.mtx;
x++;
index++;
if(x == max_callback)
{
retry = 1;
break;
}
}
curthread->context_index = index;
mtx_unlock(&global_callback_lock);
/* here one needs to switch lock to avoid
* locking order reversal
*/
while(x--)
{
/* do you see the point in storing a pointer to the
* mutex on the stack ?
* The callback structure might have been freed when one
* gets here and needs a copy !
*/
mtx_lock(mtxs[x]);
/* do you see the point in checking the bit below?
* It is supposed to get set if this callback has been
* stopped during the lock switch!
*/
if(!(curthread->context_bitmap[index / 8] & (1<<(index % 8
{
callbacks[x]->ctx.done_p = NULL;
(callbacks[x]->func)(callbacks[x]->arg, &callback[x]->ctx);
}
/* else callback stopped */
mtx_unlock(mtxs[x]);
/* free up bits used */
index--;
curthread->context_index--;
}
if(retry)
{
retry = 0;
goto retry;
}
}
>
> > What do you think about the following:
>
> [...]
>
> > I hope this wasn't too much for you to read :-)
> >
> > Any comments ?
> >
>
> I'm not too familiar with the exact problem you're trying to solve in
> USB. I guess you need to be able to allocate a contiguous chunk of
> memory in order to do a transaction, but are afraid that state will
> change while the allocation is in progress?
>
That's one problem.
> What is the maximum size
> of memory that the hardware can handle for this transaction?
It is limited to the amount of available memory.
> How many transactions can be handled concurrently by the hardware?
Typically there is more than one transaction i parallell, and there is
synchronous transfers waiting for completion and non-synchronous transfers
not waiting for completion, that call callbacks.
> What state are you trying to protect?
For example that the callback is not called after that I have stopped a
non-synchronous transfer.
> Is it possible to do the allocation before
> the state needs to be protected?
Mostly, but not always, though that only solves one part of the problem.
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
which function
hi what and where is the function that is responsible for printing the bsd logo on startup? sorry for than question but i'm a new in hacking the bsd and my time is very limited. -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) http://www.maslanlab.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with new the "contigmalloc" routine
Hans Petter Selasky wrote:
On Saturday 21 May 2005 20:04, Scott Long wrote:
John-Mark Gurney wrote:
Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46
+0200:
On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
Non-blocking mode has got to be supported. Else you get a nightmare
rewriting the code to support blocking mode.
Your code either has to block somewhere or fail. contigmalloc() only
blocks if it couldn't satisfy the request immediately. If it returns
to your code, you still have the problem of needing the memory and
not being able to allocate it without blocking.
That is not the problem. The problem is that it sleeps, which will exit
the Giant lock, which means another thread can change the state of what
I am about to setup meanwhile:
one_thread:
mtx_lock(&Giant);
if(sc->gone == 0)
{
sc->data = contigmalloc();
}
mtx_unlock(&Giant);
another_thread:
mtx_lock(&Giant);
if(sc->data)
{
contigfree();
sc->data = NULL;
}
sc->gone = 1;
mtx_unlock(&Giant);
The problem is that the undefined state: "sc->data != NULL" and
"sc->gone == 1" can be reached.
How about rewriting the code to be:
one_thread:
tmpdata = contigmalloc();
mtx_lock(&Giant);
if(sc->gone == 0) {
sc->data = tmpdata;
} else {
contigfree(tmpdata);
}
mtx_unlock(&Giant);
another_thread:
mtx_lock(&Giant);
if(sc->data) {
tmpdata = sc->data;
sc->data = NULL;
}
sc->gone = 1;
mtx_unlock(&Giant);
contigfree(tmpdata);
When I worked with USB I ran into some synchronization problems with callbacks
that leaded me to writing to the stack of another thread, which I hope is OK.
No, it's not ok. Kernel stacks can be swapped out while sleeping.
Writing to a swapped out stack will cause a VM panic.
What do you think about the following:
[...]
I hope this wasn't too much for you to read :-)
Any comments ?
That should do it.. Though you do need to have your own ref count on sc
to prevent the entire sc from going away before the first thread has
locked... Anyways, you should be using your own lock that's in sc for
this instead of using Giant...
right
I'd suggest just following a simplier and more deterministic path by
either pre-allocating your contiguous buffers in a safe context, or
allocating them on the fly before you depend on state being static.
Our concept of 'sleep' and 'block' are a bit muddled now that we have
liberal uses of sleep locks, and we as programmers need to cope and
adjust. It's always good form in embedded and kernel programming to
pre-allocate and closely manage resources when you can; this isn't
userland where resources are cheap.
Pre-allocating memory is good, but not always the easiest to do ...
--HPS
I'm not too familiar with the exact problem you're trying to solve in
USB. I guess you need to be able to allocate a contiguous chunk of
memory in order to do a transaction, but are afraid that state will
change while the allocation is in progress? What is the maximum size
of memory that the hardware can handle for this transaction? How many
transactions can be handled concurrently by the hardware? What state
are you trying to protect? Is it possible to do the allocation before
the state needs to be protected?
Scott
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with new the "contigmalloc" routine
On Saturday 21 May 2005 20:04, Scott Long wrote:
> John-Mark Gurney wrote:
> > Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46
+0200:
> >>On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
> >>>On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
> Non-blocking mode has got to be supported. Else you get a nightmare
> rewriting the code to support blocking mode.
> >>>
> >>>Your code either has to block somewhere or fail. contigmalloc() only
> >>>blocks if it couldn't satisfy the request immediately. If it returns
> >>>to your code, you still have the problem of needing the memory and
> >>>not being able to allocate it without blocking.
> >>
> >>That is not the problem. The problem is that it sleeps, which will exit
> >> the Giant lock, which means another thread can change the state of what
> >> I am about to setup meanwhile:
> >>
> >>one_thread:
> >>
> >> mtx_lock(&Giant);
> >>
> >> if(sc->gone == 0)
> >> {
> >>sc->data = contigmalloc();
> >> }
> >>
> >> mtx_unlock(&Giant);
> >>
> >>another_thread:
> >>
> >> mtx_lock(&Giant);
> >>
> >> if(sc->data)
> >> {
> >>contigfree();
> >>sc->data = NULL;
> >> }
> >>
> >> sc->gone = 1;
> >>
> >> mtx_unlock(&Giant);
> >>
> >>
> >>The problem is that the undefined state: "sc->data != NULL" and
> >>"sc->gone == 1" can be reached.
> >
> > How about rewriting the code to be:
> > one_thread:
> > tmpdata = contigmalloc();
> > mtx_lock(&Giant);
> > if(sc->gone == 0) {
> > sc->data = tmpdata;
> > } else {
> > contigfree(tmpdata);
> > }
> > mtx_unlock(&Giant);
> >
> > another_thread:
> > mtx_lock(&Giant);
> > if(sc->data) {
> > tmpdata = sc->data;
> > sc->data = NULL;
> > }
> >
> > sc->gone = 1;
> >
> > mtx_unlock(&Giant);
> > contigfree(tmpdata);
When I worked with USB I ran into some synchronization problems with callbacks
that leaded me to writing to the stack of another thread, which I hope is OK.
What do you think about the following:
struct context
{
struct mtx *mtx;
u_int8_t *done_p;
};
struct callback
{
struct context ctx;
void *arg;
void (*func)(void *, struct context *ctx);
struct callback *next, **next_p;
};
callback_thread():
{
retry:
struct callback * callbacks[max_callback];
struct mtx * mtxs[max_callback];
u_int8_t done[max_callback] = { /* zero */ };
int x = 0;
int repeat = 0;
int retry = 0;
mtx_lock(&global_callback_lock);
while(1)
{
callbacks[x] = GET_NEXT_CALLBACK();
if(callbacks[x] == NULL)
{
break;
}
if(callbacks[x]->ctx.done_p)
{
/* another thread is calling callback
* ERROR
*/
continue;
}
callbacks[x]->ctx.done_p = &done[x];
mtxs[x] = callbacks[x]->ctx.mtx;
x++;
if(x == max_callback)
{
retry = 1;
break;
}
}
mtx_unlock(&global_callback_lock);
/* here one needs to switch lock to avoid
* locking order reversal
*/
while(x--)
{
mtx_lock(mtxs[x]);
if(done[x] == 0)
{
callbacks[x]->ctx.done_p = NULL;
(callbacks[x]->func)(callbacks[x]->arg, &callback[x]->ctx);
}
/* else callback stopped */
mtx_unlock(mtxs[x]);
}
if(retry)
{
retry = 0;
goto retry;
}
}
void
callback_stop(struct callback *callback)
{
mtx_assert(callback->ctx.mtx, MA_OWNED);
mtx_lock(&global_callback_lock);
REMOVE callback from QUEUE if queued
if(callback->ctx.done_p)
{
*(callback->ctx.done_p) = 1;
callback->ctx.done_p = NULL;
}
mtx_unlock(&global_callback_lock);
}
void
callback_start(struct callback *callback)
{
mtx_assert(callback->ctx.mtx, MA_OWNED);
mtx_lock(&global_callback_lock);
if((callback not QUEUED) &&
(callback->ctx.done_p == NULL))
{
QUEUE callback;
}
mtx_unlock(&global_callback_lock);
}
Now I return to my initial problem. The callback pointed to by
"callback->func" will call "contigmalloc()". How can I solve this, keeping in
mind that "callback_stop()" should stop the callback call?
void
context_exit(struct context *ctx, u_int8_t *tmpvar, struct mtx **tmpmtx)
{
if(ctx == NULL) { *tmpvar = 0; *tmpmtx = 0; return; }
if(ctx->done_p)
{
panic("context already exited\n");
}
mtx_assert(ctx->mtx, MA_OWNED|MA_STATIC);
ctx->done_p = tmpvar;
*tmpvar = 0;
*tmpmtx = ctx->mtx;
mtx_unlock(ctx->mtx);
return;
}
int
context_enter(struct context *ctx, u_int8_t *tmpvar, struct mtx **tmpmtx)
{
if(ctx)
{
mtx_lock(*tmpmtx);
if(*tmpvar == 0)
{ ctx->done_p = NULL; return 0; }
else
{ return EGONE; }
}
return 0;
}
int
context_sleep(struct context *ctx)
{
u_int8_t tmpvar;
int error;
if(ctx == NULL) { return tsleep(); }
if(ctx->done_p)
{
panic("context already exited\n");
}
mtx_assert(ctx->mtx, MA_OWNED|MA_STATIC);
ctx->done_p = &tmpvar;
tmpvar = 0;
error = msleep(... ctx->mtx ...);
if(tmpvar != 0)
error = EGONE;
else { ctx->done_p = NULL; }
return
Re: WRAP.1E and geode.c
Walter C. Pelissero <[EMAIL PROTECTED]> started this thread with message-id <[EMAIL PROTECTED]>: it was noted that bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C " was indeed not working correctly on WRAP.1E platforms. I had been working on this problem recently and have just submitted a patch with a more generalized bios_string() routine which fixes this and also emits BIOS version numbers at boot time, see: http://www.freebsd.org/cgi/query-pr.cgi?pr=81360 Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for ANSI/VT100 code replacement.
On Sun May 22 05, Andrew MacIntyre wrote: > alexander wrote: > >However burncd being a C app uses fprintf. Can I replace > >the functionality of fprintf under x86asm by using only syscalls? > > fprintf(3) is most likely doing buffered I/O in the burncd case, which > for a tty defaults to line buffered. > > Your code is doing unbuffered I/O, which might explain some of the > discrepancies you see. > > Doing your own output buffering in assembly shouldn't be any big deal > that I can see. > > - > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 >[EMAIL PROTECTED] (alt) |Belconnen ACT 2616 > Web:http://www.andymac.org/ |Australia > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" OK. Thx a lot. Due to the incompatibility/bug issue of Eterm I've gotten rid of the entire VT100 sequence and am now using a CR. This works even under Eterm. So far I haven't discovered any slowdowns due to the fast that I'm now rewriting the whole line instead of just 5 ascii values (plus the VT100 stuff). I'm now trying to limit the output rate to correspond with the CRT refresh rate. Is 100 Hz the standard value to use in this case or are there monitors out there that use a higher refresh rate? Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
trouble on the mb acorp 6via/zx85
Hi.
I have a trouble by to install FreeBSD 5.2.1 Release on the
motherboard Acorp 6via/zx85 :(
MB: Acorp 6VIA/ZX85
Chipset: Intel 440ZX PCISet
HDD: Seagate ST340810A
After last dialog window ("Last Chance..."), system write to log:
READ_DMA retrying LBA=78
READ_DMA interrupt was seen but timeout fired LBA=78
READ_DMA status=51 error=40
LBA=78
Signal 11 was cought...
...and reboot the computer (
After changing the variable "ata_dma" (set hw.ata.ata_dma="0") this
error not view, BUT, after last dialog window system write to log:
...
READ_MUL interrupt was seen but timeout fired LBA=78
READ_MUL status=59 error=40
LBA=78
Signal 11 was cought...
...and reboot the computer (
Please, help me to install the system.
Best Regards.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to get the status of cpu in kernel?
On 2005-05-21 18:49, shiner chen wrote: In order to implement a dispacthing policy I want to get the status of cpu. I have read the code of top command and i find it get the status of cpu by the function : int sysctlbyname(const char *, void *, size_t *, void *, size_t); I search the code of kernel ,then I consider that i can get the status of cpu through the funciton: int kernel_sysctlbyname(struct thread *td, char *name, void *old, size_t *oldlenp, void *new, size_t newlen, size_t *retval); I try to get the status of cpu by that function ,but it does not work! You're looking at the wrong place. There is a manpage for the sysctlbyname() function, which you obviously missed. who can tell me the problem? Nobody until you show us the source, I guess :-) How do i get the status of cpu? How do i use it if the funcion is right? what's the mean of the function's arguments ? Start by reading the manpage of sysctlbyname(). Then, if you still have problems, you can post the source online somewhere and point us people at the URL. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i915 AGP not supported aka PR kern/80396
On Sat, May 21, 2005 at 03:17:21PM +0200, Paolo Pisati wrote:
>
> (i already sent an email to Eric some days ago but i
> didn't receive any ack so i try here...)
>
> can anyone take a look at this?
> as the comments say, agp still doesn't
> work...
>
> anything i can do to help?
> Eric?
[snip]
i answer to myself:
just after my post i realized that my chipset
wasn't supported by eric's patch (mine is a i915GM while
original patch was for i915G).
I added my chip id to eric's patch and now i have
agp working (somehow):
[EMAIL PROTECTED] ~]$ dmesg | grep agp
agp0: port 0xec38-0xec3f mem
0xdfec-0xdfef,0xc000-0xcfff,0xdff0-0xdff7 irq 16 at
device 2.0 on pci0
agp0: detected 8060k stolen memory
agp0: aperture size is 256M
[EMAIL PROTECTED] ~]$ ls -la /dev/agpgart
crw--- 1 root wheel 241, 0 May 22 12:52 /dev/agpgart
Unfortunately, xorg-6.8.2 doesn't support my chipset
yet (seems i have to wait for 6.8.3 if it ever will be released...),
so i couldn't test if there were any mistakes in agp
programming.
Anyway, attached is eric's patch with i915gm id added,
if someone care to test it.
bye
--
Paolo
diff -u /usr/src/sys/pci/agp_i810.c agp/agp_i810.c
--- /usr/src/sys/pci/agp_i810.c Wed Mar 23 06:59:42 2005
+++ agp/agp_i810.c Sun May 22 13:55:32 2005
@@ -65,10 +65,12 @@
#define READ1(off) bus_space_read_1(sc->bst, sc->bsh, off)
#define READ4(off) bus_space_read_4(sc->bst, sc->bsh, off)
#define WRITE4(off,v) bus_space_write_4(sc->bst, sc->bsh, off, v)
+#define WRITEGTT(off,v)bus_space_write_4(sc->gtt_bst, sc->gtt_bsh,
off, v)
#define CHIP_I810 0/* i810/i815 */
#define CHIP_I830 1/* 830M/845G */
#define CHIP_I855 2/* 852GM/855GM/865G */
+#define CHIP_I915 3/* 915G */
struct agp_i810_softc {
struct agp_softc agp;
@@ -78,9 +80,14 @@
u_int32_t dcache_size; /* i810 only */
u_int32_t stolen; /* number of i830/845 gtt entries for
stolen memory */
device_t bdev; /* bridge device */
+
struct resource *regs; /* memory mapped GC registers */
bus_space_tag_t bst;/* bus_space tag */
bus_space_handle_t bsh; /* bus_space handle */
+
+ struct resource *gtt; /* memory mapped GATT entries */
+ bus_space_tag_t gtt_bst;/* bus_space tag */
+ bus_space_handle_t gtt_bsh; /* bus_space handle */
};
static const char*
@@ -129,6 +136,12 @@
case 0x25728086:
return ("Intel 82865G (865G GMCH) SVGA controller");
+
+ case 0x25828086:
+ return ("Intel 82915G (915G GMCH) SVGA controller");
+
+ case 0x25928086:
+ return ("Intel 82915GM (915GM GMCH) SVGA controller");
};
return NULL;
@@ -160,6 +173,8 @@
case 0x25628086:
case 0x35828086:
case 0x25728086:
+ case 0x25828086:
+ case 0x25928086:
devid -= 0x2;
break;
};
@@ -222,6 +237,8 @@
case 0x35828086:
case 0x25628086:
case 0x25728086:
+ case 0x25828086:
+ case 0x25928086:/* XXX: Is this the right way? */
gcc1 = pci_read_config(bdev, AGP_I830_GCC1, 1);
if ((gcc1 & AGP_I830_GCC1_DEV2) ==
AGP_I830_GCC1_DEV2_DISABLED) {
if (bootverbose)
@@ -272,19 +289,41 @@
case 0x25728086:
sc->chiptype = CHIP_I855;
break;
+ case 0x25828086:
+ case 0x25928086:
+ sc->chiptype = CHIP_I915;
+ break;
};
/* Same for i810 and i830 */
- rid = AGP_I810_MMADR;
+ if (sc->chiptype == CHIP_I915)
+ rid = AGP_I915_MMADR;
+ else
+ rid = AGP_I810_MMADR;
+
sc->regs = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid,
RF_ACTIVE);
if (!sc->regs) {
agp_generic_detach(dev);
- return ENOMEM;
+ return ENODEV;
}
sc->bst = rman_get_bustag(sc->regs);
sc->bsh = rman_get_bushandle(sc->regs);
+ if (sc->chiptype == CHIP_I915) {
+ rid = AGP_I915_GTTADR;
+ sc->gtt = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid,
+RF_ACTIVE);
+ if (!sc->gtt) {
+ bus_release_resource(dev, SYS_RES_MEMORY,
+AGP_I810_MMADR, sc->regs);
+ agp_generic_detach(dev);
+ return ENODEV;
+ }
+ sc->gtt_bst = rman_get_bustag(sc->regs);
+ sc->gtt_bsh = rman_get_bushandle(sc->regs);
+ }
+
sc->initial_aperture = AGP_GET_APERTURE(dev);
gatt = malloc( sizeof(struct a
