public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* OOPS in read_cd... what to do?
@ 2003-01-27 14:43 Mauricio Martinez
  2003-01-27 16:23 ` Brian Gerst
  2003-01-29 21:25 ` OOPS in read_cd... what to do? Faik Uygur
  0 siblings, 2 replies; 7+ messages in thread
From: Mauricio Martinez @ 2003-01-27 14:43 UTC (permalink / raw)
  To: linux-kernel


I reported twice (Jan 15 the last time) to this list a kernel oops when
reading a CD in a SONY CDU-31A unit with kernels 2.4.18 - 2.4.20 (and
probably all the 2.4 series), which works fine on 2.2.x (and even
1.2.x!!), maybe the maintainer of this part os the code is offline... Are
there any alternatives to fix this problem? Thank you.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: OOPS in read_cd... what to do?
  2003-01-27 14:43 OOPS in read_cd... what to do? Mauricio Martinez
@ 2003-01-27 16:23 ` Brian Gerst
  2003-01-28 12:51   ` Andreas Henriksson
  2003-01-29 21:25 ` OOPS in read_cd... what to do? Faik Uygur
  1 sibling, 1 reply; 7+ messages in thread
From: Brian Gerst @ 2003-01-27 16:23 UTC (permalink / raw)
  To: Mauricio Martinez; +Cc: linux-kernel

Mauricio Martinez wrote:
> I reported twice (Jan 15 the last time) to this list a kernel oops when
> reading a CD in a SONY CDU-31A unit with kernels 2.4.18 - 2.4.20 (and
> probably all the 2.4 series), which works fine on 2.2.x (and even
> 1.2.x!!), maybe the maintainer of this part os the code is offline... Are
> there any alternatives to fix this problem? Thank you.

Drivers for older hardware like this are more than likely unmaintained, 
and suffer from bit-rot.  I don't have this hardware, but I can offer a 
bit of analysis to help you debug this further.  From the oops message 
in your previous email, it looks like the oops occurred on line 1326 of 
cdu31a.c.  From the stack dump, I can see that input_data was called 
with bytesleft=0x4000.  This caused readahead_buffer + bytesleft to go 
past the end of the module and oops.

--
				Brian Gerst


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: OOPS in read_cd... what to do?
  2003-01-27 16:23 ` Brian Gerst
@ 2003-01-28 12:51   ` Andreas Henriksson
  2003-01-28 18:48     ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Henriksson @ 2003-01-28 12:51 UTC (permalink / raw)
  To: linux-kernel

Hi...

While talking about old (probably unmaintaned) hardware and oops..

Any kernel I've tried oops when I try to use the e2100 driver to get my
Cabletron E2100 isa network-card running.

Btw. I don't expect anyone to care, but I'd be very happy if anyone could
give me any comment/hint... I haven't done much debugging before and I'm
not very familiar with kernel/driver development. (So if anyone wondered
why I'm even looking at this, it's not because I can't live without my
Cabletron. It's more like this might be my chance to get more familiar. ;-])

How to reproduce:
1. load module.
	#modprobe e2100
	e2100.c: Presently autoprobing (not recommended) for a single card.
	e2100.c:v1.01 7/21/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
	 00 00 1D 0A 72 AB, IRQ 15, secandary media, memory @ 0xd0000
(I can supply io=0x380 to get rid of the warning message, but there will
be no real difference. I'm not really sure this is the correct value,
but last time I tried this I did look at the jumpers and used the right
value, thats when I noticed the oops. A weird thing btw. It didn't
happen when there also was a ne2000-compatible isa-card used at the same
time, then it just refused to send any traffic.)

2. configure and up the interface, then send traffic using the
interface.
(ping some.remote.ip ... pinging myself works fine, but I guess it's
because the driver isn't involved there)


ksymoops output:


ksymoops 2.4.5 on i586 2.4.20.  Options used
     -v vmlinux (specified)
     -k ksyms (specified)
     -l modules (specified)
     -o /lib/modules/2.4.20/ (default)
     -m System.map (specified)

c38e44e7
*pde = 00000000
Oops: 0000
CPU:    0
EFLAGS: 00010246
eax: 00000030   ebx: 0000002a     ecx: 00000000       edx: c38e4a20
esi: c097f6c2   edi: 000d0000     ebp: 00000380       esp: c07d1c7c
ds: 0018        es: 0018       ss: 0018
Process ping (pid: 320, stackpage=c07d10000)
Stack:  c10e6a60 00000030 c38e4a20 0000003c c38e12ff c38e4a20 0000002a c097f6c2
               00000030 c10e6c60 c38e4a20 c2e20120 c38e4a98 0000002a 00000380 c01d4ce1
               c2e20120 c38e4a20 c02ab7c8 c38e4a20 00000000 c01ceac1 c38e4a20 c2e20120
Call Trace:    [<c38e4a20>] [<c38e12ff>] [<c38e4a20>] [<c38e4a20>] [<c38e4a98>]
  [<c01d4ce1>] [<c38e4a20>] [<c38e4a20>] [<c01ceac1>] [<c38e4a20>] [<c38e4a9e>]
  [<c01fa629>] [<c38e4a20>] [<c01fa133>] [<c38e4a20>] [<c38e4a90>] [<c38e4a98>]
  [<c01d19fa>] [<c01d20bd>] [<c01e0690>] [<c01e13b2>] [<c01f8217>] [<c01f7eb0>]
  [<c010df44>] [<c01c8309>] [<c018e407>] [<c01c9a9c>] [<c0106d34>] [<c0106c23>]
Code: 8a 14 38 25 ff 00 00 00 8d 55 10 8a 04 38 ec b0 05 8d 55 15
Using defaults from ksymoops -t elf32-i386 -a i386


>>edx; c38e4a20 <[e2100]dev_e21+0/570>
>>esi; c097f6c2 <_end+6ae7e6/35fa124>
>>edi; 000d0000 Before first symbol
>>esp; c07d1c7c <_end+500da0/35fa124>

Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e12ff <[8390]ei_start_xmit+133/1f8>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e4a98 <[e2100]dev_e21+78/570>
Trace; c01d4ce1 <qdisc_restart+51/d8>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c01ceac1 <dev_queue_xmit+101/244>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e4a9e <[e2100]dev_e21+7e/570>
Trace; c01fa629 <arp_send+1f5/240>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c01fa133 <arp_solicit+ab/d4>
Trace; c38e4a20 <[e2100]dev_e21+0/570>
Trace; c38e4a90 <[e2100]dev_e21+70/570>
Trace; c38e4a98 <[e2100]dev_e21+78/570>
Trace; c01d19fa <__neigh_event_send+7e/1b4>
Trace; c01d20bd <neigh_resolve_output+61/19c>
Trace; c01e0690 <ip_output+c4/12c>
Trace; c01e13b2 <ip_build_xmit+2c2/35c>
Trace; c01f8217 <raw_sendmsg+28b/2f4>
Trace; c01f7eb0 <raw_getfrag+0/24>
Trace; c010df44 <do_page_fault+0/486>
Trace; c01c8309 <sockfd_lookup+11/7c>
Trace; c018e407 <tty_ioctl+1b3/39c>
Trace; c01c9a9c <sys_socketcall+1e4/200>
Trace; c0106d34 <error_code+34/40>
Trace; c0106c23 <system_call+33/40>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8a 14 38                  mov    (%eax,%edi,1),%dl
Code;  00000003 Before first symbol
   3:   25 ff 00 00 00            and    $0xff,%eax
Code;  00000008 Before first symbol
   8:   8d 55 10                  lea    0x10(%ebp),%edx
Code;  0000000b Before first symbol
   b:   8a 04 38                  mov    (%eax,%edi,1),%al
Code;  0000000e Before first symbol
   e:   ec                        in     (%dx),%al
Code;  0000000f Before first symbol
   f:   b0 05                     mov    $0x5,%al
Code;  00000011 Before first symbol
  11:   8d 55 15                  lea    0x15(%ebp),%edx

 <0>Kernel panic: Aiee, killing interrupt handler!




Did I forget to append something? (Hope not)


Thanks for all your great work by the way!

Regards,
Andreas Henriksson

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: OOPS in read_cd... what to do?
  2003-01-28 12:51   ` Andreas Henriksson
@ 2003-01-28 18:48     ` Alan Cox
  2003-01-28 19:52       ` Andreas Henriksson
  2003-01-29  4:07       ` Cabletron E2100 (e2100.c) Oops Andreas Henriksson
  0 siblings, 2 replies; 7+ messages in thread
From: Alan Cox @ 2003-01-28 18:48 UTC (permalink / raw)
  To: Andreas Henriksson; +Cc: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]


> 1. load module.
> 	#modprobe e2100
> 	e2100.c: Presently autoprobing (not recommended) for a single card.
> 	e2100.c:v1.01 7/21/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> 	 00 00 1D 0A 72 AB, IRQ 15, secandary media, memory @ 0xd0000
> (I can supply io=0x380 to get rid of the warning message, but there will
> be no real difference. I'm not really sure this is the correct value,
> but last time I tried this I did look at the jumpers and used the right
> value, thats when I noticed the oops. A weird thing btw. It didn't
> happen when there also was a ne2000-compatible isa-card used at the same
> time, then it just refused to send any traffic.)
> 
> 2. configure and up the interface, then send traffic using the
> interface.
> (ping some.remote.ip ... pinging myself works fine, but I guess it's
> because the driver isn't involved there)

Try this



[-- Attachment #2: a1 --]
[-- Type: text/plain, Size: 1587 bytes --]

--- drivers/net/e2100.c~	2003-01-28 18:38:21.000000000 +0000
+++ drivers/net/e2100.c	2003-01-28 18:38:21.000000000 +0000
@@ -77,7 +77,7 @@
 {
 	/* This is a little weird: set the shared memory window by doing a
 	   read.  The low address bits specify the starting page. */
-	readb(mem_base+start_page);
+	isa_readb(mem_base+start_page);
 	inb(port + E21_MEM_ENABLE);
 	outb(E21_MEM_ON, port + E21_MEM_ENABLE + E21_MEM_ON);
 }
@@ -306,9 +306,9 @@
 
 #ifdef notdef
 	/* Officially this is what we are doing, but the readl() is faster */
-	memcpy_fromio(hdr, shared_mem, sizeof(struct e8390_pkt_hdr));
+	isa_memcpy_fromio(hdr, shared_mem, sizeof(struct e8390_pkt_hdr));
 #else
-	((unsigned int*)hdr)[0] = readl(shared_mem);
+	((unsigned int*)hdr)[0] = isa_readl(shared_mem);
 #endif
 
 	/* Turn off memory access: we would need to reprogram the window anyway. */
@@ -328,7 +328,7 @@
 	mem_on(ioaddr, shared_mem, (ring_offset>>8));
 
 	/* Packet is always in one chunk -- we can copy + cksum. */
-	eth_io_copy_and_sum(skb, dev->mem_start + (ring_offset & 0xff), count, 0);
+	isa_eth_io_copy_and_sum(skb, dev->mem_start + (ring_offset & 0xff), count, 0);
 
 	mem_off(ioaddr);
 }
@@ -342,10 +342,10 @@
 
 	/* Set the shared memory window start by doing a read, with the low address
 	   bits specifying the starting page. */
-	readb(shared_mem + start_page);
+	isa_readb(shared_mem + start_page);
 	mem_on(ioaddr, shared_mem, start_page);
 
-	memcpy_toio(shared_mem, buf, count);
+	isa_memcpy_toio(shared_mem, buf, count);
 	mem_off(ioaddr);
 }
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: OOPS in read_cd... what to do?
  2003-01-28 18:48     ` Alan Cox
@ 2003-01-28 19:52       ` Andreas Henriksson
  2003-01-29  4:07       ` Cabletron E2100 (e2100.c) Oops Andreas Henriksson
  1 sibling, 0 replies; 7+ messages in thread
From: Andreas Henriksson @ 2003-01-28 19:52 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

Hi..

It didn't help. :(

Though I had to change it some to get it to compile... hopefully I
didn't screw up. (I did this to avoid "invalid operators to binary +")

#define virt_addr(addr) *(volatile unsigned char *) __io_virt(addr)
and changed the isa_...(foo+bar); to isa_...(virt_addr(foo+bar));

The oops looks about the same.. so I guess the patch didn't do any
difference (even if it might be needed in the long run)...

Any more ideas? ;)

 -- Andreas Henriksson

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Cabletron E2100 (e2100.c) Oops...
  2003-01-28 18:48     ` Alan Cox
  2003-01-28 19:52       ` Andreas Henriksson
@ 2003-01-29  4:07       ` Andreas Henriksson
  1 sibling, 0 replies; 7+ messages in thread
From: Andreas Henriksson @ 2003-01-29  4:07 UTC (permalink / raw)
  To: linux-kernel

On Tue, Jan 28, 2003 at 06:48:31PM +0000, Alan Cox wrote:
> 
> Try this

[patch removed]

(Ignore my last posting, brain obviously stopped working)

It worked (almost)... I had to slap a couple of int-casts on the changes
to get it to compile. No more Oops.

One problem still remains... I still can't send any traffic. :-/
"NETDEV WATCH DOG: eth2: transmit timed out"

Half way there I guess....

Here is a diff with the int-casts. Tested, doesn't oops, but doesn't
make the driver work properly eighter.

Regards,
Andreas Henriksson

--- drivers/net/e2100.c.org	Tue Jan 28 22:04:47 2003
+++ drivers/net/e2100.c	Wed Jan 29 04:31:26 2003
@@ -77,7 +77,7 @@
 {
 	/* This is a little weird: set the shared memory window by doing a
 	   read.  The low address bits specify the starting page. */
-	readb(mem_base+start_page);
+	isa_readb((int)(mem_base+start_page));
 	inb(port + E21_MEM_ENABLE);
 	outb(E21_MEM_ON, port + E21_MEM_ENABLE + E21_MEM_ON);
 }
@@ -306,9 +306,9 @@
 
 #ifdef notdef
 	/* Officially this is what we are doing, but the readl() is faster */
-	memcpy_fromio(hdr, shared_mem, sizeof(struct e8390_pkt_hdr));
+	isa_memcpy_fromio(hdr, (int)shared_mem, sizeof(struct e8390_pkt_hdr));
 #else
-	((unsigned int*)hdr)[0] = readl(shared_mem);
+	((unsigned int*)hdr)[0] = isa_readl((int)shared_mem);
 #endif
 
 	/* Turn off memory access: we would need to reprogram the window anyway. */
@@ -328,7 +328,7 @@
 	mem_on(ioaddr, shared_mem, (ring_offset>>8));
 
 	/* Packet is always in one chunk -- we can copy + cksum. */
-	eth_io_copy_and_sum(skb, dev->mem_start + (ring_offset & 0xff), count, 0);
+	isa_eth_io_copy_and_sum(skb, dev->mem_start + (ring_offset & 0xff), count, 0);
 
 	mem_off(ioaddr);
 }
@@ -342,10 +342,10 @@
 
 	/* Set the shared memory window start by doing a read, with the low address
 	   bits specifying the starting page. */
-	readb(shared_mem + start_page);
+	isa_readb((int)(shared_mem + start_page));
 	mem_on(ioaddr, shared_mem, start_page);
 
-	memcpy_toio(shared_mem, buf, count);
+	isa_memcpy_toio((int)shared_mem, buf, count);
 	mem_off(ioaddr);
 }
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: OOPS in read_cd... what to do?
  2003-01-27 14:43 OOPS in read_cd... what to do? Mauricio Martinez
  2003-01-27 16:23 ` Brian Gerst
@ 2003-01-29 21:25 ` Faik Uygur
  1 sibling, 0 replies; 7+ messages in thread
From: Faik Uygur @ 2003-01-29 21:25 UTC (permalink / raw)
  To: Mauricio Martinez; +Cc: linux-kernel


> I reported twice (Jan 15 the last time) to this list a kernel oops when
> reading a CD in a SONY CDU-31A unit with kernels 2.4.18 - 2.4.20 (and
> probably all the 2.4 series), which works fine on 2.2.x (and even
> 1.2.x!!), maybe the maintainer of this part os the code is offline... Are
> there any alternatives to fix this problem? Thank you.

There is something wrong here. This should help.

--- linux-2.4.20/drivers/cdrom/cdu31a.c.orig    Fri Nov 29 01:53:12 2002
+++ linux-2.4.20/drivers/cdrom/cdu31a.c Wed Jan 29 23:12:39 2003
@@ -1384,9 +1384,9 @@
                               readahead_buffer + (2048 -
                                                   readahead_dataleft),
                               readahead_dataleft);
-                       readahead_dataleft = 0;
                        bytesleft -= readahead_dataleft;
                        offset += readahead_dataleft;
+                       readahead_dataleft = 0;
                } else {
                        /* The readahead will fill the whole buffer, get the data
                           and return. */



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-01-29 21:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-27 14:43 OOPS in read_cd... what to do? Mauricio Martinez
2003-01-27 16:23 ` Brian Gerst
2003-01-28 12:51   ` Andreas Henriksson
2003-01-28 18:48     ` Alan Cox
2003-01-28 19:52       ` Andreas Henriksson
2003-01-29  4:07       ` Cabletron E2100 (e2100.c) Oops Andreas Henriksson
2003-01-29 21:25 ` OOPS in read_cd... what to do? Faik Uygur

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox