> On Fri, Dec 07, 2007 at 10:43:00AM +0100, Gerald Heinig wrote:
> > Hi Sonja,
> >
> > > Hi everyone.
> > >
> > > I'm working on a kernel module that needs to maintain a large
> > structure
> > > in memory. As this structure could grow
> Gerald Heinig wrote:
>
> > How about implementing your code as a system call, which is called
from
> > a process that maps a large file into memory, as you suggested
above.
>
> What if the code is a device driver?
I'm just assuming it isn't a device driver
Hi Sonja,
> Hi everyone.
>
> I'm working on a kernel module that needs to maintain a large
structure
> in memory. As this structure could grow too big to be stored in
memory,
> it would be good to offload parts of it to the disk. What would be the
> best way to do this? Could using a memory-mappe
Hi Guys,
On Fri, 2006-06-30 at 01:16 -0700, John-Mark Gurney wrote:
> [EMAIL PROTECTED] wrote this message on Fri, Jun 30, 2006 at 14:26 +0800:
> > I found the problem! It was caused by an existed ata driver in FreeBSD. I
> > have mentioned before that the existed ata driver can take over the
> >
Hi Puramukas,
Puramukas wrote:
I get this error when try to load NICs driver kldload if_yk.ko
for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3
---^^^
This is a Yukon-EC adapter which isn't supported yet for FreeBSD.
Where did you get this driver from? The page you cited b
Hi Puramukas,
which driver version are you using?
Did you get this error message with the standard GENERIC kernel that
came with 5.3-RELEASE, or did you get it with your own kernel?
By the way, if you get problems with our drivers, please contact
[EMAIL PROTECTED] That way we can log problems of
Hi hackers,
I've come across weird behaviour in bus_dmamem_alloc() whilst trying to
allocate small memory blocks (less than PAGE_SIZE) which have to be
aligned to PAGE_SIZE.
My segment size is 2048, my maximum number of segments is 1 (it MUST be
contiguous), my max. total segment size is also 2048
Stephan Uphoff wrote:
On Wed, 2005-02-16 at 07:19, Gerald Heinig wrote:
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.debug
...
0x in ?? ()
I got this as well. In my case I assumed
Ulrich Spoerlein wrote:
On Sun, 13.02.2005 at 22:46:29 -0500, Stephan Uphoff wrote:
+device dcons
+device dcons_crom
Then configured/compiled/installed the GENERIC.debug kernel.
Copied the kernel.debug file in the GENERIC.debug compile directory to
the debug station and rebooted the target machine.
Stephan Uphoff wrote:
On Tue, 2005-02-15 at 11:55, Gerald Heinig wrote:
Hi Stephan,
I'm happy to say that it's working now :)
I grabbed a 5.3-STABLE snapshot to get the updated kgdb and completely
reinstalled my 5.3-RELEASE system. I compiled the kernel using your
options and it worke
27;s the debug method I'm _really_ interested in, because it enables
you to debug hangs and freezes.
Anyway, enough for now. Thanks again.
Cheers,
Gerald
Stephan Uphoff wrote:
On Mon, 2005-02-14 at 11:41, Gerald Heinig wrote:
Gerald Heinig wrote:
Hi Stephan,
first off, thanks very much for your cont
Gerald Heinig wrote:
Hi Stephan,
first off, thanks very much for your continuing help on this. It's very
much appreciated.
I compiled a kernel with exactly the same options that you cited below.
I tried booting it and it stops before the kernel probe routines and
waits for the FireWir
Hi Stephan,
first off, thanks very much for your continuing help on this. It's very
much appreciated.
I compiled a kernel with exactly the same options that you cited below.
I tried booting it and it stops before the kernel probe routines and
waits for the FireWire GDB connect.
I can't understa
Ashwin Chandra wrote:
ryan,
i think i was a bit vague in my email. I am correctly usnig the swap
device and dump directory. Before the system reboots the core should be
saved from the swap device (before it mounts) and into the path that i
specified. dumpdev="/dev/ad0s1b", our 2gb swap device an
Stephan Uphoff wrote:
Once I linked in dcons, dcons_crom and firewire into the kernel
everything worked. (I think only dcons is really needed - maybe a link
set issue?)
I only used the gdb stub method.
Can you send me your dmesg? (After you linked the dcons stuff into the
kernel)
Another thing: wha
Stephan Uphoff wrote:
On Wed, 2005-02-09 at 03:13, Gerald Heinig wrote:
Stephan Uphoff wrote:
There are two ways using kgdb to debug a target with firewire.
The first way basically replaces the slow serial cable for
communication to the remote target gdb stub. The second way uses
the remote DMA
Stephan Uphoff wrote:
There are two ways using kgdb to debug a target with firewire.
The first way basically replaces the slow serial cable for communication
to the remote target gdb stub.
The second way uses the remote DMA capabilities of firewire to directly
read memory of the target WITHOUT usin
Gerald Heinig wrote:
I recall some issues with gdb and firewire as a module that may or may
not be fixed.
I recommend to put the dcons into the kernel to avoid any problems.
I tried that too. There are a few additional flags that can be set. Of
particular interest are DCONS_FORCE_CONSOLE and
Stephan Uphoff wrote:
On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote:
Hi all,
I'm having problems getting two 5.3-RELEASE boxes to communicate over
firewire.
I'm using two VIA Vt-6306 -based cards which are correctly recognised at
boot-time.
I've loaded the dcons and dconsc
Hi all,
I'm having problems getting two 5.3-RELEASE boxes to communicate over
firewire.
I'm using two VIA Vt-6306 -based cards which are correctly recognised at
boot-time.
I've loaded the dcons and dconschat modules and obtained both firewire
addresses via fwcontrol.
When I try to set up a conn
Hi all,
I'm having problems getting a kernel to write a crash dump on my Dell
Optiplex under FreeBSD 5.3.
I've set dumpdev="/dev/ad0s1b", set kern.sync_on_panic to 1, the dump
device has enough space (1 Gig, physical RAM is 512M).
When the kernel panics, it starts writing out a vmcore, but only
ing
poorly. Use a proper MP box ("proper" meaning >= 4 CPUs) and the picture
usually changes.
I'd be interested to see the same test done on a 4 CPU box.
Cheers,
Gerald
Kamal R. Prasad wrote:
--- Gerald Heinig <[EMAIL PROTECTED]> wrote:
Hi Robert,
the benchmark you cited
Hi Robert,
the benchmark you cited is for uniprocessor systems only.
It says nothing about multiprocessor performance, which is what FreeBSD
is aiming for.
It's comparing apples with oranges.
Cheers,
Gerald
Robert Ryan wrote:
Fellow FreeBSD developers,
I hate to say I told you but it was inevitab
Martin,
take a look at isdnd. If all you want is a program to tell you whether
someone's calling you and under what number, isdnd will tell you that in
full screen mode.
Alternatively, if you want to write your own program, take a look at the
isdnd sources to see how it's done.
HTH,
Gerald
Mar
f_linkmiblen = sizeof(struct ifmib_iso_8802_3);
--
S y s K o n n e c t G m b H
A Marvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
---------
Gerald Heinig
Software Engineer
-
phone: + 49 (0) 7243 502 354
fax:+49 (0) 7243 502 364
e
rvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
-----
Gerald Heinig
Software Engineer
-
phone: + 49 (0) 7243 502 354
fax:+49 (0) 7243 502 364
email: [EMAIL PROTECTED]
http://www.syskonnect.com
ed by malloc at driver start-time, or can I use malloc
as in userland?
Cheers,
Gerald
--
S y s K o n n e c t G m b H
A Marvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
-
Gerald Heinig
Software Engineer
-
phone: + 49 (0)
ed by malloc at driver start-time, or can I use malloc
as in userland?
Cheers,
Gerald
--
S y s K o n n e c t G m b H
A Marvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
-
Gerald Heinig
Software Engineer
-
phone: + 49 (0)
.hints.
Is something like this at all possible?
Cheers,
Gerald
--
S y s K o n n e c t G m b H
A Marvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
-----
Gerald Heinig
Software Engineer
-
phone: + 49 (0) 7243 502 354
fax:
30 matches
Mail list logo
