>> Can anyone explain to me why I would be getting this error in the
>> first place? Why is it failing to allocate a page when there are
>> pages available? That does not make any sense to me.
> order:1
> It's failing to allocate -two- pages.
Good point. However, why is it failing? According
Apparently I spoke too soon - sorry about that. I am still getting the error
when I try to write to disk and receive on the network at the same time. Here
is the output:
blastee: page allocation failure. order:1, mode:0x4020
Call Trace:
[ccea9a40] [c0006ef0] show_stack+0x44/0x16c (unreliable)
Okay, I think I have all the issues worked out and can now send and receive any
size packet without a hiccup. I have tested this in our system setup as well
with data being sent out to disk and did not see any problems there either
(since it only ever allocates a single page, never more).
Is t
I found out what was causing the crash, but still am not there and could use
some direction:
What was happening was that I was not allocating a new SKB to replace the one
in the ring that was being passed up the stack. I have remedied that and am
now having another issue:
Once the ring index
> On Mon, 2009-11-09 at 16:21 -0700, Jonathan Haws wrote:
> > All,
> >
> > I would like to disable caching for an address that was returned
> from a call to mmap(). I am using this address for DMA operations
> in user space and want to make sure that the data cache is t
All,
I have a routine to invalidate the data cache from user space (since I do not
believe there is a standard routine I can use outside of kernel space??).
Here is the code:
.text;
.globl cacheInvalidate405;
cacheInvalidate405:
/*
* r3 = Data cache
* r4
All,
I would like to disable caching for an address that was returned from a call to
mmap(). I am using this address for DMA operations in user space and want to
make sure that the data cache is turned off for that buffer.
The way this works is the driver simply takes an address I provide and
All,
I am having some troubles getting interrupts to fire from my kernel module. I
have connected the ISR with a call to request_irq() and have configured my
device to generate interrupts. However, my ISR is called once when I connect
the interrupt for the first time. After that it never is
> 1. I open /dev/mem and get a file descriptor
> 2. I use mmap to reserve some physical addresses for my buffers in
> user space.
> 3. I give that address to the FPGA for DMA use.
> 4. When I get the FPGA interrupt, I invalidate the data cache and
> write the data to disk
>
> Does that sound like
> Jonathan Haws wrote:
> > All,
> >
> > I have what may be an unconventional question:
> >
> > Our application consists of data being captured by an FPGA,
> processed, and transferred to SDRAM. I simply give the FPGA an
> address of where I want it stored
All,
I have what may be an unconventional question:
Our application consists of data being captured by an FPGA, processed, and
transferred to SDRAM. I simply give the FPGA an address of where I want it
stored in SDRAM and it simply DMAs the data over and interrupts me when
finished. I then t
> Michael Buesch wrote:
> > Yes, I think the barrier is wrong.
> > Please try with
> >
> > #define mb()__asm__ __volatile__("eieio\n sync\n" : : :
> "memory")
>
>
> For uncached memory, eieio should be enough.
I tried eieio alone and it did not work. It needed the above command to take
> On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote:
> > > asm("eieio; sync");
> >
> > Hmm...
> > : : : "memory"
> >
> > And, doesn't ";" start a comment in assembly? (no, not on powerpc
> it seems)
>
> Yes, I think the barrier is wrong.
> Please try with
>
> #define mb() __asm__ __
> On Friday 30 October 2009 15:50:22 Jonathan Haws wrote:
> > > I suspect that the msync() was merely serving as a very
> heavyweight
> > > memory barrier.
> >
> > I did try hacking the mb() calls from the kernel source to use
> them in user space, but they
> On Thu, Oct 29, 2009 at 10:00:28AM +0100, Joakim Tjernlund wrote:
> > > I have found the problem. It occurred to me in the shower (okay
> not really,
> > > but most good ideas happen there).
> > >
> > > What was happening is that I was in fact able to write to the
> correct
> > > registers. How
> Looking through our notes and talking with the engineer
> who was performing the tests, it was exactly that - MTD was waiting
> for a signal that was produced differently than the hardware
> ready signal. By simply polling the flash until the hardware
> ready signal toggled we were able to get
> > > Anyway, to make a long story short, I inserted an msync() after
> each
> > > assignment to the flash. This resolved my problem and I can now
> program my flash.
> >
> > Ouch, this was news to me too. Calling msync() after every write
> kills performance.
> > We use mmap(/dev/mem) to access H
> Does O_DIRECT help? (you may need to define _GNU_SOURCE before
> #include)
Nope, O_DIRECT did not help - in fact it caused the application to crash. Why
that is I am not sure, but it crashed.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.o
> On Tue, Oct 27, 2009 at 04:52:40PM -0600, Jonathan Haws wrote:
> > > Will the device respond to 0x1234 being written at offset zero?
> You
> > > generally have to poke these things pretty specifically in order
> to
> > > get
> > > them to go into
> > On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> > >> >>> How can I get that pointer? Unfortunately I cannot simply
> > use
> > >> the
> > >> >>>
> > >> >> address of the flash. Is there
> On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote:
> > > Jonathan Haws wrote:
> > > > I had thought about using MTD, but decided against it because
> with
> > > > previous benchmarking that we did with MTD and our custom
> driver,
> > > we
> On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
> >> >>> How can I get that pointer? Unfortunately I cannot simply
> use
> >> the
> >> >>>
> >> >> address of the flash. Is there some magical function call
> Jonathan Haws wrote:
> >>> flash[0] = 0x1234;
> >>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> printf("flash[0] = %#04x\n", flash[0]);
> >>>
> >>> That prints flash[0] = 0x7f45. I have verif
> > Okay, I now have access to the flash memory, however when I write
> to it the writes do not take. I have tried calling msync() on the
> mapping to no avail. I have opened the fd with O_SYNC, but cannot
> get things to work right.
> >
> > Here are the calls:
> >
> > int fd = open("/dev/mem
> > Okay, I now have access to the flash memory, however when I write
> to
> > it the writes do not take.
>
>
> > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
>
> MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
> in-ram copy of the data, not to the original on
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >>
> >
> >
> > To use th
> Jonathan Haws wrote:
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
&
> > How can I get that pointer? Unfortunately I cannot simply use the
> address of the flash. Is there some magical function call that
> gives me access to that portion of the memory space?
> >
>
> $ man 2 mmap
>
> You want MAP_SHARED and O_SYNC.
To use that I need to have a file descriptor t
I know this is probably a really dumb question, but a wise man once said that
the only stupid question is the one that is not asked.
So, I have written a flash driver in VxWorks that simply addresses the flash
directly and handles all the hardware accesses just fine. I am porting that to
Linux
ld love to be
able to use a 9000 byte MTU without getting out of memory errors simply due to
fragmentation.
HTH,
Jonathan
>
> -Original Message-
> From: linuxppc-dev-bounces+john.p.price=l-3com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+john.p.price=l-
> 3com@lis
October 2009 19:43:00 Jonathan Haws wrote:
> > Quick question about the network stack in general:
> >
> > Does the stack itself release an SKB allocated by the device
> driver back to the heap upstream, or does it require that the device
> driver handle that?
>
Quick question about the network stack in general:
Does the stack itself release an SKB allocated by the device driver back to the
heap upstream, or does it require that the device driver handle that?
Thanks!
Jonathan
___
Linuxppc-dev mailing list
L
Okay, I need to revisit this issue. I have had my time taken away for other
things the past couple of months, but I am now back at this network issue.
Here is what I have done:
1. I modified the ibm_newemac driver to follow scatter-gather chains on the RX
path. The idea was to setup the drive
(34113).
- Jake Magee
On Thu, Oct 22, 2009 at 3:57 PM, Jonathan Haws
mailto:jonathan.h...@sdl.usu.edu>> wrote:
All,
I am using a 405EX CPU on a custom board. The layout and hardware is very
similar to the AMCC Kilauea board. Here is the output of uname -a:
Linux (none) 2.6.30.3-wolverine
All,
I am using a 405EX CPU on a custom board. The layout and hardware is very
similar to the AMCC Kilauea board. Here is the output of uname -a:
Linux (none) 2.6.30.3-wolverine-dirty #3 PREEMPT Thu Sep 10 11:41:37 MDT 2009
ppc unknown
I am getting the following BUG output when my program ex
> If the hardware supports it, the best way to deal with it is to set
> up
> the driver so that it only ever deals in single pages.
I am working on fixing the driver to support NETIF_F_SG and have changed how it
receives packets to follow how the e1000 driver does it.
Here is where I am at:
W
All,
I am having some issues with my target and was hoping that someone could lend a
hand. I am using an AMCC 405EX (Kilauea) board running Linux kernel 2.6.31.
Here is the problem. I have some code that receives jumbo frames via the EMAC,
sticks the data in a buffer, and writes the data out
All,
I am having some issues with my target and was hoping that someone could lend a
hand. I am using an AMCC 405EX (Kilauea) board running Linux kernel 2.6.31.
Here is the problem. I have some code that receives jumbo frames via the EMAC,
sticks the data in a buffer, and writes the data out
38 matches
Mail list logo
