I had tried 6.1.8 + 2.4.3 and had problems which included messages like
'aic7xxx_abort returns 8194' and machine froze up shortly after X started.
This on redhat 7.0. Sorry but since I was unable to even boot back the
prev kernel (2.4.0) I cant provide any more detailed information. I have
been following to see a few other folks have had some issues with scsi as well.
I have 2 lvd scsi disks and one ide, AH 2940U2 - top of lilo included below -
and bios boot order is scsi first.
So I started again - installed redhat 7.0.9.
took 2.4.4-pre1 and patched it with
linux-aic7xxx-6.1.10-2.4.3.patch
Patch applied cleanly but when I compile it complains a little:
In file included from aic7xxx_linux.c:131:
aic7xxx_osm.h: In function `ahc_pci_read_config':
aic7xxx_osm.h:862: warning: control reaches end of non-void function
(for several .c files but always refers to 'ahc_pci_read_config')
In file included from ... include/linux/raid/md.h:50,
from init/main.c:24: ..include/linux/raid/md_k.h: In function `pers_to_level':
raid/md_k.h:39: warning: control reaches end of non-void function
Do I need to be concerned here? I dont whether the presumed missing return is
a bad thing or not.
I have not yet tried to boot this kernel.
Also
# lilo.conf
boot=/dev/sda
disk=/dev/sda
bios=0x80
disk=/dev/sdb
bios=0x81
disk=/dev/hda
bios=0x82
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
lba32
default=linux
...
> So I started again - installed redhat 7.0.9.
> took 2.4.4-pre1 and patched it with
> linux-aic7xxx-6.1.10-2.4.3.patch
>
> Patch applied cleanly but when I compile it complains a little:
>
> In file included from aic7xxx_linux.c:131:
> aic7xxx_osm.h: In function `ahc_pci_read_config':
> aic7xxx_osm.h:862: warning: control reaches end of non-void function
>
> (for several .c files but always refers to 'ahc_pci_read_config')
This is because panic() is not marked as a "no return" function. So,
GCC compains that, in the panic() case, we don't return a value from
this particular function. Since we will never return in that case,
it is, at least in the aic7xxx driver, a harmless warning.
--
Justin
On 04.08 Justin T. Gibbs wrote:
> >
> > In file included from aic7xxx_linux.c:131:
> > aic7xxx_osm.h: In function `ahc_pci_read_config':
> > aic7xxx_osm.h:862: warning: control reaches end of non-void function
>
> This is because panic() is not marked as a "no return" function. So,
linux/include/linux/kernel.h +38:
# define NORET_TYPE /**/
# define ATTRIB_NORET __attribute__((noreturn))
# define NORET_AND noreturn,
..
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2)));
^^^^^^^^^
Similar cases, compare include/linux/raid/md_k.h:pers_to_level() in
2.4.3 and 2.4.3-ac3.
--
J.A. Magallon # Let the source
mailto:[email protected] # be with you, Luke...
Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686
>NORET_TYPE void panic(const char * fmt, ...)
> __attribute__ ((NORET_AND format (printf, 1, 2)));
> ^^^^^^^^^
>
>Similar cases, compare include/linux/raid/md_k.h:pers_to_level() in
>2.4.3 and 2.4.3-ac3.
Then gcc is not honoring the attribute. The only way for that
function to not return with a value is in the panic case and that
cannot happen.
--
Justin
I used 5000ms. I still freeze up with 2.4.3 + 6.1.10.
Unfortunately i could not see any messages and nothing got logged.
This time an fsck allowed me to boot back to 2.4.1.
The visible symptoms were the same as before (2.4.3 + 6.1.8) but this time I was
unable to flip virtual consoles before the freeze so I dont even
know 100% what is causing it - it boots fine - and the scsi driver
makes no complaints - it all looks normal. X starts up and I can login.
it starts ok and windows start popping up - shortly thereafter it freezes
- just like before.
I will try investigate further and see if I can get any more log messages.
Is there any debug boot option or compile flag that will help me find out more
what is going on?
/var/log/messages says this about scsi.
Apr 7 19:56:13 snap kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.10
Apr 7 19:56:13 snap kernel: <Adaptec 2940 Ultra2 SCSI adapter>
Apr 7 19:56:13 snap kernel: aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs
Apr 7 19:56:13 snap kernel:
Apr 7 19:56:13 snap kernel: Vendor: YAMAHA Model: CRW8424S Rev: 1.0d
Apr 7 19:56:13 snap kernel: Type: CD-ROM ANSI SCSI revision: 02
Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LW Rev: 0001
Apr 7 19:56:13 snap kernel: Type: Direct-Access ANSI SCSI revision: 02
Apr 7 19:56:13 snap kernel: (scsi0:A:5): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LW Rev: 0001
Apr 7 19:56:13 snap kernel: Type: Direct-Access ANSI SCSI revision: 02
Apr 7 19:56:13 snap kernel: (scsi0:A:6): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Apr 7 19:56:13 snap kernel: scsi0:0:5:0: Tagged Queuing enabled. Depth 253
Apr 7 19:56:13 snap kernel: scsi0:0:6:0: Tagged Queuing enabled. Depth 253
Well my aicxxx problems continue:
I did it again and indeed verified similar error messages as I had
under stock 2.4.3 and 2.4.3+aic 6.1.8. This time it died during boot itself
starting with complaints from ssh/xinet et al - then I started seeing the
scsi errors. (I believe I had also tried ac26 with similar problems hwhich IIRC
is 6.1.5).
Anyway, it goes around in a loop with stuff like:
SCB 1 ...
scsi ...
scsi ... recovery complete ..
scsi ... code aweke ..
scsi ... aic7xxx_abort returns 8194
or somwething similar. The aic7xxx_abort returns 8194 i remember exactly the others
I'm a bit shaky on. Anyway it seems to loop with the recovery/abort thing.
What can I do to help track down the problem?
Regards,
Gene/
-------------------------------------------------------------------
I enclose output of ver_linux - I note that it incorrectly reports util-linux
becuase it uses mount --version. On my redhat system mount is 2.10r while util-linux
is 2.10s-11.
Linux snap 2.4.1-0.1.9 #1 Wed Feb 14 22:15:15 EST 2001 i686 unknown
Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.91.0.2
util-linux 2.10r
modutils 2.4.5
e2fsprogs 1.19
reiserfsprogs 3.x.0b
pcmcia-cs 3.1.22
PPP 2.4.0
Linux C Library 2.2.2
Dynamic linker (ldd) 2.2.2
Procps 2.0.7
Net-tools 1.57
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded emu10k1 soundcore autofs joydev hid input 3c59x ipchains ide-scsi ide-cd cdrom usb-uhci usbcore aic7xxx sd_mod scsi_mod
-------------------------------------------------------------------
On Sun, Apr 08, 2001 at 12:11:32AM -0400, [email protected] wrote:
>
> I used 5000ms. I still freeze up with 2.4.3 + 6.1.10.
>
> ...
>Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LW Rev:
> 0001
I seem to recall this being a very buggy firmware version. You should
check with Seagate to see if they have something new. If this is the
firmware I'm thinking of, the driver should perform correctly if you
disable write caching. You can do this via the SCSI-Select menu for
the controller.
--
Justin
Justin:
Ya think very buggy? I checked seagate web page and
unfortunately was unable to find any firmware updates
for the barracuda drives.
Curious tho that this has worked flawlessly for well over a
year with all prior version of linux and win2000 as well.
Also a few other folks seem to have similar problems with
newer kernels.
Do the newer drivers put a bigger demand on the drives that
might start to uncover the problems previously not seen?
I did find newer firmware for the adaptec 2940u2w card
tho so perhaps I should upgrade that?
I will try turning off write cache - kernel config option right?
Will report back.
Thanks for your help - it sure would be nice to be able to
run with the newer kernels again!
Regards,
Gene/
On Mon, Apr 09, 2001 at 03:19:55PM -0600, Justin T. Gibbs wrote:
> >Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LW Rev:
> > 0001
>
> I seem to recall this being a very buggy firmware version. You should
> check with Seagate to see if they have something new. If this is the
> firmware I'm thinking of, the driver should perform correctly if you
> disable write caching. You can do this via the SCSI-Select menu for
> the controller.
>
> --
> Justin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>Justin:
>
>Ya think very buggy? I checked seagate web page and
>unfortunately was unable to find any firmware updates
>for the barracuda drives.
I'm pretty sure you need to be up to at leaset 0005 of
the firmware to stabilize this drive.
>Curious tho that this has worked flawlessly for well over a
>year with all prior version of linux and win2000 as well.
>Also a few other folks seem to have similar problems with
>newer kernels.
It all depends on the access pattern. The drive will only
fail if you fill its write cache. At that point, it will
fall off the bus, never to return.
>Do the newer drivers put a bigger demand on the drives that
>might start to uncover the problems previously not seen?
Depends on your settings. If you are using the default, we
run a much larger number of concurrent transactions when
compared to the old driver.
>I did find newer firmware for the adaptec 2940u2w card
>tho so perhaps I should upgrade that?
If you aren't having problems with your BIOS today, there is
no reason to flash the BIOS on teh 2940U2W.
>I will try turning off write cache - kernel config option right?
SCSI-Select option.
--
Justin
On Tue, Apr 10, 2001 at 08:00:19AM -0600, Justin T. Gibbs wrote:
> >
> I'm pretty sure you need to be up to at leaset 0005 of
> the firmware to stabilize this drive.
FYI, I contacted seagate and they say the firmware is the latest.
Regards,
Gene/