Hello,
I have retained my earlier mail below so that you have some context.
For the case 1 described below, I got a dump which I could decode for
once.
Here it is. Could anyone tell me what might be happening?
This happens at the receiver and that too when I transmit a 25-100 Meg of
data as fast as I can. If I transfer 1 Meg, this doesn't happen. If I
transfer slowly (send a packet, wait for a while and send again), this
happens almost at the end of 100 Meg at the receiver (25, 50 Meg go
through fine).
Does it have to do with some memory crunch?
Any response is highly appreciated.
Thanks,
Pramodh
The ksymoops output:
------------------------------------------------------------
>>EIP: c0110a06 <schedule+382/398>
Trace: c018a60e <ll_rw_block+14a/1ac>
Trace: c01257d5 <__wait_on_buffer+99/d4>
Trace: c0126596 <bread+4a/70>
Trace: c013a23e <read_block_bitmap+3a/88>
Trace: c013a45c <load__block_bitmap+1d0/1e4>
Trace: c013a8de <ext2_new_block+176/9a0>
Trace: c015f41d <alloc_skb+71/dc>
Trace: c01bffba <tulip_rx+37a/404>
Trace: c01132ba <printk+166/174>
Trace: c0107e8d <cpu_idle+61/68>
Code: c0110a06 <schedule+382/398> 00000000 <_EIP>: <===
Code: c0110a06 <schedule+382/398> 0: c7 05 00 00 00 00
00 movl $0x0,0x0 <===
Code: c0110a0d <schedule+389/398> 7: 00 00 00
Code: c0110a10 <schedule+38c/398> a: 8d 65 e4
leal 0xffffffe4(%ebp),%esp
Code: c0110a13 <schedule+38f/398> d: 5b
popl %ebx
Code: c0110a14 <schedule+390/398> e: 5e
popl %esi
Code: c0110a15 <schedule+391/398> f: 5f
popl %edi
Code: c0110a16 <schedule+392/398> 10: 89 ec
movl %ebp,%esp
Code: c0110a18 <schedule+394/398> 12: 5d
popl %ebp
Code: c0110a19 <schedule+395/398> 13: c3
ret
-------------------------------------------------------------------------
On Wed, 24 May 2000, pramodh mallipatna wrote:
> Hello,
>
> Appreciate your patience to read this slightly long mail and answer.
>
> I am trying trying to do File transfer over Ethernet using my own protocol
> (non-IP). I read the contents in chunks (within the kernel, similar to
> generic_file_read()), packetize it and send it across. I get the packet at
> the other end (the contents are fine) and write it to the file (in either
> of the two ways).
>
> 1. Using a routine similar to ext2_file_write() but the difference being,
> I do a memcpy() from the skbuff instead of the copy_from_user().
>
> PROBLEM: This works fine for files as large as 1MB but has problems
> for larger files like 25, 50MB files. I just get a huge dump and I
> can't even trace the calls. So, I don't know what is happening.
>
> 2. I mmap the output file using do_mmap() within the kernel and I memcpy
> the contents of the skbuff to this memory mapped buffer (Since do_mmap
> returns a user buffer, I map it to a kernel address and use this for
> memcpy. The user-kernel memory mapping part works fine, I have tested
> that independently). When I print out the contents of this buffer, it
> has the data which came from the skbuff. The memcpy is fine, in the
> sense that it doesn't panic/hang.
>
> PROBLEM: After the transfer, when I look at the contents of the file,
> it just has zeros.
>
> I have tried transferring files within the kernel (on the same
> machine) using do_mmap() for both input and output files. It just works
> fine.
>
> The communication part (transfer over Ethernet) works fine. i.e. if I just
> send dummy packets, I get it at the other end without problems.
>
> Could anyone help me debug the problem?
>
> Thanks,
> Pramodh
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST