2003-08-01 18:21:01

by Diffie

[permalink] [raw]
Subject: Badness in device_release at drivers/base/core.c:84


Hello folks,

Under 2.6.0-test2-mm2 keeps getting Badness in device_release at
drivers/base/core.c:84 when loading USB modules on NFORCE2 based board.

uname: Linux blaze 2.6.0-test2-mm2 #1 Thu Jul 31 13:11:05 EDT 2003 i686
unknown on Linux Slackware 9.0, GCC 3.2.2

Device '' does not have a release() function, it is broken and must be
fixed.
Badness in device_release at drivers/base/core.c:84
Call Trace:
[<c021dfd8>] kobject_cleanup+0x88/0x90
[<c02c03ff>] hub_port_connect_change+0x2af/0x330
[<c02bfcfd>] hub_port_status+0x3d/0xb0
[<c02c07bd>] hub_events+0x33d/0x3b0
[<c02c0865>] hub_thread+0x35/0xf0
[<c011b810>] default_wake_function+0x0/0x30
[<c02c0830>] hub_thread+0x0/0xf0
[<c01070c9>] kernel_thread_helper+0x5/0xc

hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x501
Device '' does not have a release() function, it is broken and
must be fixed.
Badness in device_release at drivers/base/core.c:84
Call Trace:
[<c021dfd8>] kobject_cleanup+0x88/0x90
[<c02c03ff>] hub_port_connect_change+0x2af/0x330
[<c02bfcfd>] hub_port_status+0x3d/0xb0
[<c02c07bd>] hub_events+0x33d/0x3b0
[<c02c0865>] hub_thread+0x35/0xf0
[<c011b810>] default_wake_function+0x0/0x30
[<c02c0830>] hub_thread+0x0/0xf0
[<c01070c9>] kernel_thread_helper+0x5/0xc

hub 1-0:0: debounce: port 3: delay 100ms stable 4 status
0x501
Device '' does not have a release() function, it is
broken and must be fixed.
Badness in device_release at drivers/base/core.c:84
Call Trace:
[<c021dfd8>] kobject_cleanup+0x88/0x90
[<c02c03ff>] hub_port_connect_change+0x2af/0x330
[<c02bfcfd>] hub_port_status+0x3d/0xb0
[<c02c07bd>] hub_events+0x33d/0x3b0
[<c02c0865>] hub_thread+0x35/0xf0
[<c011b810>] default_wake_function+0x0/0x30
[<c02c0830>] hub_thread+0x0/0xf0
[<c01070c9>] kernel_thread_helper+0x5/0xc

Also keep getting oops in radeon module:

[drm] Loading R200 Microcode
Unable to handle kernel NULL pointer dereference at virtual address 00000120
printing eip:
c02a8cae
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[<c02a8cae>] Not tainted VLI
EFLAGS: 00210286
EIP is at aic7xxx_proc_info+0x2e/0xc80
eax: c1bb25b0 ebx: c1bb2400 ecx: c038bb20 edx: 00000000
esi: 00000400 edi: f1715000 ebp: 412de000 esp: f620fecc
ds: 007b es: 007b ss: 0068
Process nautilus (pid: 3555, threadinfo=f620e000 task=f6216720)
Stack: 000001f7 00000000 00000000 c013c612 c0379eb0 00000000 00000000 f6613340
00000000 00000000 c0379eb0 00000400 00000400 f1715000 412de000 c02956fc
c1bb2400 f1715000 f620ff60 00000000 00000400 00000000 c02956c0 c018bc91
Call Trace:
[<c013c612>] __alloc_pages+0x92/0x320
[<c02956fc>] proc_scsi_read+0x3c/0x60
[<c02956c0>] proc_scsi_read+0x0/0x60
[<c018bc91>] proc_file_read+0xd1/0x280
[<c015617c>] vfs_read+0xbc/0x130
[<c0156452>] sys_read+0x42/0x70
[<c01091f7>] syscall_call+0x7/0xb
Code: 53 83 ec 2c a1 b8 a6 38 c0 89 44 24 20 8b 98 20 01 00 00 85 db 74
1e 8d b6 00 00 00 00 8b 54 24 20 8b 92 1c 01 00 00 89 54 24 20 <8b> 8a
20 01 00 00 85 c9 75 e8 8b 54 24 20 85 d2 0f 84 e4 0b 00

There also seems to be a problem with SCSI subsystem where /dev/sda
devices are labeled as /dev/sdb as seen in the dmesg.txt attached file.

Regards,

Paul B.


Attachments:
(No filename) (0.00 B)
(No filename) (189.00 B)
Download all attachments

2003-08-01 21:34:20

by Greg KH

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Fri, Aug 01, 2003 at 02:22:07PM -0400, Diffie wrote:
>
> Under 2.6.0-test2-mm2 keeps getting Badness in device_release at
> drivers/base/core.c:84 when loading USB modules on NFORCE2 based board.
>
> uname: Linux blaze 2.6.0-test2-mm2 #1 Thu Jul 31 13:11:05 EDT 2003 i686
> unknown on Linux Slackware 9.0, GCC 3.2.2
>
> Device '' does not have a release() function, it is broken and must be
> fixed.
> Badness in device_release at drivers/base/core.c:84
> Call Trace:
> [<c021dfd8>] kobject_cleanup+0x88/0x90
> [<c02c03ff>] hub_port_connect_change+0x2af/0x330
> [<c02bfcfd>] hub_port_status+0x3d/0xb0
> [<c02c07bd>] hub_events+0x33d/0x3b0
> [<c02c0865>] hub_thread+0x35/0xf0
> [<c011b810>] default_wake_function+0x0/0x30
> [<c02c0830>] hub_thread+0x0/0xf0
> [<c01070c9>] kernel_thread_helper+0x5/0xc

The USB warnings should all be fixed up with the patches I just sent to
Linus, so you can safely ignore them for now.

As for the oops, I have no idea, sorry.

thanks,

greg k-h

2003-08-01 21:57:05

by Andrew Morton

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

Diffie <[email protected]> wrote:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000120
> printing eip:
> c02a8cae
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> CPU: 0
> EIP: 0060:[<c02a8cae>] Not tainted VLI
> EFLAGS: 00210286
> EIP is at aic7xxx_proc_info+0x2e/0xc80
> eax: c1bb25b0 ebx: c1bb2400 ecx: c038bb20 edx: 00000000
> esi: 00000400 edi: f1715000 ebp: 412de000 esp: f620fecc
> ds: 007b es: 007b ss: 0068
> Process nautilus (pid: 3555, threadinfo=f620e000 task=f6216720)
> Stack: 000001f7 00000000 00000000 c013c612 c0379eb0 00000000 00000000 f6613340
> 00000000 00000000 c0379eb0 00000400 00000400 f1715000 412de000 c02956fc
> c1bb2400 f1715000 f620ff60 00000000 00000400 00000000 c02956c0 c018bc91
> Call Trace:
> [<c013c612>] __alloc_pages+0x92/0x320
> [<c02956fc>] proc_scsi_read+0x3c/0x60
> [<c02956c0>] proc_scsi_read+0x0/0x60

This patch should fix the oops.

As for why the proc reading code was unable to locate the HBA: dunno, but
this is a first step.

Or maybe you don't have any adaptec controllers in the machine?

(jejb, please apply..)


25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
--- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
+++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
@@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB

HBAptr = NULL;

- for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
+ for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
;

if (!p)

_

2003-08-01 23:23:51

by Mike Anderson

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

Andrew Morton [[email protected]] wrote:
> This patch should fix the oops.
>
> As for why the proc reading code was unable to locate the HBA: dunno, but
> this is a first step.
>
> Or maybe you don't have any adaptec controllers in the machine?
>
> (jejb, please apply..)
>
>
> 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
> --- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
> +++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
> @@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB
>
> HBAptr = NULL;
>
> - for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
> + for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
> ;
>
> if (!p)

Is this really the right thing to add. The only purpose of these few lines
is a poor sanity check as down further in the code a pointer to the
structure is already present in hostdata.

Adding the "p" is an indication that this drivers list got corrupted some
where.

I agree it may be better than an oops, but what else is invalid?

You need to have adaptec controllers in the system to get a procfs node
to read / write, but this error could be related to the node not getting
cleaned up correctly on a remove which a patch has previously been
posted.

-andmike
--
Michael Anderson
[email protected]

2003-08-02 05:38:48

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Fri, Aug 01, 2003 at 02:27:50PM -0700, Greg KH wrote:

>
> The USB warnings should all be fixed up with the patches I just sent to
> Linus, so you can safely ignore them for now.
>
> As for the oops, I have no idea, sorry.
>
> thanks,
>
> greg k-h
>

Greg,

I'll look into your patches.

Thank you,

Paul


Attachments:
(No filename) (314.00 B)
(No filename) (189.00 B)
Download all attachments

2003-08-02 05:51:38

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Fri, Aug 01, 2003 at 02:44:55PM -0700, Andrew Morton wrote:
>
> This patch should fix the oops.
>
> As for why the proc reading code was unable to locate the HBA: dunno, but
> this is a first step.
>
> Or maybe you don't have any adaptec controllers in the machine?
>
> (jejb, please apply..)
>
>
> 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
> --- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
> +++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
> @@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB
>
> HBAptr = NULL;
>
> - for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
> + for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
> ;
>
> if (!p)
>
> _
>
>

Andrew,

