lkml.org 
[lkml]   [1998]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [REPORT] Adaptec and SMP problems on 2.0.35
Ricardo Galli Granada wrote:
>
> I received at leat very good comment of possible errors and workarounds
> for these problems. It seems a lot of people is suffering lockups when SMP
> and aicxxx are together (I was very surprised and feel much better now
> ;-).

To refresh some people about what the original posting was, and my comments
are interspersed among the quote in the []:

<QUOTE>
Hi all,
after having occasional (one each 150-30 days) server lockups with
2.0.34 and very often ones (one per day) with 2.0.35, I decided to stop it
and do an extensive test trying to discover the problem.

My hardware is a Intel RC440LX motherboard with two 300 MHz PII, 256 MB, one
internal 7880U Adpatec controller and a EtherPro 100 mbps. I also bought an
3Com 509 and an Adaptec 2940U board for the tests.

I tried all possible combinations of SCSI controllers and ethernets, all
results were bad and consistent, so I bet is a problem of the aic7xxx
driver.

[ The aic7xxx driver versions between 2.0.34 and 2.0.35 go from 5.0.14 to
5.0.19 BTW]

With the aic7xxx version 5.0.19 and 2.0.35, the server can't survive a
simultaneus kernel compilation and a ping flood through a 10 mbps LAN. It
took 1 to 3 compilations, but always dies without any error log, just a
blank screen and the "three finger salute" completely blocked, so I think is
a deadlock... I made this test with the internal and the external adaptec
controller, and with the internal eepro and the external 3com 509.

[ NOTE: a print-EIP patch for 2.0.35 would be helpful here, if someone has
such as beast, then could they forward me a copy - DL ]

So, I've got the 5.1.0 pre-patch7 and applied on the 2.0.35 kernel, I did
the same tests, the machine did survive, but the driver resets the scsi
every 5-10 seconds, so the it's completely useless.

I read in some mail archives that the memory configuration in lilo.conf
should MEM - 1MB to avoid problems with the BIOS (ass) hole, I also
received few weeks ago a recommendation that Alan Cox sent to someone else,
that the it's a good idea to put MEM - 10 MB to avoid some/one memory leak
in the kernel. I tried both in the lilo.conf, the machine died anyway.


Now the machine is running 2.0.35 WITHOUT SMP support, and is happy (and
slower....).

BTW and question, I also noted that the Adaptec SCSI BIOS is disabled,
should be enabled? Why is disabled if I did not change the BIOS
configuration? I saw other Linuxes that are enabled by default...

[ This is normally a problem with reading the SEEPROM on the aic7xxx
controller, so if the motherboard controller uses NVRAM to store settings
instead of a SEEPROM, then we won't be able to read it ]

If you have any comment or recommendations, please let me know it. Should I
change to BusLogic?

BTW and question 2: Does someone how to disable by hardware the internal
EEPRO and ADAPTEC in this Intel motherboard?

[ On the Intel DK440LX, which is very similar in make, there are BIOS
options to disable the controllers under advanced peripheral setup ]

</QUOTE>

> So, my question is: Doug (Ledford...), are you receiving help for
> developing the aicxxx driver? How can we help you?

A print EIP patch would help :)

> My guess is that Doug and others are much better than me for kernel
> hacking, but if I have to spend time learning it, I will do it. So if
> anyone there has some good pointers, please send them to me. At least this
> is better that just sending reports...
>
> Doug, you received some of the recommendations, what do you think? What
> the difference between the 5.0.14 driver (2.0.34 I guess) and 5.0.19 that
> changed so much the behaviour?

Nothing (I say this after having just performed a close inspection of the
5.0.14-5.0.19 diff to see what changed). Standing on it's own, the 5.0.19
driver is SMP safe as best as I can tell. However, when I was testing the
5.0.19 driver for SMP operation, I was doing so under 2.0.33. I never used
2.0.34 and only recently compiled a 2.0.35 kernel. I also don't use the
2.0.35 kernel hardly at all, I'm mainly using the 2.1.x kernels. So, the
problem here is that there might be an interaction problem between the
aic7xxx driver and something else in the kernel that has broken the driver
under 2.0.35 specifically. My testing of the 5.0.19 driver under 2.0.33
showed the driver to be very reliable, at least I could find no way to crash
the driver (I never once had it crash the entire time I used 2.0.33 + 5.0.19
on my dual PII/266 system). OTOH, since this has been brought up, I've
found that I can crash the system under 2.0.35 and 5.1.0-pre7 (haven't tried
5.0.19 or 5.0.20) but that I can't do so reliably, it just happens once in a
great while. Unfortunately, those crashes have also coincided with other
problems on my system under 2.0.35, including the kmalloc called
non-atomically from interrupt problem that traced back to md_map and some
Aiee: scheduling in interrupt messages that also appeared to trace back to
the md code. I tried to get some traces on these problems for Alan and
Stephen, but it didn't want to reproduce itself at my whim :) However, if I
could get a print-EIP patch for 2.0.35, I think I can fairly reliably
reproduce the problem given enough time :)

> Can I solve the timeout problem in 5.1.0 by changing hardware
> configuration. I read in the docs that reset problems are solved when the
> BIOS is enabled. Is it valid just for the boot reset?

For non-Ultra2 controllers, the 5.1.0-pre7 driver should already be quite
reliable.


--

Doug Ledford <dledford@dialnet.net>
Opinions expressed are my own, but
they should be everybody's.

-
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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.371 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site