Bug 8828

Reply-To: stefanr@s5r6.in-berlin.de

For the list to see:

On 7/30/2007 2:48 PM, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8828
> 
>            Summary: nforce2 firewire no longer supported in new stack
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.22
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IEEE1394
>         AssignedTo: drivers_ieee1394@kernel-bugs.osdl.org
>         ReportedBy: kernel-bugzilla@aquazul.com
> 
> 
> Most recent kernel where this bug did not occur: 2.6.21
> Distribution: Debian sid/lenny
> Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435062
> 
> (lspci/dmesg available in debian bug report)
> 
> Problem Description:
> 
> After upgrading to 2.6.22, my firewire controller just stopped working 
> altogether. It had been working perfectly in all previous versions. I was 
> looking to manually load the old stack/sbp2 modules, but my distribution
> (Debian) chose to use the new stack only.
> 
> I found this message from Stefan Richter that explains things a bit:
> 
> "The NVidia nForce2 chipset has an own FireWire controller, and that one
> is only "supported" by a gross hack in ohci1394 and at the moment
> unsupported in firewire-ohci. There is even a bug report in Red Hat's
> bugzilla where fw-ohci hung up when trying to initialize an nForce2 chip."
> 
> See: http://www.ussg.iu.edu/hypermail/linux/kernel/0707.2/3700.html
> 
> I requested that the Debian Kernel team would switch the old stack back on,
> but
> they felt it would not be the right course of action to take:
> 
> On 29/07/07 10:50, maximilian attems wrote:
>> On Sun, Jul 29, 2007 at 05:19:53AM +0200, Mourad De Clerck wrote:
>>> This is a regression for me, and all nforce2 firewire users. I believe it's 
>>> also one of the reasons Linux 2.6.22 shipped with 2 firewire stacks instead
>>> of
>>> just the new one: the new one just doesn't cover all cases yet.
>>
>> so your bugreport needs to reach upstream,
>> so that your chipset regains support on the new stack.
>>
>> this is kind of an expected fallout and no the old stack had
>> to many shortcomings that he won't be enabled.
>> the new stack is gaining enough momentum to have it's bug
>> shaken out for the next release of Lenny.
>> 
>> please file aboves report in bugzilla.kernel.org
>> and inform us of your bug nr.
> 
> So I'm doing as asked, and filing this in the kernel bugzilla to keep track
> of
> this regression, and to request that support for this chipset be added to the
> new firewire-ohci.
> 
> Thank you,
> 
> -- Mourad DC


The above mentioned hang with nForce2 has been reported at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244576

The mentioned nForce2 hack in the old ohci1394 driver is causing bugs
like this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144201
http://bugzilla.kernel.org/show_bug.cgi?id=6070
This means that the CPU is caught in a busy loop for a moment and can't
do anything else, not even serve other interrupts.  Not nice at all, but
also not fatal.

Nowadays these kind of hacks are unacceptable for any new code that
wants to enter the mainline kernel.  That means that we need to find a
better way to support nForce2 than it had been done in ohci1394.

Stefan,
Would you consider this as a "project"? Do you think it can be posted so someone can try working on it?
Thanks.

IMO only someone with direct access to this hardware can do this.

FWIW, added a reference at http://wiki.linux1394.org/ToDo to this bug and also posted the TODO list to linux1394-devel and LKML.

Hi,

I encountered this bug while using a fresh install of lenny(installed from a daily image of a netinst iso).  While attempting to use Kino(or dvgrab) to pull video off a Canon XL2 the system locked up everytime(predictably on every test).  I was unable to switch to any other terminals or regain control without rebooting.  

My motherboard is an Asus A7N8X-E Deluxe with the nforce2 chipset.

Created attachment 15375 [details]
linux1394 SVN commit r857: "busReset loop check for nForce2 chipsets."

Attached as historical marginalia:  The ohci1394 hack for nForce2 as it went into Linux 2.4.

It is not applicable as-is to firewire-ohci (a) because of the busy-waiting and lock-juggling in the interrupt handler and (b) because firewire-ohci's interrupt handler doesn't serve pairs of bus reset events and self ID complete events, but only self ID complete events.

Created attachment 15376 [details]
linux1394 SVN commit r858: "busReset loop check, forward ported from 2.4 branch"

Attached:  The same ohci1394 hack for nForce2, as it was adopted in Linux 2.5.

I've managed to win an nForce 2 board with onboard MCP-T-driven FireWire for a reasonable price in an eBay auction, and it should be showing up via FedEx tomorrow. I'm hoping maybe with such a beast in front of me, I can figure out a work-around... (The board is an MSI K7N2G-ILSR, fwiw)

More diagnosis provided by downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=244576#c38
and following comments

People who experience total system-lockup with nForce2 are probably bitten by bug 10922.  I.e. nForce2 causes a bus reset loop if something is plugged in, and the drivers hit the general (chip independent) bug 10922 which is 100% repeatable after many bus resets.