I will test the patch shortly :). I do have Adaptec AHA-2940U2W
controller installed in my machine, http://www.blazebox.homeip.net:81/diffie/images/comp/amd_box8.png.

From dmesg:

(scsi0) <Adaptec AHA-294X Ultra2 SCSI host adapter> found at PCI 1/10/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 398 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
<Adaptec AHA-294X Ultra2 SCSI host adapter>
sda: Spinning up disk......<5>Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
(scsi0:0:6:0) Synchronous at 80.0 Mbyte/sec, offset 63.
SCSI device sdb: 71687340 512-byte hdwr sectors (36704 MB)
SCSI device sdb: drive cache: write back
/dev/scsi/host0/bus0/target6/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 >

From lspci:

01:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W

Regards,

Paul


Attachments:
(No filename) (1.80 kB)
(No filename) (189.00 B)
Download all attachments

2003-08-02 05:55:33

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Fri, Aug 01, 2003 at 04:27:22PM -0700, Mike Anderson wrote:
> Andrew Morton [[email protected]] wrote:
> > This patch should fix the oops.
> >
> > As for why the proc reading code was unable to locate the HBA: dunno, but
> > this is a first step.
> >
> > Or maybe you don't have any adaptec controllers in the machine?
> >
> > (jejb, please apply..)
> >
> >
> > 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
> > 1 files changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
> > --- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
> > +++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
> > @@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB
> >
> > HBAptr = NULL;
> >
> > - for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
> > + for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
> > ;
> >
> > if (!p)
>
> Is this really the right thing to add. The only purpose of these few lines
> is a poor sanity check as down further in the code a pointer to the
> structure is already present in hostdata.
>
> Adding the "p" is an indication that this drivers list got corrupted some
> where.
>
> I agree it may be better than an oops, but what else is invalid?
>
> You need to have adaptec controllers in the system to get a procfs node
> to read / write, but this error could be related to the node not getting
> cleaned up correctly on a remove which a patch has previously been
> posted.
>
> -andmike
> --
> Michael Anderson
> [email protected]
>
>

Mike,

I do indeed have an AHA-2940U2W controller in the box...could you be
kind and point me at the said patch? Thank you.

Regards,

Paul


Attachments:
(No filename) (1.77 kB)
(No filename) (189.00 B)
Download all attachments

