i2o & Promise SuperTrak100

i2o & Promise SuperTrak100

[David Priban]

Can somebody comment on usability of current i2o drivers
from 2.4.2 kernel with Promise SuperTrak100 controller?
There seems to be some interrupt issue causing kernel
to panic when i2o_block is loaded. Transcript as follows:

Scheduling in interrupt
kernel BUG at sched.c:707!
invalid operand: 0000
CPU:		0
EIP:		0010:[<c01110e4>]
EFLAGS:	00010086
eax: 0000001b  ebx: c7f99760  ecx: 00000001  edx: c0246b08
esi: 00001cc6  edi: c0258000  ebp: c0259eac  esp: c0259e7c
Process swapper(pid:0, stackpage=c0259000)
Stack:
c01f9acb  c01f9c36  000002c3  c7f99760  00001cc6  c1272a78  00000044
00000082
00000000  c7f99760  00000000  c01b33fe  c1272a20  c01b349c  c7f99760
c7f99760
00000001  00000056  c01b308f  c7f99760  c7f99760  c02548a0  00000001
c029072a
Call Trace:
[<c01b33fe>] [<c01b349c>] [<c01b308f>] [<c01b4774>]
[<c01b47a6>] [<c011b0fe>] [<c011b4bf>] [<c018969d>]
[<c0189731>] [<c018918e>] [<c018a12d>] [<c018a19f>]
[<c0109f6d>] [<c010a0ce>] [<c0107120>] [<c0107120>]
[<c0108e00>] [<c0107120>] [<c0107120>] [<c0100018>]
[<c0107143>] [<c01071a9>] [<c0105000>] [<c0100191>]
Code:
0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56
Kernel panic: Aiee, killing interrupt handler !
In interrupt handler - not syncing

It is hand written so errors are possible...

This doesn't happen if I compile drivers as modules a load them
by hand.

Thanks   David

Re: i2o & Promise SuperTrak100

[Alan Cox]

> c029072a
> Call Trace:
> [<c01b33fe>] [<c01b349c>] [<c01b308f>] [<c01b4774>]
> [<c01b47a6>] [<c011b0fe>] [<c011b4bf>] [<c018969d>]
> [<c0189731>] [<c018918e>] [<c018a12d>] [<c018a19f>]
> [<c0109f6d>] [<c010a0ce>] [<c0107120>] [<c0107120>]
> [<c0108e00>] [<c0107120>] [<c0107120>] [<c0100018>]
> [<c0107143>] [<c01071a9>] [<c0105000>] [<c0100191>]
> Code:
> 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56
> Kernel panic: Aiee, killing interrupt handler !
> In interrupt handler - not syncing

Run it through ksymoops and I might be able to guess what went wrong.

In theory however i2o is a standard and all i2o works alike. In practice i2o
is a pseudo standard and nobody seems to interpret the spec the same way, the
implementations all tend to have bugs and the hardware sometimes does too.

RE: i2o & Promise SuperTrak100

[David Priban]

> > Kernel panic: Aiee, killing interrupt handler !
> > In interrupt handler - not syncing
>
> Run it through ksymoops and I might be able to guess what went wrong.
>
> In theory however i2o is a standard and all i2o works alike. In
> practice i2o
> is a pseudo standard and nobody seems to interpret the spec the
> same way, the
> implementations all tend to have bugs and the hardware sometimes does too.
>
Alan,
This is what ksymoops gave me. One thing I didn't mention before:
kernel panics when I hit Ctrl-Alt-Del after it hangs telling me this:

>>Loading I2O core - (c) Copyright 1999 Read Hat Software
>>i2o: Checking for PCI I2O controllers...
>>PCI: Found IRQ5 for device 00:0a.1
>>i2o: I2O Controller on bus 0 at 81
>>i2o: PCI I2O controller at 0xE3000000 size=4194304
>>i2o/iop0: Installed at IRQ5
>>i2o: 1 I2O controller found and installed
>>Activating I2O controllers...
>>This may take few minutes if you have many devices
>>i2o/iop0: Reset rejected, trying to clear
>>i2o/iop0: LCT has 6 entries
>>i2o/iop0: Configuration dialog desired.
>>Target ID 0.
>>	Vendor:	Wind River Sys.
>>	Device:	IxWorks
>>	Rev:	0201
>>	class:	executive
>>	subclass:	0x0001
>>	Flags:	PM
>>Target ID 8.
>>	Vendor:	PROMISE TECH.
>>	Device:	I2O RAID ISM
>>	Rev:	V1.0.0
>>	Class:	Device Driver Module
>>	Subclass:0x0021
>>	Flags:	PM
>>Target ID 9.
>>	Vendor:	PROMISE TECH.
>>	Device:	I2O IDE HDM
>>	Rev:	0.02
>>	Class:	Device Driver Module
>>	Subclass:0x0020
>>	Flags:	PM
>>Target ID 10.
>>	Vendor:	Seagate
>>	Device:	Technology 1275 M
>>	Rev:	1.35
>>	Class:	Block Device
>>	Subclass:0x0000
>>	Flags:	CPM
>>Target ID 14.
>>	Vendor:	PROMISE TECH.
>>	Device:	I2O RAID DEVICE
>>	Rev:	V1.0.0
>>	Class:	Block Device
>>	Subclass:0x0000
>>	Flags:	PM
>>Target ID 15.
>>	Vendor:	WD
>>	Device:	AC31200F
>>	Rev:	14.04E28
>>	Class:	Block Device
>>	Subclass:0x0000
>>	Flags:	CPM
>>I2O Configuration Manager v 0.04
>>        (c) Copyright 1999 Read Hat Software
>>I2O Block Storage OSM v0.9
>>        (c) Copyright 1999, 2000 Read Hat Software.
>>i2o/iop0: No handler for event (0x02000000)
>>i2o_block: Controller 0 TID 14
>>Device Refused Claim! Skipping Installation

That is last line on console. Nothing of this actually make it
to the syslog.

Thanks   David



ksymoops 2.3.7 on i686 2.4.2-ac1.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.2-ac1/ (default)
     -m /boot/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod
file?
invalid operand: 0000
CPU:       0
EIP:       0010:[<c01110e4>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 0000001b  ebx: c7f99760  ecx: 00000001  edx: c02477c8
esi: 0000c204  edi: c025a000  ebp: c025beac  esp: c025be7c
Process swapper(pid:0, stackpage=c0259000)
Stack: c01fa2ab c01fa416 000002c3 c7f99760 0000c204 c1272af8 00000044
00000082
       00000000 c7f99760 00000000 c01b3bce c1272aa0 c01b3c6c c7f99760
c7f99760
       00000001 00000053 c01b385f c7f99760 c7f99760 c0255640 00000001
c029272a
Call Trace: [<c01b3bce>] [<c01b3c6c>] [<c01b385f>] [<c01b4f44>]
[<c01b4f76>] [<c011b0fe>] [<c011b4bf>] [<c0189a0d>]
[<c0189aa1>] [<c01894f9>] [<c018a49d>] [<c018a50f>]
[<c0109f6d>] [<c010a0ce>] [<c0107120>] [<c0107120>]
[<c0108e00>] [<c0107120>] [<c0107120>] [<c0100018>]
[<c0107143>] [<c01071a9>] [<c0105000>] [<c0100191>]
Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56

>>EIP; c01110e4 <schedule+388/394>   <=====
Trace; c01b3bce <i2o_status_get+52/100>
Trace; c01b3c6c <i2o_status_get+f0/100>
Trace; c01b385f <i2o_quiesce_controller+f/7c>
Trace; c01b4f44 <i2o_reboot_event+28/94>
Trace; c01b4f76 <i2o_reboot_event+5a/94>
Trace; c011b0fe <notifier_call_chain+1e/38>
Trace; c011b4bf <ctrl_alt_del+17/38>
Trace; c0189a0d <boot_it+5/8>
Trace; c0189aa1 <do_spec+31/34>
Trace; c01894f9 <handle_scancode+28d/2c8>
Trace; c018a49d <handle_kbd_event+111/174>
Trace; c018a50f <keyboard_interrupt+f/14>
Trace; c0109f6d <handle_IRQ_event+35/60>
Trace; c010a0ce <do_IRQ+6e/b0>
Trace; c0107120 <default_idle+0/28>
Trace; c0107120 <default_idle+0/28>
Trace; c0108e00 <ret_from_intr+0/20>
Trace; c0107120 <default_idle+0/28>
Trace; c0107120 <default_idle+0/28>
Trace; c0100018 <startup_32+18/139>
Trace; c0107143 <default_idle+23/28>
Trace; c01071a9 <cpu_idle+41/54>
Trace; c0105000 <empty_bad_page+0/1000>
Trace; c0100191 <L6+0/2>
Code;  c01110e4 <schedule+388/394>
00000000 <_EIP>:
Code;  c01110e4 <schedule+388/394>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c01110e6 <schedule+38a/394>
   2:   8d 65 dc                  lea    0xffffffdc(%ebp),%esp
Code;  c01110e9 <schedule+38d/394>
   5:   5b                        pop    %ebx
Code;  c01110ea <schedule+38e/394>
   6:   5e                        pop    %esi
Code;  c01110eb <schedule+38f/394>
   7:   5f                        pop    %edi
Code;  c01110ec <schedule+390/394>
   8:   89 ec                     mov    %ebp,%esp
Code;  c01110ee <schedule+392/394>
   a:   5d                        pop    %ebp
Code;  c01110ef <schedule+393/394>
   b:   c3                        ret
Code;  c01110f0 <__wake_up+0/a8>
   c:   55                        push   %ebp
Code;  c01110f1 <__wake_up+1/a8>
   d:   89 e5                     mov    %esp,%ebp
Code;  c01110f3 <__wake_up+3/a8>
   f:   83 ec 10                  sub    $0x10,%esp
Code;  c01110f6 <__wake_up+6/a8>
  12:   57                        push   %edi
Code;  c01110f7 <__wake_up+7/a8>
  13:   56                        push   %esi


2 warnings issued.  Results may not be reliable.

RE: i2o & Promise SuperTrak100

[David Priban]

> Run it through ksymoops and I might be able to guess what went wrong.
>
> In theory however i2o is a standard and all i2o works alike. In
> practice i2o
> is a pseudo standard and nobody seems to interpret the spec the
> same way, the
> implementations all tend to have bugs and the hardware sometimes does too.
>
If I enable DRIVERDEBUG in i2o_core.c it makes the freeze to go away and
kernel
loads just fine. I do get bunch of I/O errors on mounted array but this may
be due to crappy HD's I'm using for testing.

David

Re: i2o & Promise SuperTrak100

[Andrew Morton]

David Priban wrote:
> 
> > > Kernel panic: Aiee, killing interrupt handler !
> > > In interrupt handler - not syncing
> >
> > Run it through ksymoops and I might be able to guess what went wrong.
> >
> > In theory however i2o is a standard and all i2o works alike. In
> > practice i2o
> > is a pseudo standard and nobody seems to interpret the spec the
> > same way, the
> > implementations all tend to have bugs and the hardware sometimes does too.
> >
> Alan,
> This is what ksymoops gave me. One thing I didn't mention before:
> kernel panics when I hit Ctrl-Alt-Del after it hangs telling me this:
> 

This untested patch should fix the scheduling-in-interrupt
thing.


--- kernel/sys.c.orig	Thu Mar  1 10:06:14 2001
+++ kernel/sys.c	Thu Mar  1 10:07:43 2001
@@ -330,6 +330,12 @@
 	return 0;
 }
 
+static void deferred_cad(void *dummy)
+{
+	notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
+	machine_restart(NULL);
+}
+
 /*
  * This function gets called by ctrl-alt-del - ie the keyboard interrupt.
  * As it's called within an interrupt, it may NOT sync: the only choice
@@ -337,10 +343,13 @@
  */
 void ctrl_alt_del(void)
 {
-	if (C_A_D) {
-		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
-		machine_restart(NULL);
-	} else
+	static struct tq_struct cad_tq = {
+		routine: deferred_cad,
+	};
+
+	if (C_A_D)
+		schedule_task(&cad_tq);
+	else
 		kill_proc(1, SIGINT, 1);
 }
 	
-

Re: i2o & Promise SuperTrak100

[Alan Cox]

> If I enable DRIVERDEBUG in i2o_core.c it makes the freeze to go away and
> kernel
> loads just fine. I do get bunch of I/O errors on mounted array but this may
> be due to crappy HD's I'm using for testing.

Umm that sounds like it might be timing. That could be a pain

Re: i2o & Promise SuperTrak100

[Jens Axboe]

On Tue, Feb 27 2001, Alan Cox wrote:
> In theory however i2o is a standard and all i2o works alike. In practice i2o
> is a pseudo standard and nobody seems to interpret the spec the same way, the
> implementations all tend to have bugs and the hardware sometimes does too.

That's a pretty good description of standards in general, at least
when it comes to hardware :-)

-- 
Jens Axboe

Re: i2o & Promise SuperTrak100

[David Priban]

On Wed, 28 Feb 2001, Andrew Morton wrote:

> This untested patch should fix the scheduling-in-interrupt
> thing.
> 
> 
> --- kernel/sys.c.orig	Thu Mar  1 10:06:14 2001
> +++ kernel/sys.c	Thu Mar  1 10:07:43 2001
> @@ -330,6 +330,12 @@

Yes, this fixed the oops. Now it's possible to ctrl-alt-del reboot
when i2o_block hangs. It still happens four times out of five reboots
meaning it is intermittent. (Timing as Alan mentioned - goes away when
DEBUG enabled) I have to put in some better HD's and test stability 
of the filesystem on this device. Any suggestions what's best way to
do it to get some meaningful results?

Thanks David

Re: i2o & Promise SuperTrak100

[David Woodhouse]

On Wed, 28 Feb 2001, Alan Cox wrote:

> Umm that sounds like it might be timing. That could be a pain

Timing-related problems in code using sleep_on(). Film at 11. :)

-- 
dwmw2

Re: i2o & Promise SuperTrak100

[Alan Cox]

> On Wed, 28 Feb 2001, Alan Cox wrote:
> 
> > Umm that sounds like it might be timing. That could be a pain
> Timing-related problems in code using sleep_on(). Film at 11. :)

No

Re: i2o & Promise SuperTrak100

[Alan Cox]

> While you are at it, can you bug them for FastTrak (the software RAID thing)
> support?

At some point. They seem very keen not to co-operate on the fasttrak so its
probably best to avoid motherboards that have the fasttrak chipset and tell
the board vendor why.

Alan

Re: i2o & Promise SuperTrak100

[Andrew Chan]

While you are at it, can you bug them for FastTrak (the software RAID thing)
support?

Their drivers are ages behind and Andre doesn't seem to be able to get them
cooperate either.

I have many many boards with their FastTrak chip on and I cannot use it
either as FastTrak or even simple ATA100 controller. I'd happy if I can use
it even as simple ATA100 controller.

Andrew Chan

==

Alan Cox says:

I've been talking constructively to promise about the i2o on the supertrak
not working straight off with the kernel i2o driver. Currently it looks
promising

Re: i2o & Promise SuperTrak100

[Chris]

>>>>> "AC" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    >> I tried talking to Promise recently to get a sample SuperTrak
    >> to make this work, but no such luck. So bother Promise and ask
    >> what they intend to do about it.

    AC> I've been talking constructively to promise about the i2o on
    AC> the supertrak not working straight off with the kernel i2o
    AC> driver. Currently it looks promising

Pun intended? :)   Anyways, I too am interested hearing how this
goes.  If it isn't going to work out, I'm going to figure out how snip
the PCI line ID'ing it as a RAID.  If Promise comes through, then I
don't have to mutilate the card. :)

-- 
Chris Bayly

Email:  Chris.Bayly@UAlberta.CA         | CNS, UNIX Support
                                        | 151 General Services Building
                                        | University of Alberta
Web:    http://www.ualberta.ca/~cbayly/ | Edmonton, Alberta 
                                        | Canada T6G 2S7

Re: i2o & Promise SuperTrak100

[Joao Paulo Martins]

Jens Axboe wrote:
> 
> On Tue, Apr 10 2001, Alan Cox wrote:
> > > >   I purchase a Promise SuperTrak100 RAID controler and
> > > [snip, SuperTrak not working]
> > >
> > > I tried talking to Promise recently to get a sample SuperTrak to
> > > make this work, but no such luck. So bother Promise and ask what
> > > they intend to do about it.
> >
> > I've been talking constructively to promise about the i2o on the supertrak
> > not working straight off with the kernel i2o driver. Currently it looks
> > promising
> 
> Good, glad someone is having more luck than I. I'd love to see it
> work, hence my interest in getting it working.
> 
> --
> Jens Axboe

Let's hope for Alan Cox luck with Promise.
I'd love to see it working too, I made some investements to bild a
raid5
array based on the linux support "promise".
--
Joao Martins.

Re: i2o & Promise SuperTrak100

[Jens Axboe]

On Tue, Apr 10 2001, Alan Cox wrote:
> > > 	I purchase a Promise SuperTrak100 RAID controler and
> > [snip, SuperTrak not working]
> > 
> > I tried talking to Promise recently to get a sample SuperTrak to
> > make this work, but no such luck. So bother Promise and ask what
> > they intend to do about it.
> 
> I've been talking constructively to promise about the i2o on the supertrak
> not working straight off with the kernel i2o driver. Currently it looks
> promising

Good, glad someone is having more luck than I. I'd love to see it
work, hence my interest in getting it working.

-- 
Jens Axboe

Re: i2o & Promise SuperTrak100

[Alan Cox]

