Hi,
I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
It doesn't work on my Alpha (hangs the machine on boot) and I'm trying to find
out whether its an Alpha-specific issue or not, as I can't try the card in
another machine as it's in production.
I've also got the same problem with 2.6.5 (and newer) - but I think this is a
known issue with 2.6?
Thanks,
David.
--
David Johnson
http://www.david-web.co.uk/
On Apr-26 2004, Mon, 15:32 +0100
David Johnson <[email protected]> wrote:
> I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
>
> It doesn't work on my Alpha (hangs the machine on boot) and I'm trying to find
> out whether its an Alpha-specific issue or not, as I can't try the card in
> another machine as it's in production.
>
> I've also got the same problem with 2.6.5 (and newer) - but I think this is a
> known issue with 2.6?
x86: both 2.4.26 and 2.6.6-rc2 work ok for me using aic7xxx.
The controllers driven are
00:10.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
00:12.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
--
Tomas Szepe <[email protected]>
On Mon, 26 Apr 2004, David Johnson wrote:
> I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
I've seen bogus and fruitless bus and host adaptor resets at kernel-boot
with sym53c8xx_2 with a recent 2.4-BK (the last that I could compile, I
cannot compile the current 2.4 BK tree at all for unknown reasons. 2.6
is fine), i386.
> I've also got the same problem with 2.6.5 (and newer) - but I think this is a
> known issue with 2.6?
Not using aic7xxx on 2.6, 2.6.6-rc2 is fine for me.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
On Mon, Apr 26, 2004 at 03:32:37PM +0100, David Johnson wrote:
> I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
Yep, no problems at all. Upgraded this weekend from 2.4.23 to 2.4.26, and
it Just Worked(tm):
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 15 for device 00:09.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec 19160B Ultra160 SCSI adapter>
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
(scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Vendor: QUANTUM Model: ATLAS_V__9_WLS Rev: 0200
Type: Direct-Access ANSI SCSI revision: 03
Vendor: QUANTUM Model: ATLAS_V__9_WLS Rev: 0200
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 64
scsi0:A:6:0: Tagged Queuing enabled. Depth 64
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
SCSI device sda: 17930694 512-byte hdwr sectors (9181 MB)
Partition check:
sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 >
SCSI device sdb: 17930694 512-byte hdwr sectors (9181 MB)
sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 >
--
Jurjen Oskam
"Avoid putting a paging file on a fault-tolerant drive, such as a mirrored
volume or a RAID-5 volume. Paging files do not need fault-tolerance." - Q308417
On Mon, Apr 26, 2004 at 06:10:04PM +0200, Matthias Andree wrote:
> On Mon, 26 Apr 2004, David Johnson wrote:
>
> > I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
>
> I've seen bogus and fruitless bus and host adaptor resets at kernel-boot
> with sym53c8xx_2 with a recent 2.4-BK (the last that I could compile, I
> cannot compile the current 2.4 BK tree at all for unknown reasons. 2.6
> is fine), i386.
What is the compile error with 2.4-BK-current?
Did you post the boot messages with sym53c8xx_2? Can you use sym53c8xx?
>
> > I've also got the same problem with 2.6.5 (and newer) - but I think this is a
> > known issue with 2.6?
>
> Not using aic7xxx on 2.6, 2.6.6-rc2 is fine for me.
On Mon, Apr 26, 2004 at 03:32:37PM +0100, David Johnson wrote:
> Hi,
>
> I was wondering if anyone had aic7xxx SCSI working with kernel 2.4.26?
>
> It doesn't work on my Alpha (hangs the machine on boot) and I'm trying to find
> out whether its an Alpha-specific issue or not, as I can't try the card in
> another machine as it's in production.
>
> I've also got the same problem with 2.6.5 (and newer) - but I think this is a
> known issue with 2.6?
Hi David,
Can you post save the boot messages and post? Which 2.4/2.6 works on this box?
What are the boot messages with 2.6.5 and newer?
On Tuesday 27 Apr 2004 14:21, Marcelo Tosatti wrote:
>
> Hi David,
>
> Can you post save the boot messages and post?
I'm not sure - I'll try to find out.
> Which 2.4/2.6 works on this box?
2.4.24 and earlier works, but I haven't tried 2.4.25. I haven't found a 2.6
that works but I haven't tried anything older than 2.6.5.
>
> What are the boot messages with 2.6.5 and newer?
I'm afraid I don't have these, but will try to get them. There are no errors
or anything out of the ordinary, it just hangs when it gets to finding the
SCSI devices.
I've got a bug report (http://bugzilla.kernel.org/show_bug.cgi?id=2517) which
has my dmesg from 2.4.24 and I've noted in it where 2.4.26 hangs.
2.6.5 (and newer) hangs in exactly the same place with either the old or new
driver, again with no errors.
I know this is isn't a lot to go on, but it's difficult to play with it as its
in production. Let me know what you'd like me to do next and I'll try to do
it. Shall I compile in the driver's debugging stuff?
Thanks,
David.
--
David Johnson
http://www.david-web.co.uk/
On Tue, 27 Apr 2004, Marcelo Tosatti wrote:
> What is the compile error with 2.4-BK-current?
Well, it used to be one that went away after I typed:
cp .config /tmp
make distclean
bk -Ur get -S # <- this checked out dozens of include files
mv /tmp/.config .
make oldconfig dep
make bzImage modules
The problem was:
(1) glibc-devel (SuSE Linux) installs includes into /usr/include/linux.
These are older includes (UTS_RELEASE 2.4.20, LINUX_VERSION_CODE
132116).
(2) BK had removed some of the include files in the course of a "bk pull"
(3) "make dep" and the kernel stuff picked up the stale includes from
/usr/include/linux instead of /space/BK/linux-2.4/include/...
Apparently, the (relative) include/ directory has precedence, but
the kernel build system falls back to looking in /usr/include/linux.
I don't know the kernel build system well enough to make a qualified
comment why this happened, might have been missing dependencies, missing
paths relative to the kernel source directory or something, or might be
the use of VPATH where it shouldn't be used or with too broad paths.
sym53c8xx_2 is also fine currently, I'm using it for my system disk as I
am writing this. This problem started earlier than compile errors
(incompatibly redefined symbols and such), so it may have had some stale
include files already but not enough to jam the build.
> Did you post the boot messages with sym53c8xx_2? Can you use sym53c8xx?
No, I didn't because I wasn't confident it was my own fault.
I haven't used ncr53c8xx or sym53c8xx in ages and don't intend to.
So everything is fine for me - except that this may happen to everyone
again at any time unless the build system is fixed to that make can
"get" (as in bk get) the include files.
Someone posted patches to fix this some weeks ago, but the patches
apparently fell on the floor unheeded, I don't recall if this was for
2.4 or 2.6.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
On 27 abr 2004, at 16:26, Matthias Andree wrote:
> On Tue, 27 Apr 2004, Marcelo Tosatti wrote:
>
>> What is the compile error with 2.4-BK-current?
>
> Well, it used to be one that went away after I typed:
>
> cp .config /tmp
> make distclean
> bk -Ur get -S # <- this checked out dozens of include files
> mv /tmp/.config .
> make oldconfig dep
> make bzImage modules
>
> The problem was:
>
> (1) glibc-devel (SuSE Linux) installs includes into /usr/include/linux.
> These are older includes (UTS_RELEASE 2.4.20, LINUX_VERSION_CODE
> 132116).
>
> (2) BK had removed some of the include files in the course of a "bk
> pull"
>
> (3) "make dep" and the kernel stuff picked up the stale includes from
> /usr/include/linux instead of /space/BK/linux-2.4/include/...
>
-nostdinc should be mandatory ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
MacOS X 10.3.3, Build 7F44, Darwin Kernel Version 7.3.0
On Tue, 27 Apr 2004, J.A.Magallon wrote:
> -nostdinc should be mandatory ?
Seems to be in use on my machine, looking at what "make" prints.
--
Matthias Andree
On Tue, 27 Apr 2004, Matthias Andree wrote:
> On Tue, 27 Apr 2004, J.A.Magallon wrote:
>
> > -nostdinc should be mandatory ?
>
> Seems to be in use on my machine, looking at what "make" prints.
OK, here's how I can reproduce my previous problems - and I start
wondering why -nostdinc is missing this time:
rm include/asm/processor.h
make
-> boom:
| gcc -D__KERNEL__ -I/space/BK/linux-2.4-dm/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
| In file included from /space/BK/linux-2.4-dm/include/linux/mm.h:4,
| from /space/BK/linux-2.4-dm/include/linux/slab.h:14,
| from /space/BK/linux-2.4-dm/include/linux/proc_fs.h:5,
| from init/main.c:15:
| /space/BK/linux-2.4-dm/include/linux/sched.h:807: error: conflicting types for `kernel_thread'
| /usr/include/asm/processor.h:428: error: previous declaration of `kernel_thread'
| make: *** [init/main.o] Fehler 1
Given that init wants stdarg.h, -nostdinc is not an option for init/main.c.
Looking further, I find that include/asm/processor.h is not listed in
.depend or .hdepend.
Looks like a mkdep problem: the .hdepend file appears to lists only
files that actually exist - and hence it will not list a dependency on
include/asm/processor.h when it's missing -- creating a hen-and-egg problem:
1. because the file isn't there, it isn't listed as a dependency, follows: #2.
2. because it isn't listed as a dependency, make will not try
to "get include/asm/processor.h", follows: #1.
I believe the "if (access(path->buffer, F_OK) == 0)" at line 204 in
scripts/mkdep.c needs to be revised, it appears overzealous for a
BitKeeper-hosted tree. Someone more familiar with kbuild-2.4 should do
that.
I am suggesting the following patch (bksend format) that fixes the issue
for me (it isn't complete, the Config.in stuff also needs support, but
it fails in much more obvious ways - i. e. it prints which file it
cannot access, whereas #includes pick up the wrong file or spew tons of
warnings, burying the actual "include file not found" message):
mkdep.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 66 insertions(+), 12 deletions(-)
This BitKeeper patch contains the following changesets:
1.1390
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: matthias.andree
# Host: gmx.de
# Root: /suse/kernel/BK/linux-2.4-dm
#
#--- 1.4/scripts/mkdep.c Sat May 4 15:53:16 2002
#+++ 1.5/scripts/mkdep.c Tue Apr 27 20:01:36 2004
#@@ -30,6 +30,7 @@
# * -isystem, -I- etc.
# */
#
#+#define _GNU_SOURCE /* for stpcpy */
# #include <ctype.h>
# #include <fcntl.h>
# #include <limits.h>
#@@ -81,6 +82,13 @@
# }
# }
#
#+static void
#+oom(void)
#+{
#+ fprintf(stderr, "mkdep: out of memory.\n");
#+ exit(1);
#+}
#+
# /*
# * Grow the configuration string to a desired length.
# * Usually the first growth is plenty.
#@@ -92,7 +100,7 @@
# size_config = 2048;
# str_config = realloc(str_config, size_config *= 2);
# if (str_config == NULL)
#- { perror("malloc config"); exit(1); }
#+ oom();
# }
# }
#
#@@ -162,7 +170,7 @@
# size_precious = 2048;
# str_precious = realloc(str_precious, size_precious *= 2);
# if (str_precious == NULL)
#- { perror("malloc"); exit(1); }
#+ oom();
# }
# }
#
#@@ -182,7 +190,57 @@
# len_precious += 3;
# }
#
#+/* Matthias Andree:
#+ * stpncpy copies at most max bytes from src to dest, adds a NUL byte
#+ * and returns a pointer to the NUL byte.
#+ * WARNING: dest must be able to hold max + 1 bytes!
#+ */
#+static char *stpn0cpy(char *dest, const char *src, size_t max)
#+{
#+ while(max) {
#+ *dest = *(src++);
#+ if (*dest == '\0')
#+ return dest;
#+ dest++;
#+ max--;
#+ }
#+ *dest = '\0';
#+ return dest;
#+}
#
#+/* Matthias Andree:
#+ * check if an SCCS/s. file corresponding to path exists.
#+ */
#+static int access_sccs(const struct path_struct *path, const char *name, const int len)
#+{
#+ char prefix[] = "SCCS/s.";
#+ size_t pfxlen = strlen(prefix), seplen;
#+ const char *lastsep = name + len;
#+ int rv;
#+ char *t, *d;
#+
#+ t = malloc(path->len + pfxlen + len + 1);
#+ if (!t)
#+ oom();
#+
#+ while(--lastsep >= name)
#+ if (*lastsep == '/')
#+ break;
#+
#+ if (lastsep < name)
#+ lastsep = name;
#+ else
#+ lastsep ++;
#+ seplen = lastsep - name;
#+
#+ d = stpn0cpy(t, path->buffer, path->len);
#+ d = stpn0cpy(d, name, seplen);
#+ d = stpcpy(d, prefix);
#+ d = stpn0cpy(d, name+seplen, len - seplen);
#+ rv = access(t, F_OK);
#+ free(t);
#+ return rv;
#+}
#
# /*
# * Handle an #include line.
#@@ -201,13 +259,13 @@
# for (i = start, path = path_array+start; i < paths; ++i, ++path) {
# memcpy(path->buffer+path->len, name, len);
# path->buffer[path->len+len] = '\0';
#- if (access(path->buffer, F_OK) == 0) {
#+ if (access(path->buffer, F_OK) == 0
#+ || access_sccs(path, name, len) == 0) {
# do_depname();
# printf(" \\\n %s", path->buffer);
# return;
# }
# }
#-
# }
#
#
#@@ -233,18 +291,14 @@
# }
#
# path_array = realloc(path_array, (++paths)*sizeof(*path_array));
#- if (!path_array) {
#- fprintf(stderr, "cannot expand path_arry\n");
#- exit(1);
#- }
#+ if (!path_array)
#+ oom();
#
# path = path_array+paths-1;
# path->len = strlen(name2);
# path->buffer = malloc(path->len+1+256+1);
#- if (!path->buffer) {
#- fprintf(stderr, "cannot allocate path buffer\n");
#- exit(1);
#- }
#+ if (!path->buffer)
#+ oom();
# strcpy(path->buffer, name2);
# if (path->len && *(path->buffer+path->len-1) != '/') {
# *(path->buffer+path->len) = '/';
#
# Diff checksum=11f9831e
# Patch vers: 1.3
# Patch type: REGULAR
== ChangeSet ==
[email protected]|ChangeSet|20020205173056|16047|c1d11a41ed024864
[email protected]|ChangeSet|20040427115253|59043
D 1.1390 04/04/27 20:05:55+02:00 [email protected] +1 -0
B [email protected]|ChangeSet|20020205173056|16047|c1d11a41ed024864
C
c mkdep.c:
c When searching paths, check for path/SCCS/s.name
c files in addition to path/name files, to have a more
c complete dependency record.
K 59773
P ChangeSet
------------------------------------------------
0a0
> [email protected]|scripts/mkdep.c|20020205174036|09708|c47e74e17b837ca3 [email protected]|scripts/mkdep.c|20040427180136|27902
== scripts/mkdep.c ==
[email protected]|scripts/mkdep.c|20020205174036|09708|c47e74e17b837ca3
[email protected]|scripts/mkdep.c|20020514005529|09830
D 1.5 04/04/27 20:01:36+02:00 [email protected] +66 -12
B [email protected]|ChangeSet|20020205173056|16047|c1d11a41ed024864
C
c Cleanup: consolidate all out-of-memory print/exit
c in a single oom() function.
c Feature: when searching for includes, also look for
c path/SCCS/s.name files.
K 27902
O -rw-rw-r--
P scripts/mkdep.c
------------------------------------------------
I32 1
#define _GNU_SOURCE /* for stpcpy */
I83 7
static void
oom(void)
{
fprintf(stderr, "mkdep: out of memory.\n");
exit(1);
}
\
D95 1
I95 1
oom();
D165 1
I165 1
oom();
I184 17
/* Matthias Andree:
* stpncpy copies at most max bytes from src to dest, adds a NUL byte
* and returns a pointer to the NUL byte.
* WARNING: dest must be able to hold max + 1 bytes!
*/
static char *stpn0cpy(char *dest, const char *src, size_t max)
{
while(max) {
*dest = *(src++);
if (*dest == '\0')
return dest;
dest++;
max--;
}
*dest = '\0';
return dest;
}
I185 33
/* Matthias Andree:
* check if an SCCS/s. file corresponding to path exists.
*/
static int access_sccs(const struct path_struct *path, const char *name, const int len)
{
char prefix[] = "SCCS/s.";
size_t pfxlen = strlen(prefix), seplen;
const char *lastsep = name + len;
int rv;
char *t, *d;
\
t = malloc(path->len + pfxlen + len + 1);
if (!t)
oom();
\
while(--lastsep >= name)
if (*lastsep == '/')
break;
\
if (lastsep < name)
lastsep = name;
else
lastsep ++;
seplen = lastsep - name;
\
d = stpn0cpy(t, path->buffer, path->len);
d = stpn0cpy(d, name, seplen);
d = stpcpy(d, prefix);
d = stpn0cpy(d, name+seplen, len - seplen);
rv = access(t, F_OK);
free(t);
return rv;
}
D204 1
I204 2
if (access(path->buffer, F_OK) == 0
|| access_sccs(path, name, len) == 0) {
D210 1
D236 4
I239 2
if (!path_array)
oom();
D244 4
I247 2
if (!path->buffer)
oom();
# Patch checksum=ea3230b5
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
On 27 abr 2004, at 20:09, Matthias Andree wrote:
> On Tue, 27 Apr 2004, Matthias Andree wrote:
>
>> On Tue, 27 Apr 2004, J.A.Magallon wrote:
>>
>>> -nostdinc should be mandatory ?
>>
>> Seems to be in use on my machine, looking at what "make" prints.
>
> Given that init wants stdarg.h, -nostdinc is not an option for
> init/main.c.
>
At least gcc3 has [v][s][n]printf and friends as builtins, and also
has __builtin_va_list,_start,_end, etc, so it looks easy to get rid of
the
stdarg.h dependency.
Easy way: create stdarg.h in kernel includes with defines to builtins.
Next step: kill printfs from linux/lib, if __builtins support the same
features (ie, kernel printfs do not have any particular % code).
Anybody knows if gcc2.95.3 has this builtins ?
I think gcc builtins are under-used in kernel...
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
MacOS X 10.3.3, Build 7F44, Darwin Kernel Version 7.3.0
On Wed, 28 Apr 2004 [email protected] wrote:
>
> At least gcc3 has [v][s][n]printf and friends as builtins, and also has
> __builtin_va_list,_start,_end, etc, so it looks easy to get rid of the
> stdarg.h dependency.
No, let's _not_ start implementing stdarg.h inside the kernel. It's just
too compiler-dependent (remember - gcc isn't even the only compiler people
use).
How about just _always_ including stdarg.h, and doing it by just making
the main Makefile add a "-include <pathname>" to the CFLAGS? We should be
able to generate the stdarg.h pathname pretty easily, with something like
gcc --print-file-name=include/stdarg.h
(and that may depend on gcc versions too, of course).
> I think gcc builtins are under-used in kernel...
They are just _way_ too unreliable. They come and go with compiler
versions, and aren't documented anywhere.
Linus
On Tue, 27 Apr 2004, Linus Torvalds wrote:
> How about just _always_ including stdarg.h, and doing it by just making
> the main Makefile add a "-include <pathname>" to the CFLAGS? We should be
> able to generate the stdarg.h pathname pretty easily, with something like
>
> gcc --print-file-name=include/stdarg.h
>
> (and that may depend on gcc versions too, of course).
stdarg.h is innocent, it is just one of the few include files valid in
the stdinc paths.
How about making sure the dependency information is complete, even when
BK has just "bk clean"ed an unedited file in the course of a "bk pull"?
Maybe mkdep or Makefile should just try to check out missing files and
mkdep barf if it cannot open a file it was given? It works for .c files,
it works for many of the .h files - it lacks for some other .h files and
for the Config.in or Kconfig files. That would leave the BK user with
just the "bk get" boot-strap at top level.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95