* 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