Re: [Bugme-new] [Bug 7130] New: loading driver eat all CPU and since some time may block all system disk IO (even can not reboot)

Re: [Bugme-new] [Bug 7130] New: loading driver eat all CPU and since some time may block all system disk IO (even can not reboot)

[Andrew Morton]

On Sat, 9 Sep 2006 03:32:07 -0700
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7130
> 
>            Summary: loading driver eat all CPU and since some time may block
>                     all system disk IO (even can not reboot)
>     Kernel Version: 2.6.17.12
>             Status: NEW
>           Severity: blocking
>              Owner: scsi_drivers-other@kernel-bugs.osdl.org
>          Submitter: wizard580@gmail.com
> 
> 
> Most recent kernel where this bug did not occur: 2.6.17.12
> Distribution: Debian SID/Unstable
> Hardware Environment: SUN UltraSparc2 E3500 FC-AL SCSI hard drives
> Software Environment: Debian with latest updates on 09.09.2006
> Problem Description: When I load a driver fcal, mu cpu will be 100% busy and 
> will never fred. modprobe fcal will never ends. If I do not restart 
> immediately, then since 2-4min I can not even reboot. Seems to there is a 
> block of all disk io. A top and so programs running fine, until exit. Start 
> again will fail.
> So... may be because of that, I can not see my FC-AL scsi hard drives.
> My hardware (if I did't mistaken):
> 1) X2652A FC-AL INTERFACE BOARD 3500.
> 2) X6731A FCAL GBIC MODULE 100MB/SEC
> P.S.: I do anything for seeing my hard drives in Debian. If I need to tell you 
> any info, or make a tests, just let me know. :)
> If anybody can quickly help, I will be blessed. :D My life is bet on this.
> P.P.S:
> hard drives I see in "pre boot 'bios' with probe-fcal-all command"
> 
> Steps to reproduce:
> modprobe fcal on a Sparc arch.
> 

Does anyone else us the fcal driver?

I'd suggest the next step would be to run a kernel profile, or just sysrq-P
to find out where the CPU is stuck.  Could a sparc person please talk the
reporter through that process?

Thanks.

Re: [Bugme-new] [Bug 7130] New: loading driver eat all CPU and since some time may block all system disk IO (even can not reboot)

[James Bottomley]

On Sat, 2006-09-09 at 08:36 -0700, Andrew Morton wrote:
> Does anyone else us the fcal driver?
> 
> I'd suggest the next step would be to run a kernel profile, or just sysrq-P
> to find out where the CPU is stuck.  Could a sparc person please talk the
> reporter through that process?

I'm not sure this is really worth it.  Apart from trying to keep it
compiling, fcal has had no maintainer since the 2.2 kernel days.  Since
no-one has the hardware or the inclination, it's not plugged into the
SCSI FC infrastructure and thus it's bitrotting.  Now might be a good
time to declare it officially dead and remove it from the tree.  Unless
someone actually wants to maintain it and bring it into the 21st
century?

James

Re: [Bugme-new] [Bug 7130] New: loading driver eat all CPU and since some time may block all system disk IO (even can not reboot)

[David Miller]

From: James Bottomley <James.Bottomley@SteelEye.com>
Date: Sat, 09 Sep 2006 11:04:15 -0500

> On Sat, 2006-09-09 at 08:36 -0700, Andrew Morton wrote:
> > Does anyone else us the fcal driver?
> > 
> > I'd suggest the next step would be to run a kernel profile, or just sysrq-P
> > to find out where the CPU is stuck.  Could a sparc person please talk the
> > reporter through that process?
> 
> I'm not sure this is really worth it.  Apart from trying to keep it
> compiling, fcal has had no maintainer since the 2.2 kernel days.  Since
> no-one has the hardware or the inclination, it's not plugged into the
> SCSI FC infrastructure and thus it's bitrotting.

I think it's not feasible nor worth plugging the fcal driver into the
SCSI FC infrastructure right now simply because these drivers need a
full software FC stack, and the SCSI FC stuff just provides very high
level interfaces to all of this an expects on-board firmware to do all
the protocol packet building and other FC stuff just like the
Qlogic-FC and other cards do.

So it's not just a matter of "porting fcal to SCSI FC", someone would
need to implement the full FC software stack.