> > 	I purchase a Promise SuperTrak100 RAID controler and
> [snip, SuperTrak not working]
> 
> I tried talking to Promise recently to get a sample SuperTrak to
> make this work, but no such luck. So bother Promise and ask what
> they intend to do about it.

I've been talking constructively to promise about the i2o on the supertrak
not working straight off with the kernel i2o driver. Currently it looks
promising

Re: i2o & Promise SuperTrak100

[Jens Axboe]

On Mon, Apr 09 2001, Joao Paulo Martins wrote:
> Hi,
> 
> 	I purchase a Promise SuperTrak100 RAID controler and

[snip, SuperTrak not working]

I tried talking to Promise recently to get a sample SuperTrak to
make this work, but no such luck. So bother Promise and ask what
they intend to do about it.

-- 
Jens Axboe

i2o & Promise SuperTrak100

[Joao Paulo Martins]

Hi,

	I purchase a Promise SuperTrak100 RAID controler and
installed on a PIII dual with latest kernel 2.4.3. It didn't
work, so I searched the linux-kernel achives and found an exact
discription of my problem by David Priban on Feb. 27 2001
(http://www.uwsg.iu.edu/hypermail/linux/kernel/0102.3/0037.html).
Andrew Morton and Alan Cox gave an hand. I follow hte hists
and advance a bit, and as David, now I get a bunch of I/O errors
on mounted array. After this there was a sugestion of timing problems,
but the issue ended with no solution.

	Could any one help me, please!
	Let me thank you in advance for any help.

	I have no problem starting the i2o_block modules, I can
run a create a partition, but when I try to make a file system
I get a lot of I/O erros:

	> modprobe i2o_block
	> fdisk /dev/i2o/hd/disc0/disc
	> mkreiserfs /dev/i2o/hd/disc0/part1

syslog:

Linux I2O PCI support (c) 1999 Red Hat Software. 
I2O Core - (C) Copyright 1999 Red Hat Software 
i2o: Checking for PCI I2O controllers... 
i2o: I2O controller on bus 1 at 25. 
i2o: PCI I2O controller at 0xFE000000 size=4194304 
i2o/iop0: Installed at IRQ22 
i2o: 1 I2O controller found and installed. 
I2O: Event thread created as pid 1029 
Activating I2O controllers... 
This may take a few minutes if there are many devices 
i2o/iop0: Reset rejected, trying to clear 
i2o/iop0: LCT has 10 entries. 
i2o/iop0: Configuration dialog desired. 
Target ID 0. 
    Device: IxWorks 
      Rev: 0201     
  Class: Executive             
Subclass: 0x0001 
      Flags: PM 
Target ID 8. 
     Vendor: PROMISE TECH.    
     Device: I2O RAID ISM     
        Rev: V1.0.0   
    Class: Device Driver Module  
  Subclass: 0x0021 
     Flags: PM 
Target ID 9. 
     Vendor: PROMISE TECH.    
     Device: I2O IDE HDM      
        Rev: 0.02     
    Class: Device Driver Module  
  Subclass: 0x0020 
     Flags: PM 
Target ID 10. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 12. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 13. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 14. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 15. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 16. 
     Vendor: VENDOR-UNKNOWN   
     Device: IBM-DTLA-307060  
        Rev: TX8OA50C 
    Class: Block Device          
  Subclass: 0x0000 
     Flags: CPM 
Target ID 17. 
     Vendor: PROMISE TECH.    
     Device: I2O RAID DEVICE  
        Rev: V1.0.0   
    Class: Block Device          
  Subclass: 0x0000 
     Flags: PM 
i2o/iop0: No handler for event (0x02000000) 
I2O Block Storage OSM v0.9 
   (c) Copyright 1999, 2000 Red Hat Software. 
i2o_block: registered device at major 80 
i2ob: Installing tid 17 device at unit 0 
Max Segments set to 12 
Byte limit is 6144. 
i2o/hda: Type 1- 293220Mb, 512 byte sectors. 
i2o/hda: Maximum sectors/read set to 255. 
 i2o/hda: p1 
devfs: devfs_register(disc): NULL ops, got d0c18ef0 from major table 
 
/dev/i2o/hda error: Device is not ready 
end_request: I/O error, dev 50:00 (i2o block), sector 22600 
 
/dev/i2o/hda error: Device is not ready 
end_request: I/O error, dev 50:00 (i2o block), sector 22600 

(errors repeat many times)



-- 
------------------------------------------------------------------
Joao Martins                            martinsj@lip.pt
Av. Elias Garcia, 14-1                  Tel: +351 21 797 3880
1000-149 Lisboa Portugal                Fax: +351 21 793 4631