In message <[EMAIL PROTECTED]>, "David O'Brien" writes:
>When compiling the `dict' port, one gets:
>
>In file included from /usr/include/machine/signal.h:54,
> from /usr/include/sys/signal.h:178,
> from /usr/include/signal.h:44,
> fro
>
>Correction.
>
>This sample:
>>
>> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
>> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
>> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
>> isp_prt(isp, ISP_LOGERR,
>>
>Every hear the phrase "you get what you pay for?" The API isn't all that
>clear, and we don't have a man page or document that describes in detail
>how to use it properly. Rather than whining about that, I decided to
>tinker with it and Use The Source, Luke (tm). This is the result.
Fair enough.
Correction.
This sample:
>
> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
> isp_prt(isp, ISP_LOGERR,
>
On Mon, 20 Aug 2001, Bill Paul wrote:
> Every hear the phrase "you get what you pay for?" The API isn't all that
> clear, and we don't have a man page or document that describes in detail
> how to use it properly. Rather than whining about that, I decided to
> tinker with it and Use The Source,
In message <[EMAIL PROTECTED]> "Walter C. Pelissero"
writes:
: Mmmm, you might be right. I'm using a 3com 589, therefore I'm using
: the ep driver.
The ep driver has been a little flakey under heavy load (like NFS) for
a while.
: Side note. Regarding a different problem I've mentioned in
: fre
When compiling the `dict' port, one gets:
In file included from /usr/include/machine/signal.h:54,
from /usr/include/sys/signal.h:178,
from /usr/include/signal.h:44,
from dict.h:33,
from clientparse.y:25:
/
>
> Another thing- maybe I'm confused- but I still don't see why you want to
> require the creating of a map each time you want to load an mbuf
> chain. Wouldn't it be better and more efficient to let the driver decide when
> and where the map is created and just use the common code for loads/unl
David Malone writes:
> On Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote:
> > This enforces my belief that there is something broken in some deeper
> > layer of the network code (see the remote printing issue).
>
> Just out of curiosity, what sort of network card is your Va
Another thing- maybe I'm confused- but I still don't see why you want to
require the creating of a map each time you want to load an mbuf
chain. Wouldn't it be better and more efficient to let the driver decide when
and where the map is created and just use the common code for loads/unloads?
On
Yay!
The current suggestion is fine except that each platform might have a more
efficient, or even required, actual h/w mechanism for mapping mbufs.
I'd also be a little concerned with the way you're overloading stuff into mbuf
itself- but I'm a little shakier on this.
Finally- why not make th
Okay, I decided today to write a bus_dmamap_load_mbuf() routine to
make it a little easier to convert the PCI NIC drivers to use the
busdma API. It's not the same as the NetBSD code. There are four
new functions:
bus_dmamap_load_mbuf()
bus_dmamap_unload_mbuf()
bus_dmamap_sync_mbuf()
bus_dmamap_de
> > "etni"
>
> "inet"
>
Your string reversal function is buggy.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
* Bill Kish <[EMAIL PROTECTED]> [010820 12:09] wrote:
>
> Hi All,
>
> Sorry if this posting is somewhat off topic, but I think the answer to my
> question will be found among the subscribers to this list.
>
> I'm trying to convince the powers that be here at Coyote Point Systems that
> we sho
According to David Malone:
> Just out of curiosity, what sort of network card is your Vaio using?
> Someone else is seeing network related panics that might be related
If this is a VAIO with built-in ethernet, then it is an fxp card.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL
:Matt
:
:Ok I see..the interlock is a lock on a collection (e.g
:on vfs mount list) and it can be released once the simple
:lock within the to-be-locked object has been acquired.
:These are really spin locks, now that I saw simplelock.s
:
:One more clarification if you will.. :-)
:
:What is the p
Matt
Ok I see..the interlock is a lock on a collection (e.g
on vfs mount list) and it can be released once the simple
lock within the to-be-locked object has been acquired.
These are really spin locks, now that I saw simplelock.s
One more clarification if you will.. :-)
What is the purpose of
On Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote:
> This enforces my belief that there is something broken in some deeper
> layer of the network code (see the remote printing issue).
Just out of curiosity, what sort of network card is your Vaio using?
Someone else is seeing net
John Baldwin writes:
> > fault virtual address = 0x65746e69
> "etni"
>
> Looks like a string has gotten spammed across a data structure or a
> weird pointer, etc.
Whatever mess happend, I've got some news for you that should remove
the NFS module from the list of
> "etni"
oops I mean "inte" (as in "integer"
>
> Looks like a string has gotten spammed across a data structure or a weird
> pointer, etc.
>
> From the previous panic:
>
> > fault virtual address = 0x33693d55
> "3i=U"
>
> That one look
remember it's littel endian
On Mon, 20 Aug 2001, John Baldwin wrote:
> > fault virtual address = 0x65746e69
> "etni"
"inet"
>
> Looks like a string has gotten spammed across a data structure or a weird
> pointer, etc.
>
> From the previous panic:
>
> > fault vir
On 20-Aug-01 Walter C. Pelissero wrote:
> [ third time I retry to post this message on the mailing list ]
>
> Peter Pentchev writes:
> > On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote:
> > All those ??'s are the result of kgdb being unable to look inside
> > a kernel modu
On Mon, Aug 20, 2001 at 01:05:28PM -0400, Bill Kish wrote:
>
> Hi All,
>
> Sorry if this posting is somewhat off topic, but I think the answer to my
> question will be found among the subscribers to this list.
>
> I'm trying to convince the powers that be here at Coyote Point Systems that
>
:Hi there,
:
:I need some mechanism to hold long-term locks (across
:context switches) while using kernel threads (kthread_*)
:and lockmgr() looked like the right thing to use.
:
:I am running FreeBSD 4.1 on a uniprocessor (..the questions
:are similar with 4.3)
:
:Looking at kern_lock.c, I see t
[ third time I retry to post this message on the mailing list ]
Peter Pentchev writes:
> On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote:
> All those ??'s are the result of kgdb being unable to look inside
> a kernel module. Are you loading NFS as a module?
Yep. I recomp
Hi All,
Sorry if this posting is somewhat off topic, but I think the answer to my
question will be found among the subscribers to this list.
I'm trying to convince the powers that be here at Coyote Point Systems that
we should release the source for our Equalizer load balancer software to the
Hi there,
I need some mechanism to hold long-term locks (across
context switches) while using kernel threads (kthread_*)
and lockmgr() looked like the right thing to use.
I am running FreeBSD 4.1 on a uniprocessor (..the questions
are similar with 4.3)
Looking at kern_lock.c, I see that lockmg
Mike Smith <[EMAIL PROTECTED]> wrote:
> > The memory is not freed until you unmount (and then, the memory is
> > only free'd for use by other cfs mounts -- the process size does not, of
> > course, shrink).
>
> It doesn't? Does it just use malloc for these structs? When you say "of
> cou
In message <[EMAIL PROTECTED]> "Walter C. Pelissero"
writes:
: Upgrading to 4.4-RC a couple of new problems have shown up on my
: laptop (Vaio PCG-XG9). Beside the already mentioned NFS panic (see
: freebsd-hackers or freebsd-net), now the bootstrap phase freezes
: somewhere after:
:
: pcic1: E
Upgrading to 4.4-RC a couple of new problems have shown up on my
laptop (Vaio PCG-XG9). Beside the already mentioned NFS panic (see
freebsd-hackers or freebsd-net), now the bootstrap phase freezes
somewhere after:
pcic1: Event mask 0x9
The system seems to be frozen beside that if I remove or in
On Mon, 20 Aug 2001, Makoto MATSUSHITA wrote:
> brian> Would it be worth bringing up the subject of adding an IFF_ flag that
> brian> can be SIOCSIFFLAGS'd into the interface with the kame team ?
>
> I cannot tell it's good and/or standard-compliant things or not... but,
>
> brian> If you thi
brian> Would it be worth bringing up the subject of adding an IFF_ flag that
brian> can be SIOCSIFFLAGS'd into the interface with the kame team ?
I cannot tell it's good and/or standard-compliant things or not... but,
brian> If you think it's worth bringing up with the kame guys, can you tell
On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote:
> [ it seems my original article didn't get through ]
>
> I recently upgraded to 4.4-RC.
> Now my Vaio panics when I use NFS volumes (as client).
> The panic is reproducible with a:
>
> find /some/NFS/mount/point -type f -e
[ it seems my original article didn't get through ]
I recently upgraded to 4.4-RC.
Now my Vaio panics when I use NFS volumes (as client).
The panic is reproducible with a:
find /some/NFS/mount/point -type f -exec cat {} \; >/dev/null
Sometime I got a "page fault", sometime a "lockmgr: locki
>
> brian> Can anybody tell me if it's possbile to tell a given interface
> brian> not to do DAD ?
>
> There is a kernel MIB, 'net.inet6.ip6.dad_count'. See inet6(4)
> manpage for more detail.
>
> However, there is no way to stop DAD for any given interfaces; only
> we have two choices, 'do DA
* Kris Kennaway <[EMAIL PROTECTED]> [010820 03:26] wrote:
> On Mon, Aug 20, 2001 at 01:19:05AM -0700, Peter Wemm wrote:
>
> > Regarding stripping gcc2_compiled.. strip can only filter symbols from
> > the .symtab and .symstr symbol tables. Since strip already removes both
> > of those sections,
Murray/jkh, please do not approve this for MFC until the problems have been
fixed. For starters, it breaks all platforms other than the i386.
Matt Dillon wrote:
> Here is my proposed patch. It adds to options (overrides) to the kernel
> config, two boot-time tunables for same, and sets
On Mon, Aug 20, 2001 at 01:19:05AM -0700, Peter Wemm wrote:
> Regarding stripping gcc2_compiled.. strip can only filter symbols from
> the .symtab and .symstr symbol tables. Since strip already removes both
> of those sections, the -N gcc2_compiled is useless. strip cannot modify
> the .dynsym
Kris Kennaway wrote:
> + execlp("strip", "strip", "-s", "-R", ".comment",
> +"-R", ".note", "-N", "gcc2_compiled",
> +to_name, (char *)NULL);
Some comments:
.note: used in ELF branding.
gcc2_compiled: used by
39 matches
Mail list logo
