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 con
> "AC" == Alan Cox <[EMAIL PROTECTED]> 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
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
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 a
> > 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 p
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 a
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/01
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
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-d
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 des
> 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
-
To unsubscribe from thi
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 pseu
> 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 some
> > 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 interpr
> c029072a
> Call Trace:
> [] [] [] []
> [] [] [] []
> [] [] [] []
> [] [] [] []
> [] [] [] []
> [] [] [] []
> 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 m
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:
17 matches
Mail list logo
