Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
On Thu, 03 Apr 2008, maximilian attems wrote: On Thu, Apr 03, 2008 at 07:35:38AM +0200, Frans Pop wrote: A post on lkml today [1] by one of the people working on it makes clear that the new firewire stack will not get into shape in time for lenny. the third fedora release happens with juju firewire stack only. drivers/firewire sees a steady progress. 2.6.26 will have nice logging options for the juju modules. backported into debian kernel 2.6.25. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
[ dropping release cc ] On Thu, Apr 03, 2008 at 07:35:38AM +0200, Frans Pop wrote: A post on lkml today [1] by one of the people working on it makes clear that the new firewire stack will not get into shape in time for lenny. the third fedora release happens with juju firewire stack only. drivers/firewire sees a steady progress. 2.6.26 will have nice logging options for the juju modules. At the same time, there is quite a big demand from users for the old stack because there hardware is not supported by the new one. Some of the relevant BRs are: 436267, 449272, 450836, 441206, 441179, 435224, 435062, 434551. humm let's sort those bug reports: - fixed 441179 441206 - moreinfo 435224 (no follow up most probably fixed as really old version of the stack tested) - userspace 434551 436267 - missing driver 450836 - missing hardware support 435062 - crash of old stack 449272 please next time be more carefull compiling such lists, at scrutiny survives 4 bugs. Could the kernel team please reconsider making the enabling the old stack again and use that as the default stack. The new stack could remain available, but blacklisted for modprobe. relevant bugs of the old stack are (see bugzilla.kernel.org): 6070 6393 7569 7771 7774 7794 8174 8361 8403 9616 i wouldn't consider this list minor. considering the slowness of the firewire userspace for example kino or raw1394 our user should have the avaibility of the old stack. so blacklisting ieee1394 sounds like a way to move on. Cheers, FJP [1] http://lkml.org/lkml/2008/4/2/564 best regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
A post on lkml today [1] by one of the people working on it makes clear that the new firewire stack will not get into shape in time for lenny. At the same time, there is quite a big demand from users for the old stack because there hardware is not supported by the new one. Some of the relevant BRs are: 436267, 449272, 450836, 441206, 441179, 435224, 435062, 434551. Could the kernel team please reconsider making the enabling the old stack again and use that as the default stack. The new stack could remain available, but blacklisted for modprobe. Doing so now would still allow time for feedback from users after the switch and to document the issue for Lenny (e.g. by creating a wiki page). Cheers, FJP [1] http://lkml.org/lkml/2008/4/2/564 signature.asc Description: This is a digitally signed message part.
Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
On 29/07/07 10:50, maximilian attems wrote: please file aboves report in bugzilla.kernel.org and inform us of your bug nr. Done, see: http://bugzilla.kernel.org/show_bug.cgi?id=8828 Thanks, -- Mourad DC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
On Sun, Jul 29, 2007 at 05:19:53AM +0200, Mourad De Clerck wrote: 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 I see you chose not to include them anymore. yes they can't work both equaly on the same pci ids. 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 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. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435062: linux-image-2.6.22-1-k7: nforce2 firewire unsupported in new stack, please enable old fw stack
Package: linux-image-2.6.22-1-k7 Version: 2.6.22-2 Severity: important 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 I see you chose not to include them anymore. 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 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. I therefore respectfully request you re-enable the old stack. Thanks -- Mourad DC -- Package-specific info: ** Version: Linux version 2.6.22-1-k7 (Debian 2.6.22-2) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 SMP Mon Jul 23 14:02:09 UTC 2007 ** Tainted: PFSRMB ** Kernel log: PCI: cache line size of 64 is not supported by device :00:02.2 ehci_hcd :00:02.2: irq 18, io mem 0xed083000 ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 6 ports detected NFORCE2: IDE controller at PCI slot :00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: :00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA Probing IDE interface ide0... firewire_core: created new fw device fw0 (0 config rom retries) hda: HL-DT-ST RW/DVD GCC-4520B, ATAPI CD/DVD-ROM drive usb 3-2: new high speed USB device using ehci_hcd and address 3 usb 3-2: configuration #1 chosen from 1 choice hub 3-2:1.0: USB hub found hub 3-2:1.0: 4 ports detected ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ATAPI 52X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 swsusp: Basic memory bitmaps created swsusp: Basic memory bitmaps freed EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. usb 2-1: new low speed USB device using ohci_hcd and address 2 usb 2-1: configuration #1 chosen from 1 choice usb 2-2: new full speed USB device using ohci_hcd and address 3 usb 2-2: configuration #1 chosen from 1 choice usbcore: registered new interface driver hiddev usb 1-1: new full speed USB device using ohci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: Logitech NetPlay Keyboard as /class/input/input0 input: USB HID v1.10 Keyboard [Logitech NetPlay Keyboard] on usb-:00:02.1-1 input: Logitech USB Gaming Mouse as /class/input/input1 input: USB HID v1.11 Mouse [Logitech USB Gaming Mouse] on usb-:00:02.1-2 hiddev96: USB HID v1.11 Device [Logitech USB Gaming Mouse] on usb-:00:02.1-2 usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver kjournald starting. Commit interval 5 seconds EXT3-fs: sda1: orphan cleanup on readonly fs ext3_orphan_cleanup: deleting unreferenced inode 2310155 ext3_orphan_cleanup: deleting unreferenced inode 2281718 EXT3-fs: sda1: 2 orphan inodes deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. Linux agpgart interface v0.102 (c) Dave Jones agpgart: Detected NVIDIA nForce2 chipset agpgart: AGP aperture is 128M @ 0xe000 Real Time Clock Driver v1.12ac i2c-adapter i2c-0: nForce2 SMBus adapter at 0x5000 i2c-adapter i2c-1: nForce2 SMBus adapter at 0x5100 pci_hotplug: PCI Hot Plug PCI Core version: 0.5 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 input: PC Speaker as /class/input/input2 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20 ACPI: PCI Interrupt :00:06.0[A] - Link [APCJ] - GSI 20 (level, high) - IRQ 19 PCI: Setting latency timer of device :00:06.0 to 64 Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.9 intel8x0_measure_ac97_clock: measured 52786 usecs intel8x0: clocking to 48000 usbcore: registered new interface driver hci_usb Adding 2104504k swap on /dev/sda2. Priority:-1 extents:1 across:2104504k EXT3 FS on sda1, internal journal it87: Found IT8712F chip at 0x290, revision 5 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] fuse init (API version 7.8) NET: Registered protocol family 10 lo: Disabled Privacy Extensions input: Power Button (FF) as /class/input/input3 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input4