2003-08-03 01:54:24

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Fri, Aug 01, 2003 at 02:44:55PM -0700, Andrew Morton wrote:
> Diffie <[email protected]> wrote:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000120
> > printing eip:
> > c02a8cae
> > *pde = 00000000
> > Oops: 0000 [#1]
> > PREEMPT
> > CPU: 0
> > EIP: 0060:[<c02a8cae>] Not tainted VLI
> > EFLAGS: 00210286
> > EIP is at aic7xxx_proc_info+0x2e/0xc80
> > eax: c1bb25b0 ebx: c1bb2400 ecx: c038bb20 edx: 00000000
> > esi: 00000400 edi: f1715000 ebp: 412de000 esp: f620fecc
> > ds: 007b es: 007b ss: 0068
> > Process nautilus (pid: 3555, threadinfo=f620e000 task=f6216720)
> > Stack: 000001f7 00000000 00000000 c013c612 c0379eb0 00000000 00000000 f6613340
> > 00000000 00000000 c0379eb0 00000400 00000400 f1715000 412de000 c02956fc
> > c1bb2400 f1715000 f620ff60 00000000 00000400 00000000 c02956c0 c018bc91
> > Call Trace:
> > [<c013c612>] __alloc_pages+0x92/0x320
> > [<c02956fc>] proc_scsi_read+0x3c/0x60
> > [<c02956c0>] proc_scsi_read+0x0/0x60
>
> This patch should fix the oops.
>
> As for why the proc reading code was unable to locate the HBA: dunno, but
> this is a first step.
>
> Or maybe you don't have any adaptec controllers in the machine?
>
> (jejb, please apply..)
>
>
> 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
> --- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
> +++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
> @@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB
>
> HBAptr = NULL;
>
> - for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
> + for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
> ;
>
> if (!p)
>
> _
>
>

Andrew,

After applaying the above patch and testing it still oopses the kernel.

I noticed same patch in today's mm3 which i compiled and use right now.

When using cat /proc/scsi/aic7xxx/0 i get segmentation fault and oops
which i'll attach to this email.

uname: Linux blaze 2.6.0-test2-mm3 #1 Sat Aug 2 20:12:35 EDT 2003 i686 unknown

gcc version 3.2.2 on Slackware 9.0

I noticed this when the SCSI sybsystem is initialized upon boot:
scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 1 lun 0

Regards,

Paul B.


Attachments:
(No filename) (0.00 B)
(No filename) (189.00 B)
Download all attachments

2003-08-03 02:06:36

by Andrew Morton

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

Diffie <[email protected]> wrote:
>
> After applaying the above patch and testing it still oopses the kernel.
>
> I noticed same patch in today's mm3 which i compiled and use right now.
>
> When using cat /proc/scsi/aic7xxx/0 i get segmentation fault and oops
> which i'll attach to this email.
>
> ...
>
> EIP is at aic7xxx_proc_info+0xc28/0xc80

This is crashing in a different place. Probably the same bug, showing up
later on.

I don't know if anyone is maintaining aic7xxx_old in 2.7. It looks like it
was subject to some random untested change a couple of months back.


2003-08-03 21:46:12

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Sat, Aug 02, 2003 at 07:07:37PM -0700, Andrew Morton wrote:
> Diffie <[email protected]> wrote:
> >
> > After applaying the above patch and testing it still oopses the kernel.
> >
> > I noticed same patch in today's mm3 which i compiled and use right now.
> >
> > When using cat /proc/scsi/aic7xxx/0 i get segmentation fault and oops
> > which i'll attach to this email.
> >
> > ...
> >
> > EIP is at aic7xxx_proc_info+0xc28/0xc80
>
> This is crashing in a different place. Probably the same bug, showing up
> later on.
>
> I don't know if anyone is maintaining aic7xxx_old in 2.7. It looks like it
> was subject to some random untested change a couple of months back.
>
>
>

Hi Andrew,

I think this bug is due to me using the aic7xxx_old code ver 5.x.x.

Under kernel 2.4.21 the aic7xxx (new) is ver 6.2.8 and it works great
with Adaptec AHA-2940U2W controller i have.

On 2.6.0-test2-mm3 (tried Linus test1,test2,mm1 and mm2) the NEW aic7xxx
uses ver 6.2.35 and will not scan my IBM drive even though it
initializes the correct SCSI ID,LUN etc...

I would like to contact and report this issue to the aic7xxx maintaner
and perhaps get it resolved.Where would be the best place to report this
kind of problem?

I have taken few screen captures which are available at:
http://www.blazebox.homeip.net:81/diffie/images/2.6.0-test2/ and show
the aic7xxx (new) failure.


Regards,

Paul B.


Attachments:
(No filename) (1.38 kB)
(No filename) (189.00 B)
Download all attachments

2003-08-03 21:51:18

by Andrew Morton

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

Diffie <[email protected]> wrote:
>
> I think this bug is due to me using the aic7xxx_old code ver 5.x.x.
>
> Under kernel 2.4.21 the aic7xxx (new) is ver 6.2.8 and it works great
> with Adaptec AHA-2940U2W controller i have.
>
> On 2.6.0-test2-mm3 (tried Linus test1,test2,mm1 and mm2) the NEW aic7xxx
> uses ver 6.2.35 and will not scan my IBM drive even though it
> initializes the correct SCSI ID,LUN etc...
>
> I would like to contact and report this issue to the aic7xxx maintaner
> and perhaps get it resolved.Where would be the best place to report this
> kind of problem?
>
> I have taken few screen captures which are available at:
> http://www.blazebox.homeip.net:81/diffie/images/2.6.0-test2/ and show
> the aic7xxx (new) failure.

An appropriate way to report this would be to email Justin (CC'ed here)
and [email protected].

2003-08-03 22:21:14

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Sun, Aug 03, 2003 at 02:52:11PM -0700, Andrew Morton wrote:
> Diffie <[email protected]> wrote:
> >
> > I think this bug is due to me using the aic7xxx_old code ver 5.x.x.
> >
> > Under kernel 2.4.21 the aic7xxx (new) is ver 6.2.8 and it works great
> > with Adaptec AHA-2940U2W controller i have.
> >
> > On 2.6.0-test2-mm3 (tried Linus test1,test2,mm1 and mm2) the NEW aic7xxx
> > uses ver 6.2.35 and will not scan my IBM drive even though it
> > initializes the correct SCSI ID,LUN etc...
> >
> > I would like to contact and report this issue to the aic7xxx maintaner
> > and perhaps get it resolved.Where would be the best place to report this
> > kind of problem?
> >
> > I have taken few screen captures which are available at:
> > http://www.blazebox.homeip.net:81/diffie/images/2.6.0-test2/ and show
> > the aic7xxx (new) failure.
>
> An appropriate way to report this would be to email Justin (CC'ed here)
> and [email protected].
>
>

Andrew,

Thank you for all your help.Sorry but i gave the wrong URL in previous
email.The correct one is http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/

Attached is the dmesg,lspci and aic7xxx /proc information from 2.4.21
kernel.

Regards,

Paul B.


Attachments:
(No filename) (1.23 kB)
(No filename) (189.00 B)
Download all attachments

2003-08-03 22:29:45

by Diffie

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Sun, Aug 03, 2003 at 06:23:13PM -0400, Diffie wrote:
> On Sun, Aug 03, 2003 at 02:52:11PM -0700, Andrew Morton wrote:
> > Diffie <[email protected]> wrote:
> > >
> > > I think this bug is due to me using the aic7xxx_old code ver 5.x.x.
> > >
> > > Under kernel 2.4.21 the aic7xxx (new) is ver 6.2.8 and it works great
> > > with Adaptec AHA-2940U2W controller i have.
> > >
> > > On 2.6.0-test2-mm3 (tried Linus test1,test2,mm1 and mm2) the NEW aic7xxx
> > > uses ver 6.2.35 and will not scan my IBM drive even though it
> > > initializes the correct SCSI ID,LUN etc...
> > >
> > > I would like to contact and report this issue to the aic7xxx maintaner
> > > and perhaps get it resolved.Where would be the best place to report this
> > > kind of problem?
> > >
> > > I have taken few screen captures which are available at:
> > > http://www.blazebox.homeip.net:81/diffie/images/2.6.0-test2/ and show
> > > the aic7xxx (new) failure.
> >
> > An appropriate way to report this would be to email Justin (CC'ed here)
> > and [email protected].
> >
> >
>
> Andrew,
>
> Thank you for all your help.Sorry but i gave the wrong URL in previous
> email.The correct one is http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/
>
> Attached is the dmesg,lspci and aic7xxx /proc information from 2.4.21
> kernel.
>
> Regards,
>
> Paul B.
>

I am sorry again for not including the attachement.


Attachments:
(No filename) (0.00 B)
(No filename) (189.00 B)
Download all attachments

2003-08-04 16:31:08

by Patrick Mansfield

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Sun, Aug 03, 2003 at 06:31:15PM -0400, Diffie wrote:
> On Sun, Aug 03, 2003 at 06:23:13PM -0400, Diffie wrote:

> > Thank you for all your help.Sorry but i gave the wrong URL in previous
> > email.The correct one is http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/
> >

Per your screen dump - it found the cd-rom's on id 3 and 4, but not your
disk drive that was at id 0, and the adapter found something at id 6 (host
adapter is at id 7).

You could try turning on scan logging, it might give more information.
You can turn on the logging at boot time, make sure you have
CONFIG_SCSI_LOGGING on, the information of interest (scan of host 0 chan 0
id 0 lun 0) likely will scroll off screen.

For scan logging, add to your boot line:

scsi_mod.scsi_logging_level=0x140

To limit the logging info, make sure max_scsi_luns=1 via config or boot
time option scsi_mod.max_scsi_luns=1.

-- Patrick Mansfield

2003-08-04 17:47:04

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Mon, 2003-08-04 at 12:30, Patrick Mansfield wrote:
> On Sun, Aug 03, 2003 at 06:31:15PM -0400, Diffie wrote:
> > On Sun, Aug 03, 2003 at 06:23:13PM -0400, Diffie wrote:
>
> > > Thank you for all your help.Sorry but i gave the wrong URL in previous
> > > email.The correct one is http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/
> > >
>
> Per your screen dump - it found the cd-rom's on id 3 and 4, but not your
> disk drive that was at id 0, and the adapter found something at id 6 (host
> adapter is at id 7).
>
> You could try turning on scan logging, it might give more information.
> You can turn on the logging at boot time, make sure you have
> CONFIG_SCSI_LOGGING on, the information of interest (scan of host 0 chan 0
> id 0 lun 0) likely will scroll off screen.
>
> For scan logging, add to your boot line:
>
> scsi_mod.scsi_logging_level=0x140
>
> To limit the logging info, make sure max_scsi_luns=1 via config or boot
> time option scsi_mod.max_scsi_luns=1.
>
> -- Patrick Mansfield
>

Patrick,

That's correct Plextor 40TW (ultraplex wide) is on ID3 and Plextor
plexwriter 32/10/12s is on ID4.Originally i had the IBM 36LZX drive at
ID6 (factory setting) but when using the aic7xxx_old driver it was
detected as /dev/sdb for some reason.I've changed the ID to 0 and it
became /dev/sda again...strange it is.

The Adaptec AHA-2940U2W card is set to boot from ID0 by default and it
has 2.57.2 BIOS (the latest i think).

I tried the latest 2.6.36 driver from Justin's site on kernel 2.4.21 and
it works great.I was unable to boot the 2.5 driver on 2.6.0-test2 it
game oops and i had to define blkdev.h in few places.

I will try your suggestions and report back.

Regards,

Paul B.



Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2003-08-04 18:25:54

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Mon, 2003-08-04 at 12:30, Patrick Mansfield wrote:
> On Sun, Aug 03, 2003 at 06:31:15PM -0400, Diffie wrote:
> > On Sun, Aug 03, 2003 at 06:23:13PM -0400, Diffie wrote:
>
> > > Thank you for all your help.Sorry but i gave the wrong URL in previous
> > > email.The correct one is http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/
> > >
>
> Per your screen dump - it found the cd-rom's on id 3 and 4, but not your
> disk drive that was at id 0, and the adapter found something at id 6 (host
> adapter is at id 7).
>
> You could try turning on scan logging, it might give more information.
> You can turn on the logging at boot time, make sure you have
> CONFIG_SCSI_LOGGING on, the information of interest (scan of host 0 chan 0
> id 0 lun 0) likely will scroll off screen.
>
> For scan logging, add to your boot line:
>
> scsi_mod.scsi_logging_level=0x140
>
> To limit the logging info, make sure max_scsi_luns=1 via config or boot
> time option scsi_mod.max_scsi_luns=1.
>
> -- Patrick Mansfield
>

Patrick,

I enabled CONFIG_SCSI_LOGGING=y in kernel then i used
scsi_mod.scsi_logging_level=0x140 and scsi_mod.max_scsi_luns=1 when
booting the kernel from lilo.I can see some debug information scroll on
the screen and i did see ID0 LUN0 get probed even the correct transfer
rate for the SCSI disk is set.I forgot but isn't there a key sequence
when pressed it will stop the screen output like pause/break key?

I have few screen snaps which can be viewed at
http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/aic7xxx/

Thanks for your help.

Paul B.


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2003-08-04 18:57:56

by Patrick Mansfield

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Mon, Aug 04, 2003 at 02:26:54PM -0400, Paul Blazejowski wrote:
>
> Patrick,
>
> I enabled CONFIG_SCSI_LOGGING=y in kernel then i used
> scsi_mod.scsi_logging_level=0x140 and scsi_mod.max_scsi_luns=1 when
> booting the kernel from lilo.I can see some debug information scroll on
> the screen and i did see ID0 LUN0 get probed even the correct transfer
> rate for the SCSI disk is set.I forgot but isn't there a key sequence
> when pressed it will stop the screen output like pause/break key?
>
> I have few screen snaps which can be viewed at
> http://www.blazebox.homeip.net:81/diffie/images/linux-2.6.0-test2/aic7xxx/

Yep, the shot that might have useful information is blurred.

I assume you are unable to use a serial console.

I can usually "Shift + page-up" as long as there is not too much data, and
depending on your console, AFAIR I can't pause my console output.

Also, does the adapter bios show the drive at boot time?

Hopefully Justin will add more useful suggestions for debugging.

-- Patrick Mansfield

2003-08-04 19:34:35

by Justin T. Gibbs

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

> Patrick,
>
> I enabled CONFIG_SCSI_LOGGING=y in kernel then i used
> scsi_mod.scsi_logging_level=0x140 and scsi_mod.max_scsi_luns=1 when
> booting the kernel from lilo.I can see some debug information scroll on
> the screen and i did see ID0 LUN0 get probed even the correct transfer
> rate for the SCSI disk is set.I forgot but isn't there a key sequence
> when pressed it will stop the screen output like pause/break key?

You might be able to get useful information without using a serial
console if you turn off your CDROM drives so they don't add extra output,
but your best bet is to use a serial console.

--
Justin

2003-08-05 02:21:42

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

>
> You might be able to get useful information without using a serial
> console if you turn off your CDROM drives so they don't add extra output,
> but your best bet is to use a serial console.
>
> --
> Justin
>
>
>

Justin,

I am going to try with the SCSI disk drive alone after diconnecting the
cdrom drivers.

I'll look into serial console and try to set it up.Do i need extra
hardware or cables to run serial console? any poniters or setup
suggestions would be welcome as i never used serial consoles before.
Regards,

Paul

2003-08-05 07:16:12

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Mon, 2003-08-04 at 15:36, Justin T. Gibbs wrote:
> > Patrick,
> >
> > I enabled CONFIG_SCSI_LOGGING=y in kernel then i used
> > scsi_mod.scsi_logging_level=0x140 and scsi_mod.max_scsi_luns=1 when
> > booting the kernel from lilo.I can see some debug information scroll on
> > the screen and i did see ID0 LUN0 get probed even the correct transfer
> > rate for the SCSI disk is set.I forgot but isn't there a key sequence
> > when pressed it will stop the screen output like pause/break key?
>
> You might be able to get useful information without using a serial
> console if you turn off your CDROM drives so they don't add extra output,
> but your best bet is to use a serial console.
>
> --
> Justin
>
>

Hi Justin,

This time with both plextor cdroms removed i get this in console:

scsi scan: INQUIRY to host 0 chanel 0 id0 lun 0
scsi scan: 1st INQUIRY failed with code 0x10000

and this repeats for all 15 id's on the cards with same 0x10000 code.

When using aic7xxx_old driver i get this in dmesg:

(scsi0) <Adaptec AHA-294X Ultra2 SCSI host adapter> found at PCI 1/10/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 398 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
<Adaptec AHA-294X Ultra2 SCSI host adapter>
scsi scan: INQUIRY to host 0 channel 0 id 0 lun 0
scsi scan: 1st INQUIRY successful with code 0x0
Vendor: Model: Rev:
Type: Direct-Access ANSI SCSI revision: 00
scsi scan: Sequential scan of host 0 channel 0 id 0
scsi scan: INQUIRY to host 0 channel 0 id 1 lun 0
scsi: Device offlined - not ready after error recovery: host 0 channel 0
id 1 lun 0
scsi scan: 1st INQUIRY failed with code 0x6030000
scsi scan: INQUIRY to host 0 channel 0 id 2 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 3 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 4 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 5 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 6 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 8 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 9 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 10 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 11 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 12 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 13 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 14 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
scsi scan: INQUIRY to host 0 channel 0 id 15 lun 0
scsi scan: 1st INQUIRY failed with code 0x30000
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0

Once i get null modem serial cable i will try to get more info from
serial console.

Regards,

Paul


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2003-08-05 10:13:18

by wb

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84


>
> I'll look into serial console and try to set it up.Do i need extra
> hardware or cables to run serial console? any poniters or setup
> suggestions would be welcome as i never used serial consoles before.
> Regards,
>
> Paul
> -

Your need a NULL modem serial cable available
from any computer store.

Install uucp - I use on the HOST :

uucp-1.06.1-33.7.2.

Also , LILO is broken on some machines and ignores
serial input so make sure you use at least

lilo-21.6-71

On the TARGET

1. Connect the serial ports together ( COM1->COM1 ) with
the serial cable .

2. Modify LILO to use serial line on the TARGET
add to lilo.conf:
append="console=ttyS0,9600n8 console=tty0 "
serial=0,9600N8

Run lilo

3. Add to /etc/inittab on the HOST

S0:s12345:respawn:/sbin/agetty 9600 ttyS0

4. To see ALL THE CONSOLE MESSAGES during boot on the TARGET

mv /dev/console /dev/console.org
ln /dev/ttyS0 /dev/console

5. Start uucp on the HOST:

cu -l /dev/ttyS0 -s 9600

6. Boot your target

///

John Donnelly AT HP DOT com














2003-08-05 16:12:42

by Chiaki

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

(Sorry this is not strictly related to SCSI, but I could not help it.)

Regarding the use of a program from uucp suite
for console output capture,
we can use C-Kermit as well.

> Your need a NULL modem serial cable available
> from any computer store.
>
> Install uucp - I use on the HOST :
>
> uucp-1.06.1-33.7.2.

Or you can use C-Kermit.
See

http://www.columbia.edu/kermit/ckermit.html

for details. There are precompiled packages.

> ... [omission ] ...

> 5. Start uucp on the HOST:
>
> cu -l /dev/ttyS0 -s 9600

kermit
set line /dev/ttyS0
set speed 9600
connect

and you can issue other commands.
set [space] ?
will print all the available options at that point.
(You can log the interaction into a file by issueing
a command to kermit, too, but using script and then run kermit
inside the scripted session might be easier.)
(Generally speaking hitting ? somewhere on the kermit command line
prints usable options/setting/keywords, and so
you can learn the basics very quickly.)
You can set up a startup file that sets
the device name, speed, parity, data size, etc. and
so you don't have to type all the command every time.

While I agree cu might work well for one shot job,
running a full terminal emulator like C-Kermit
helps us in the long term.

Just thought to let you know a full-featured terminal
emulator is available under linux.

> John Donnelly AT HP DOT com

Is the succinct and to the point steps
part of a widely available document?

I wish I knew this a few years ago.


--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

2003-08-06 16:53:51

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Tue, 2003-08-05 at 06:20, wb wrote:
> >
> > I'll look into serial console and try to set it up.Do i need extra
> > hardware or cables to run serial console? any poniters or setup
> > suggestions would be welcome as i never used serial consoles before.
> > Regards,
> >
> > Paul
> > -
>
> Your need a NULL modem serial cable available
> from any computer store.
>
> Install uucp - I use on the HOST :
>
> uucp-1.06.1-33.7.2.
>
> Also , LILO is broken on some machines and ignores
> serial input so make sure you use at least
>
> lilo-21.6-71
>
> On the TARGET
>
> 1. Connect the serial ports together ( COM1->COM1 ) with
> the serial cable .
>
> 2. Modify LILO to use serial line on the TARGET
> add to lilo.conf:
> append="console=ttyS0,9600n8 console=tty0 "
> serial=0,9600N8
>
> Run lilo
>
> 3. Add to /etc/inittab on the HOST
>
> S0:s12345:respawn:/sbin/agetty 9600 ttyS0
>
> 4. To see ALL THE CONSOLE MESSAGES during boot on the TARGET
>
> mv /dev/console /dev/console.org
> ln /dev/ttyS0 /dev/console
>
> 5. Start uucp on the HOST:
>
> cu -l /dev/ttyS0 -s 9600
>
> 6. Boot your target
>
> ///
>
> John Donnelly AT HP DOT com
>

John,

I appreciate your writing short and sweet howto :-).

I was able to get it going from FreeBSD 5.1 box with cu -l /dev/ttyd0
2&<1 > log to my Linux machine.

Thank you for helping.

Paul B.


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2003-08-06 16:56:22

by Paul Blazejowski

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

On Tue, 2003-08-05 at 12:10, Ishikawa wrote:
> (Sorry this is not strictly related to SCSI, but I could not help it.)
>
> Regarding the use of a program from uucp suite
> for console output capture,
> we can use C-Kermit as well.
>
> > Your need a NULL modem serial cable available
> > from any computer store.
> >
> > Install uucp - I use on the HOST :
> >
> > uucp-1.06.1-33.7.2.
>
> Or you can use C-Kermit.
> See
>
> http://www.columbia.edu/kermit/ckermit.html
>
> for details. There are precompiled packages.
>
> > ... [omission ] ...
>
> > 5. Start uucp on the HOST:
> >
> > cu -l /dev/ttyS0 -s 9600
>
> kermit
> set line /dev/ttyS0
> set speed 9600
> connect
>
> and you can issue other commands.
> set [space] ?
> will print all the available options at that point.
> (You can log the interaction into a file by issueing
> a command to kermit, too, but using script and then run kermit
> inside the scripted session might be easier.)
> (Generally speaking hitting ? somewhere on the kermit command line
> prints usable options/setting/keywords, and so
> you can learn the basics very quickly.)
> You can set up a startup file that sets
> the device name, speed, parity, data size, etc. and
> so you don't have to type all the command every time.
>
> While I agree cu might work well for one shot job,
> running a full terminal emulator like C-Kermit
> helps us in the long term.
>
> Just thought to let you know a full-featured terminal
> emulator is available under linux.
>
> > John Donnelly AT HP DOT com
>
> Is the succinct and to the point steps
> part of a widely available document?
>
> I wish I knew this a few years ago.
>

Kermit was very helpful but due to my inexperience i was not able to get
the log due to Linux's box resetting of /dev/ttyS0 when booting, i would
get disconnect...

Thanks a lot for suggesting ckermit.

Regards,

Paul B.


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2003-08-06 17:18:16

by Chiaki

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84


>
> Kermit was very helpful but due to my inexperience i was not able to get
> the log due to Linux's box resetting of /dev/ttyS0 when booting, i would
> get disconnect...
>

Oh, I forgot some details. You might be able to
circumvent the problem by
issueing
set carrier-watch off

I use the direct-wire connetion with
a device from a Linux PC's tty port using ckermit and
so let me check the setup again tomorrow at the office.

> Thanks a lot for suggesting ckermit.
>
> Regards,
>
> Paul B.


--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

2003-08-13 02:01:56

by Chiaki

[permalink] [raw]
Subject: Re: Badness in device_release at drivers/base/core.c:84

Chiaki wrote:

>> Kermit was very helpful but due to my inexperience i was not able to get
>> the log due to Linux's box resetting of /dev/ttyS0 when booting, i would
>> get disconnect...
>>
>
> Oh, I forgot some details. You might be able to
> circumvent the problem by
> issueing
> set carrier-watch off
>
> I use the direct-wire connetion with
> a device from a Linux PC's tty port using ckermit and
> so let me check the setup again tomorrow at the office.

Sorry for the delay. Below is the copy of kermit startup file
that I use for talking to a device that does not echo back characters.
I also power-on/off the device while connecting kermit to it, and
I don't think I got kicked off. : so
set carrier-watch off (abbreviated below as set carrier off)
should get you going talking to a linux box via
serial line during booting. (However,
I believe you already captured the necessary log using
uucp suite of tools.)

set line /dev/ttyS0
set speed 38400
set carrier off <- This is key to the disconnect
problem.
set terminal echo local <--- lines below here are for local echo back
set terminal newline on
set terminal cr-display crlf

>> Thanks a lot for suggesting ckermit.

You are very welcome.

From a happy Kermit user.
If you need to ask elaborate ckermit questions,
comp.protocols.kermit.misc is where the original
developers of Kermit hang around.

Happy Hacking,

Ishikawa, Chiaki


--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */