[Bug 1328301] Re: no encripted mail possible with thunderbird - wrong passphrase error
Please improve the spam filter! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1328301 Title: no encripted mail possible with thunderbird - wrong passphrase error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1328301/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Tested: - VLC 2.0.3, libraw1394 2.1.0, libdc1394 2.2.0, kernel 3.6-rc7, udev 171, Gentoo Linux - miniDV camcorder JVC GR-D725E - IIDC (DCAM) webcam Apple iSight - VIA VT6306 based CardBus FireWire controller - Texas Instruments XIO2213A/B based PCIe FireWire controller "vlc dv://" and "vlc dc1394://" automatically pick up the camcorder or webcam respectively and display live video. Sound of the DV stream is played as well. I did not try network streaming. (Never tried it before and did not figure out how to set up stream output.) The VT6306 controller does not work very reliably: For example, if VLC is stopped and restarted with "kill -STOP $pid" and "kill -CONT $pid", the DV stream is frozen. This is a known issue between VT6306 and current kernels which is also seen with some other capture programs; the VT6306 does not properly restart its DMA after a period of inactivity of the capture process. The Texas Instruments controller does not exhibit such a problem, as expected. Somewhat older software revisions should work as well. libdc1394 and the VLC dc1394 are irrelevant for DV. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/6290 Title: DV capture over Firewire is broken (no rights for /dev/raw1394) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kino/+bug/6290/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Re comment 87: Eric, thanks for describing your use case. I was vaguely aware that VLC has IEEE 1394 video capture modules, but it is interesting to learn that somebody used (is using) it as a means to deliver DV over network. There are two IEEE 1394 modules in VLC: "DC1394", implemented by modules/access/dc1394.c, for cameras which send uncompressed video over 1394 according to the IIDC a.k.a. DCAM standard (industrial cameras, some old webcams), and "DV1394" alias "dv" alias "raw1394", implemented by modules/access/dv.c, for camcorders, perhaps tape decks etc. which send DV over 1394. From VLC v1.0 to VLC v1.1, these VLC access modules have been converted to libdc1394 v2 and to libraw1394 v2, respectively. These updates to current low-level library API versions should mean that VLC should work with current kernels and current udev, which should provide the following interface: a) The single global /dev/raw1394 no longer exists. b) Instead, the kernel provides /dev/fw0, fw1, fw2, ..., one file for each IEEE 1394 node (including the local node, i.e. the controller card). These device files are binary incompatible with /dev/raw1394 but are functionally 90% compatible with /dev/raw1394. c) Udev should set group ownership or/and access control lists for the "video" group or/and the current console owner or some other suitable owner for each /dev/fw* device file which corresponds to a video device, e.g. DV camcorder. d) libdc1394 v2 and libraw1394 v2 are able to automatically select the proper /dev/fw* device file for device control and capture. e) libdc1394 v2 based or libraw1394 v2 based application programs don't notice any of that, since they let the libraries deal with the kernel's device files. Currently I don't have Ubuntu myself (I have got Gentoo Linux but am subscribed to this bug because I am involved in FireWire kernel drivers maintenance and libraw1394 maintenance), and I never tried VLC's IEEE 1394 video capture modules. I will configure my VLC installation to include these modules, try if they work here (they should work in principle), and report back. PS, kino should work out-of-the box on recent Ubuntu versions, using libraw1394 v2. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/6290 Title: DV capture over Firewire is broken (no rights for /dev/raw1394) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kino/+bug/6290/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
PS, since the kernel never gets a chance to go from in_bus_reset:1 back to in_bus_reset:0 while the camera is on, the kernel cannot transmit and receive on the bus, and hence dvgrab cannot do anything either. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
> Before connection: [...] > /sys/bus/ieee1394/devices/fw-host0/in_bus_reset:0 [...] > /sys/bus/ieee1394/devices/fw-host0/node_count:1 Good. > After connection: [...] > /sys/bus/ieee1394/devices/fw-host0/in_bus_reset:1 [...] > /sys/bus/ieee1394/devices/fw-host0/node_count:0 Bad, as this should become 0 and 2 respectively. This is consistent with what you got with the newer kernel: While the camera is connected (and switched on), the bus is permanently reset and never finishes a reset successfully with a self-ID-complete event, after which it would become usable for system software. This and the fact that you already replaced the cable and also tested a PC-to-laptop connection unsuccessfully leaves pretty much only the conclusion that the port (or the ports) on your FW322/323 based board are dead. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
Thank you very much for testing with the old drivers. The fact that nothing gets added to dmesg at the time when the camera is plugged in shows that the older drivers do not recognize the camera either, fully or partially. But could you please run "grep . /sys/bus/ieee1394/devices/*/*" before and after you connected the (switched-on) camcorder? There is for example a file in there with a node count, which would normally be 1 before a device gets added and 2 after successful addition of a device. /dev/* files won't be added by the old drivers regardless whether devices are detected or not. But after "modprobe raw1394" as root, a /dev/raw1394 is created. Temporarily give your user permission to read and write this file, e.g. "chmod a+rw /dev/raw1394", again ran as root user. Then retry dvgrab. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
> I suppose this points to defect HW? Yes. > How easy are these things to break? Ports which adhere to the old IEEE 1394:1995 specification are electrically more prone to damage during hotplugging than later 1394a:2000 hardware. And the 4-pin iLink ports are mechanically not very reliable. Damaged 6-pin 1394a ports or 9-pin 1394b ports on the other hand are not very common but do occasionally happen. > Will try older Ubuntu later. If you have the opportunity, please do so. A driver regression is unlikely to be the cause of this problem but it would be good if you could test with older firewire-ohci + firewire-core kernel drivers, or ideally with the ohci1394 + ieee1394 + raw1394 kernel drivers of kernel 2.6.36 or older to be sure. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
The cycle64Seconds interrupt is a regular interrupt caused by a timer of the FireWire chip. It is normal and intended (in this version of the kernel; kernel 3.6 does not enable this interrupt unless an application requests a certain register which depends on that timer). The bus reset loop in comment 3, i.e. the cycling endlessly through generations 0...255 while the camcorder is connected, is indicating a problem low at the physical layer. Since we are talking about a camcorder from 1998 which implements IEEE 1394:1995 but not the amendment IEEE 1394a:2000, I first suspected that maybe the recent kernel drivers enable 1394a:2000 physical layer features too optimistically, so that the camcorder PHY is throwing a fit. However, seeing that a connection between PC and laptop does not succeed either, the most likely cause is rather a hardware defect of the cable or of the PC's card or (less likely) of the laptop's port. Here is how a successful bus reset with two nodes on the bus should look like, with firewire-ohci debug parameter set to 2: Sep 3 22:34:39 stein kernel: firewire_ohci :0a:00.0: 2 selfIDs, generation 151, local node ID ffc1 Sep 3 22:34:39 stein kernel: firewire_ohci :0a:00.0: selfID 0: 807fc494, phy 0 [p--] beta gc=63 -3W L Sep 3 22:34:39 stein kernel: firewire_ohci :0a:00.0: selfID 0: 817f8972, phy 1 [-c.] S400 gc=63 +15W Lci (After this hardware-triggered bus reset with self-ID-complete event, one or a few more software-triggered bus resets and self-ID-complete events may follow when firewire-core or a remote node's firmware or system software reconfigures the bus or starts up the node's higher functions.) So the absence of a second self-identification packet on the PC and the absence of any interrupt at all on the laptop --- which both have 1394a:2000 compliant PHYs which are known to work with current Linux drivers --- show that defective hardware (e.g. the cable) is much more likely to be the culprit here than the drivers. If you try an older Ubuntu, best would be one which still has the ieee1394/ ohci1394/ raw1394 kernel drivers, i.e. with kernel 2.6.36 or older. I don't remember when these were removed from Ubuntu; distrowatch.com says at least that Ubuntu 10.10 had kernel 2.6.35. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 950879] Re: 1106:3044 DV video capture w/PCI 1394 cards unsuccessful
As root, run # echo -1 > /sys/module/firewire_ohci/parameters/debug Then plug in/ switch on the camcorder. This should normally produce lots of output in dmesg. Please post the output here, if any. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/950879 Title: 1106:3044 DV video capture w/PCI 1394 cards unsuccessful To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/950879/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1045047] Re: Firewire camera is not recognized
As root, run # echo -1 > /sys/module/firewire_ohci/parameters/debug Then plug in/ switch on the camcorder. This should normally produce lots of output in dmesg. Please post the output here, if any. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1045047 Title: Firewire camera is not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 590139] Re: kino can not connect to DV camera through IEEE1394
If you still have got this issue, please add some information (while the camcorder is plugged in and in play mode or camera mode): - Are there any error messages from Kino? - What does "ls -l /dev/raw1394 /dev/fw*" show? - What does "dmesg" show? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/590139 Title: kino can not connect to DV camera through IEEE1394 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kino/+bug/590139/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 577746] Re: Simple Scan freeze with ieee1394
Does the scan always hang or only sometimes? CurrentDmesg.txt contains several sessions of the scanner being connected via 1394 (and maybe via USB in between). In the first session, but not in any subsequent ones, is a SCSI read transaction time-out logged. That time-out was unrecoverable, hence the kernel's SCSI core took the device offline. Basically the 1394 firmware of the scanner became unresponsive. The subsequent sessions do not show any sign of problems in the kernel log. Is SimpleScanLog.txt from the first session or from a later one? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/577746 Title: Simple Scan freeze with ieee1394 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/simple-scan/+bug/577746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 881688] Re: [Latitude XT3] Firewire nonfunctional after suspend
For the failure mode that a disk is not recognized if plugged in _after_ resume, please provide kernel logs with firewire-ohci IRQ logging enabled: # echo 7 > /sys/module/firewire_ohci/parameters/debug (suspend) (resume) (attach FireWire disk) (collect the dmesg) To be sure, repeat this with additional logging of bus reset events: # modprobe -r firewire-ohci # modprobe firewire-ohci debug=15 (suspend) (resume) (attach FireWire disk) (collect the dmesg) Beware, either debug level may possibly cause huge logs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881688 Title: [Latitude XT3] Firewire nonfunctional after suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 881688] Re: [Latitude XT3] Firewire nonfunctional after suspend
> Or does the HDD keep spinning in one case and spins down in the other? Of course, either way /should/ work. But if it makes a difference, it would mean that the target itself enters a low power state from which it is unable to resume due to a firmware bug. Would # echo 0 > /sys/class/scsi_disk/6:0:0:0/manage_start_stop before suspend make a difference? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881688 Title: [Latitude XT3] Firewire nonfunctional after suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 881688] Re: [Latitude XT3] Firewire nonfunctional after suspend
Re comment 6 and 7: So, the disk is fine after resume if the PC was suspended only for a few seconds, but becomes inaccessible if the PC was suspended for longer? Or does the HDD keep spinning in one case and spins down in the other? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881688 Title: [Latitude XT3] Firewire nonfunctional after suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 881688] Re: [Latitude XT3] Firewire nonfunctional after suspend
What FireWire target devices did you test? According to the first 3 bytes of the GUID (this part is the OUI), it is a device from Buffalo, Inc. Observations about CurrentDmesg.txt from comment 1: - There is no message along the lines of "PM: resume of drv:firewire_ohci dev::09:00.0 complete after ...msecs". Should there be such a message? - There is no "Register access failure". - After PM resume, self ID receive DMA, AT-req DMA, and AR-resp DMA work fine, which is evident by "rediscovered device fw1" from firewire-core. - Ditto, physical DMA and AR-req DMA work, since firewire-sbp2 receives an SBP-2 reconnect status block and six pairs of SBP-2 login and logout status blocks from the target. So, to me it looks unlikely that there is a controller problem. More likely to me is that the target firmware is crap since it refuses re-login. The status codes mean: - Received for the reconnect request ORB: 0:9 = Request complete. Function rejected. - Received for each logout and login request ORB: 0:4 = Request complete. Access denied. Of course, there /still/ could be a controller problem because perhaps the physical DMA delivered malformed reconnect or logout or login ORBs to the target. But I think this is highly unlikely. So far, I don't know what to make of this information. I was thinking about asking for a debug log with "firewire-ohci debug=3" (logging of AT, AR, and self-ID-R DMA interrupt events), but that would show only a fraction of the picture since most of the SBP-2 communication occurs without CPU interrupts by means of OHCI-1394 physical DMA (something like remote DMA). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881688 Title: [Latitude XT3] Firewire nonfunctional after suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 862790] Re: [Latitude XT3] System unable to suspend
Attachment CurrentDmesg.txt looks like the card slot controller could be at fault. That one in turn is a combination device with the FireWire controller (cf. attachment Lspci.txt). Hence, the fix to bug 862746 "[Latitude XT3] SD/Firewire devices not detected by o2micro controller" may have an impact on this bug here too, perhaps. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/862790 Title: [Latitude XT3] System unable to suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/862790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801719] Re: [Dell E5420/E5420m/E5520/E5520M/E6520/M6600/M4600] SD card and Firewire devices are not detected when attached to o2micro controller
Marc, thank you very much. Evidently this controller has a correctly working Cycle Timer register. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801719 Title: [Dell E5420/E5420m/E5520/E5520M/E6520/M6600/M4600] SD card and Firewire devices are not detected when attached to o2micro controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801719] Re: [Dell E5420/E5420m/E5520/E5520M/E6520/M6600/M4600] SD card and Firewire devices are not detected when attached to o2micro controller
While we are at adding a quirk table entry for this controller --- could you please test whether another common controller bug is present in this device? For the test, you need to have gcc installed, download this test tool: http://user.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c compile it with "gcc test_cycle_time_v20100125.c", and run it with "sudo ./a.out /dev/fw0". The program then runs (possibly silently) for 60 seconds and then prints a test summary. Please post this output here. The controller bug which is being tested for concerns timestamps which are used in industrial video applications and for audio I/O over FireWire. You can run this test without any devices attached to the FireWire controller, or with arbitrary devices attached to it (storage, video, audio --- doesn't matter for the test; and if you have a FireWire disk attached, you can even leave it mounted during the test). Even if you don't have any of those devices yourself for which this potential other controller bug would be relevant, it would be nice if you could run the test and report the result. It could be of help to other fellow Linux users who may have such a device combination. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801719 Title: [Dell E5420/E5420m/E5520/E5520M/E6520/M6600/M4600] SD card and Firewire devices are not detected when attached to o2micro controller To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 785417] Re: 11.04 install freezes at firewire_core: created device fw0: GUID 00023c003101b099, s400
>From the ubuntuforums link: > Hardware is GB-8Ipe1000 pro-g m/b, p4 2.6 cpu, nvidia 6800, 1 gb ram, 160 > sata hd. > > During install, goes quite a way through then probs start. > > code: Bad EIP value > EIP: [<66726570>] 0x66726570 SS:ESP 0068:44699d60 > CR2: 66726570 > ---[ end trace 5045eee9721cd669 ]--- > udevd-work [81] : 'sbin/modprobe bv pci: "too long to type" unexpected exit > with status 0x0009 Aren't there more messages surrounding this/ leading up to this? If there are more, you could for example take a photograph and attach the picture here. The messages above do not identify which kernel subsystem crashed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/785417 Title: 11.04 install freezes at firewire_core: created device fw0: GUID 00023c003101b099, s400 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/785417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 792464] Re: Can't enable firewire
The help.ubuntu.com page and the Kino message are a bit outdated. With newer kernels, the software stack looks like this: -- firewire-ohci (kernel driver) -- firewire-core (kernel driver) -- libraw1394 -- Kino Please post the following information: lspci -nn | grep 1394 grep firewire /proc/interrupts ls -l /dev/fw* dmesg Run the latter two commands half a minute or so after you plugged in/ switched on the camcorder. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/792464 Title: Can't enable firewire To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kino/+bug/792464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 796267] Re: Since natty pugrape sbp2 ohci1394 is no longer working
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796267/+attachment/2166553/+files/CurrentDmesg.txt shows a (temporarily?) hanging SCSI subsystem thread on a 2 GB USB attached HDD. This is most likely unrelated to the FireWire issue, but please try again with this USB device removed and rebooted. Then, collect diagnostic output from the FireWire subsystem this way: As root, enter echo 7 > /sys/module/firewire_ohci/parameters/debug Then plug the FireWire device in, wait thirty seconds or so, and post the output of "dmesg" here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/796267 Title: Since natty pugrape sbp2 ohci1394 is no longer working To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796267/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801719] Re: [Precision M6600] Unable to connect to Firewire device
>From lspci: > 0b:00.0 FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev > 05) (prog-if 10 [OHCI]) >From dmesg: > [2.625857] firewire_ohci :0b:00.0: PCI INT A -> GSI 19 (level, low) > -> IRQ 19 > [2.625866] firewire_ohci :0b:00.0: setting latency timer to 64 > [2.680992] firewire_ohci :0b:00.0: irq 42 for MSI/MSI-X > [2.681038] firewire_ohci: Added fw-ohci device :0b:00.0, OHCI v1.10, > 8 IR + 8 IT contexts, quirks 0x0 I didn't know until know that O2 Micro have a native PCI Express FireWire controller. ... Perhaps MSI support is broken in this device. Try: # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=0x10 Then confirm with "dmesg | tail -55" that the driver was unloaded and re-loaded with the 0x10 quirks flag which disables MSI. After that, attach whatever FireWire device you are having and watch dmesg again for new messages. If nothing seems to happen, check again after about half a minute. If this does still not show anything in the log, repeat with # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=0x10 debug=0xf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801719 Title: [Precision M6600] Unable to connect to Firewire device To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801806] Re: It appears that Natty removed most of the raw 1394 support in favor of firewire_core. This broke most dv capture setups in existence. Someone needs to readd raw1394 and ohci1394 kerne
> Basically firewire_core is seeing it... and creating a /dev/fw1 for it... > but that's pretty much useless everywhere for everything since nothing > is written to use firewire_core. libraw1394 is written to use it. Kino uses libraw1394; it does not access the kernel directly. Please describe in what way DV capture is broken. Also please attach the output of dmesg that contains messages from firewire.ohci and firewire-core - from when the OHCI-1394 host controller is initialized, - from when the camcorder is plugged in/ switched on, - from when Kino is started. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801806 Title: It appears that Natty removed most of the raw 1394 support in favor of firewire_core. This broke most dv capture setups in existence. Someone needs to readd raw1394 and ohci1394 kernel modules to ubuntu natty. please tell your security guys who are humping firewire_core to stop being retarded. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kino/+bug/801806/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 619601] Re: No DV firewire control of Sony DSR-PDX10p camera
If this is still unresolved for you, please post the output from the
following commands while the camcorder is connected and switched on:
grep -e 1394 -e firewire /proc/interrupts
ls /sys/bus/{ieee1394,firewire}/devices/
dmesg
lsmod
ls -l /dev/{raw1394,fw}*
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/619601
Title:
No DV firewire control of Sony DSR-PDX10p camera
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdenlive/+bug/619601/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 649542] Re: New firewire stack makes more FFADO XRUNs than old firewire stack.
If I understand the jackd logs correctly, jackd is running in the common SCHED_OTHER scheduling class rather than the SCHED_FIFO class. Have a look at http://jackaudio.org/linux_rt_config regarding the configuration steps to grant your account access to realtime scheduling classes. This is generally important for jackd in order to lower the likelihood of audio buffer underruns/ overruns. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/649542 Title: New firewire stack makes more FFADO XRUNs than old firewire stack. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libffado/+bug/649542/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 765799] [NEW] AIGLX reverts to software rendering on virtualbox with guest additions 4.0.5pre
Public bug reported: when running ubuntu 11.04, the Xlog contains: [34.138] (II) AIGLX: Trying DRI driver /usr/lib/dri/vboxvideo_dri.so [34.600] (II) Next line is added to allow vboxvideo_drv.so to appear as whit elisted driver [34.600] (II) The file referenced, is *NOT* loaded [34.600] (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so [34.601] (II) AIGLX: vboxvideo does not export required DRI extension [34.603] (II) AIGLX: Trying DRI driver /usr/lib/dri-alternates/vboxvideo_dri .so [34.625] (II) AIGLX: dlopen of /usr/lib/dri-alternates/vboxvideo_dri.so fail ed (/usr/lib/dri-alternates/vboxvideo_dri.so: cannot open shared object file: No such file or directory) [34.625] (EE) AIGLX: reverting to software rendering [34.625] (II) AIGLX: Trying DRI driver /usr/lib/dri/swrast_dri.so [35.314] (II) AIGLX: Loaded and initialized swrast ** Affects: xorg-server (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/765799 Title: AIGLX reverts to software rendering on virtualbox with guest additions 4.0.5pre -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 732641] Re: Resume from suspend fails on new FireWire stack (TSB43AB22/A IEEE-1394a-2000 Controller)
Upstream bug tracker entry: https://bugzilla.kernel.org/show_bug.cgi?id=31432 ** Bug watch added: Linux Kernel Bug Tracker #31432 http://bugzilla.kernel.org/show_bug.cgi?id=31432 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/732641 Title: Resume from suspend fails on new FireWire stack (TSB43AB22/A IEEE- 1394a-2000 Controller) -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 728033] Re: firewire - "blocked for more than 120 seconds"
upstream discussion: http://thread.gmane.org/gmane.linux.kernel.firewire.user/4116 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/728033 Title: firewire - "blocked for more than 120 seconds" -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 134222] Re: linux-kernel-header has files with size 0
WTH does anybody attempt to put drivers/ieee1394/* files into a linux- headers package? These files are not exported headers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/134222 Title: linux-kernel-header has files with size 0 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Steffen, please open a new bug for this (this is different) and leave a short note with the new bug number here so that I can have a look. Or mail the bug description to one of linux1394-u...@lists.sf.net or linux1394-de...@lists.sf.net. These mailinglists are open for posting without prior subscription. Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/6290 Title: DV capture over Firewire is broken (no rights for /dev/raw1394) -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 657081] Re: New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b
Joan: 1. "I am experiencing problems" is not a bug report. 2. Unibrain Fire-i is neither a storage device nor a 1394b device, like in this bug. 3. This bug here occurs only in firewire-ohci of kernel 2.6.35...2.6.35.7 and nothing else. 4. Ubuntu 10.04 with kernel 2.6.32 uses the older ohci1394 driver per default. Why are you commenting at this bug at all? Open a new bug with a detailed problem description. Or better yet, mail a detailed problem description to a relevant upstream mailinglist: linux1394-user if it seems to be a generic FireWire problem, coriander- user if the problems specifically occur in the Coriander capture software, libdc1394-devel if the problems occur in another libdc1394 based capture software. Because it is almost guaranteed that nobody who could help with problems like you might have is going to accidently see a report here on bugs.launchpad.net. (Cf. how Eric got his problem resolved.) -- New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b https://bugs.launchpad.net/bugs/657081 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 657081] Re: New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b
This patch will be included in upstream 2.6.35.8, expected to be released early next week. From there it will find its way into an Ubuntu 2.6.35 package update, I suppose. -- New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b https://bugs.launchpad.net/bugs/657081 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 657081] Re: New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b
Discussion on linux1394-user: http://thread.gmane.org/gmane.linux.kernel.firewire.user/4013 -- New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b https://bugs.launchpad.net/bugs/657081 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 550010] Re: Unable to transfer digital video content from SONY camcorder to PC
Robert Stagner's report is a duplicate of bug 6290 (no raw1394 rule in Ubuntu's udev ruleset). Re comment 2: Wrong tip. See bug 6290. Re comment 7: Vince McIntyre 's report, while motivated by the same bug, is something else. The dmesg indicates that the FireWire bus is malfunctioning on the physical level, i.e. that the hardware is defective. Re comment 8: Dvgrab and kino do not require the cycle timer register access that is tested by the utility and fixed up for VIA controllers by firewire-core in kernel 2.6.34 and later. Nor does this register affect the physical operation of the bus. The messages "isochronous cycle too long" come from a controller interrupt which is sent if the controller does not receive a so-called cycle start packet within a certain time interval. This indicates that there is something more fundamentally wrong with this camcorder (or combination of camcorder, cable, controller, and PC) than what was fixed in kernel 2.6.35 (an issue with buggy firmware on some but not all Sony camcorders which resulted in both the camcorder and the Linux PC issuing conflicting gap counts). Some more information about the problem may perhaps be revealed by # modprobe -r firewire-ohci # modprobe firewire-ohci debug=-1 Then plug the camcorder in and watch /var/log/messages. -- Unable to transfer digital video content from SONY camcorder to PC https://bugs.launchpad.net/bugs/550010 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320898] Re: Cant use firewire for DV capture
Re comment 7: > kernel: [ 63.316346] raw1394: Unknown symbol compat_alloc_user_space This is a different problem. Here, the kernel configuration with which raw1394.ko was compiled does not match the one with which the running kernel was compiled. -- Cant use firewire for DV capture https://bugs.launchpad.net/bugs/320898 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 529524] Re: Impossible to activate the new firewire kernel stack on Karmic or Lucid
Hi Huygens, Dan Dennedy wrote at bug #6290 comment #78: > I learned that you must update the initrd images after changing the blacklist > file: > sudo update-initramfs -k all -u I.e. because ohci1394 is present in the original initrd (initial RAM disk with a minimal preliminary root filesystem), it got bound to the OHCI-1394 controller during boot-up instead of firewire-ohci. (The wiki page at kernel.org does currently lack this extra information. I'll add it soon.) Later on, when ieee1394 discovered that an SBP-2 compliant device is present behind the OHCI-1394 controller, it sends an "uevent" to userspace with the SBP-2 module alias. Both the new firewire-core-based firewire-sbp2 driver and the old ieee1394-based sbp2 driver match this alias. Modprobe will load the first one of these modules (minus any that was blacklisted), in your case firewire-sbp2. firewire-core gets loaded as a prerequisite for firewire-sbp2. However, since firewire- core sees no controller (only ieee1394 sees one), firewire-sbp2 gets nothing to do either. You could use the SBP-2 device only if you manually load sbp2. /Or/ you manually unload ohci1394, then manually load firewire-ohci. After that, the new stack will work, including firewire-sbp2 being automatically loaded and bound to the SBP-2 device. /Or/ you can attempt to replace the initrd as described by Dan. That change will become effective at the next reboot. -- Impossible to activate the new firewire kernel stack on Karmic or Lucid https://bugs.launchpad.net/bugs/529524 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320898] Re: Cant use firewire for DV capture
ericbuntu, does "cat /proc/interrupts" show ohci1394? I wonder why no messages from ohci1394 and ieee1394 are present in your dmesg --- there should at least some from when the ohci1394 driver was loaded. According to the lspci output, the kernel has all information available that is required to detect that ohci1394 is to be bound to the FW323 chip. Did you cut too much out of the dmesg? (If you don't want to reboot to get a fresh new dmesg buffer, you can also run "modprobe -r dv1394 ohci1394; modprobe ohci1394" as root or with sudo and check whether anything new appears in dmesg at that time. If /yes/, then plug in/ switch on the camcorder and check dmesg again. Also run "grep . /sys/bus/ieee1394/devices/*/*". Post the outputs of dmesg and of the grep command here (as attachments if they are large). -- Cant use firewire for DV capture https://bugs.launchpad.net/bugs/320898 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Did you blacklist dv1394 and video1394 as well? Does an /etc/modprobe.conf exist on Ubuntu? If yes, regenerate it by "update-modules" or delete the file. modprobe ignores /etc/modprobe.d/* if /etc/modprobe.conf exists. Does the initrd contain ohci1394? Hard to tell how to check that, as I never create and use initrd myself. Maybe dmesg gives away whether ohci1394 was loaded early. OTOH, that should lead to _both_ modules being loaded, not only ohci1394. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
> There is apparently a lot of missing kernel support here There is nothing missing in the new stack. And what is missing in the old stack could have been added to it if development manpower would have been available, or better yet, development and deployment of the new stack could have been sped up with developer and tester manpower. > unsafe hacks around that won't be accepted upstream Do you mean upstream udev? They also accepted Ubuntu's video1394 and dv1394 rules that had typos in them such that they never matched. (Or they added the typos themselves when they merged Ubuntu's rules, I don't know. Commit 41e7f557.) The fact that they removed the raw1394 rule (commit a8cf7cf) with a mere pointer to this distro bug here but without an own analysis of costs vs. rewards or without checking back with raw1394/ libraw1394 developers also shows that upstream is not in a position to judge what is safe and unsafe. You Ubuntu developers OTOH (a) kept confusing device security with host security and raw1394 flaws with ohci1394/sbp2 flaws, (b) never analyzed the actual risks, (c) never analyzed the costs of the rule removal, (d) never researched potential alternatives. Upstream udev simply trusted your judgment, which was a mistake. (And I didn't push for a revert when I noticed this because I thought that the new firewire drivers would show up in distributions any day now or distributors would at least begin to ask for them, which was a mistaken belief on my side.) One more word on hacks: Ubuntu's raw1394 rule removal was initially motivated by host security implications but did not in fact solve them, because that's the wrong point to go at. It's ohci1394 and a feature of it on which sbp2 relied. > You are of course welcome to add one locally if you are in a trusted or single-user environment. That's 1990's Linux mindset. This is an unacceptable hack too. You OTOH were of course welcome to discuss your concerns and requirements with upstream kernel/ library/ application developers when you removed the rule in Ubuntu, or at least later when this change went upstream. I'm not even talking about contribution of tests or code. Hmm, maybe I should have taken initiative two years ago (that's when transparent dual stack capability was implemented in libraw1394 by Dan) and should have pushed for the new stack to be provided by default in Ubuntu. The then half-working new stack might have been preferable to the mostly non-working old stack as configured in Ubuntu. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Re comment 71: - If both stacks are installed but none blacklisted, then the kernel's driver core should first attempt to bind firewire-ohci before ohci1394. This is tied to the build order in the kernel's build system. However, it may go wrong for one or another reason; e.g. ohci1394 present in initrd or whatever. - The udev rules for firewire-core's files are fine; I referred to the missing rule for raw1394. (BTW, I hope that we as upstream stay in control of firewire udev rules now, but I'm afraid I cannot monitor udev development as closely as desirable.) -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
PS: Nice work, Ubuntu maintainers. Instead of helping upstream to get the raw1394 security issue resolved, your only contribution was to create a huge support workload for the various affected upstream projects. Not to mention the damaging user experience that you provided to your users, and later to users of several other distributions too when you pushed your ill-advised udev rules upstream. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
I agree with Dan's comment #68 except for the FFADO status. As the status message that Dan quotes correctly states, new kernel drivers + libraw1394 + FFADO are working together since end of 12/2009. The only issue is that a small fix in FFADO _may_ (or may not) be required that came after the FFADO release v2.0.0. (I believe that fix was not required in my own testing.) Everybody is still holding their breath for a 2.0.1 maintenance release or the much anticipated 2.1 feature release of FFADO --- except Debian who simply package current FFADO trunk which works fine. Hence Ubuntu or Ubuntu Studio et al should already have a fine FFADO package too. I guess we as upstream need to communicate more clearly that the new drivers should be used by default now, and the old ones blacklisted or disabled entirely. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 276463] Re: Enable new Firewire stack in default kernel config
Kernel 2.6.32 (2 December 2009) and libraw1394 v2.0.5 (26 December 2009) contain the fixes that are required for FFADO. Debugged and implemented by Jay Fenlason. I believe I had vanilla FFADO v2.0.0 running with these, but Debian's FFADO maintainer packages FFADO trunk which contains a small fix that is related to the new FireWire drivers. I don't know how essential that fix is. I heard FFADO is going to do a v2.0.1 maintenance release eventually; however, Debian's current FFADO package is closer t what will become FFADO v2.1 --- also to be released "any day now" with much extended hardware support (independent of whether old or new firewire kernel drivers are used). In short: After storage, consumer video, industrial video, and IP networking, FireWire audio as the last missing piece in the puzzle works through the new kernel driver stack too since end of 12/2009. Note that Ubuntu's current defaults (old stack, no user access to raw1394) effectively prevents non-experts from using FireWire for anything else than storage devices (and even those with less performance and compatibility than the new drivers offer). -- Enable new Firewire stack in default kernel config https://bugs.launchpad.net/bugs/276463 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 543343] Re: ath5k driver misspells the ESSID for ad-hoc networks
I noticed that this bug only occurs if I don't stop the network-manager. So I seems that the network-manager in Ubuntu lucid changes the ESSID! (service network-manager stop) -- ath5k driver misspells the ESSID for ad-hoc networks https://bugs.launchpad.net/bugs/543343 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 543343] Re: ath5k driver misspells the ESSID for ad-hoc networks
** Attachment added: "AlsaDevices.txt" http://launchpadlibrarian.net/41501512/AlsaDevices.txt ** Attachment added: "AplayDevices.txt" http://launchpadlibrarian.net/41501513/AplayDevices.txt ** Attachment added: "ArecordDevices.txt" http://launchpadlibrarian.net/41501514/ArecordDevices.txt ** Attachment added: "BootDmesg.txt" http://launchpadlibrarian.net/41501515/BootDmesg.txt ** Attachment added: "Card0.Amixer.values.txt" http://launchpadlibrarian.net/41501516/Card0.Amixer.values.txt ** Attachment added: "Card0.Codecs.codec.0.txt" http://launchpadlibrarian.net/41501517/Card0.Codecs.codec.0.txt ** Attachment added: "Card0.Codecs.codec.1.txt" http://launchpadlibrarian.net/41501518/Card0.Codecs.codec.1.txt ** Attachment added: "CurrentDmesg.txt" http://launchpadlibrarian.net/41501519/CurrentDmesg.txt ** Attachment added: "Dependencies.txt" http://launchpadlibrarian.net/41501520/Dependencies.txt ** Attachment added: "IwConfig.txt" http://launchpadlibrarian.net/41501521/IwConfig.txt ** Attachment added: "Lspci.txt" http://launchpadlibrarian.net/41501522/Lspci.txt ** Attachment added: "PciMultimedia.txt" http://launchpadlibrarian.net/41501523/PciMultimedia.txt ** Attachment added: "ProcCpuinfo.txt" http://launchpadlibrarian.net/41501524/ProcCpuinfo.txt ** Attachment added: "ProcInterrupts.txt" http://launchpadlibrarian.net/41501525/ProcInterrupts.txt ** Attachment added: "ProcModules.txt" http://launchpadlibrarian.net/41501526/ProcModules.txt ** Attachment added: "RfKill.txt" http://launchpadlibrarian.net/41501527/RfKill.txt ** Attachment added: "UdevDb.txt" http://launchpadlibrarian.net/41501528/UdevDb.txt ** Attachment added: "UdevLog.txt" http://launchpadlibrarian.net/41501529/UdevLog.txt ** Attachment added: "WifiSyslog.txt" http://launchpadlibrarian.net/41501530/WifiSyslog.txt -- ath5k driver misspells the ESSID for ad-hoc networks https://bugs.launchpad.net/bugs/543343 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 543343] [NEW] ath5k driver misspells the ESSID for ad-hoc networks
Public bug reported: I tried to set up a wireless ad-hoc network with my atheros wlan chip. But I did not get it work because the ath5k driver seems to be corrupt. After a few seconds the ESSID changed to a random value. The following script reproduces the error: ifconfig wlan0 down iwconfig wlan0 essid "WLAN" mode Ad-Hoc channel 3 ifconfig wlan0 up iwconfig wlan0 # correct output ifconfig wlan0 down iwconfig wlan0 essid "WLAN" mode Ad-Hoc channel 3 ifconfig wlan0 up sleep 3 iwconfig wlan0 # incorrect output I got the following output: r...@ubuntu:/home/ubuntu/Desktop# ./wlan-script.sh wlan0 IEEE 802.11bg ESSID:"WLAN" Mode:Ad-Hoc Frequency:2.422 GHz Cell: Not-Associated Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off wlan0 IEEE 802.11bg ESSID:"\xAA\x9A\xC2\x87CV\xA1\xB4c/\xFD\x9E\x0D\x80\xFE%\x0E \x14V\xB2+s\xA8\x01\xA9;\xA4\xA2\x92iM" Mode:Ad-Hoc Frequency:2.422 GHz Cell: Not-Associated Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off As you can see the ESSID changed to a random string after a delay of 3 seconds. So I can not set up a ad-hoc network ... Additional informations: - bug in Ubuntu lucid beta 1 (live system at pen drive) - lspci | grep Atheros 01:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01) - lsmod | grep ath ath5k 121856 0 mac80211 204598 1 ath5k ath 7611 1 ath5k cfg80211 126645 3 ath5k,mac80211,ath led_class 2864 3 ath5k,asus_laptop,sdhci best regards ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21. Architecture: i386 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ubuntu 3111 F pulseaudio CRDA: Error: [Errno 2] No such file or directory Card0.Amixer.info: Card hw:0 'NVidia'/'HDA NVidia at 0xdc6b8000 irq 22' Mixer name : 'Realtek ALC660-VD' Components : 'HDA:10ec0660,1043,0011 HDA:15433155,10431335,00100700' Controls : 18 Simple ctrls : 12 Date: Sun Mar 21 11:27:26 2010 DistroRelease: Ubuntu 10.04 LiveMediaBuild: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318) Lsusb: Bus 002 Device 002: ID 0b05:1712 ASUSTek Computer, Inc. BT-183 Bluetooth 2.0+EDR adapter Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 05e1:0501 Syntek Semiconductor Co., Ltd DC-1125 Webcam Bus 001 Device 002: ID 0d7d:1624 Phison Electronics Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: ASUSTeK Computer INC. F3T Package: linux-image-2.6.32-16-generic 2.6.32-16.25 ProcCmdLine: BOOT_IMAGE=(loop)/casper/vmlinuz boot=casper iso-scan/filename=/boot/iso/lucid-desktop-i386.iso quiet splash noeject noprompt -- ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-16.25-generic Regression: No RelatedPackageVersions: linux-firmware 1.32 Reproducible: Yes SourcePackage: linux TestedUpstream: Yes Uname: Linux 2.6.32-16-generic i686 dmi.bios.date: 06/01/2007 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F3TAS.226 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: F3T dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: 1.00 dmi.chassis.asset.tag: 0x dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTek Computer INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF3TAS.226:bd06/01/2007:svnASUSTeKComputerINC.:pnF3T:pvr1.0:rvnASUSTeKComputerINC.:rnF3T:rvr1.00:cvnASUSTekComputerINC.:ct10:cvr1.0: dmi.product.name: F3T dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK Computer INC. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 lucid -- ath5k driver misspells the ESSID for ad-hoc networks https://bugs.launchpad.net/bugs/543343 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Re comment 61: > Now i do not know what are the implications of unblocking the firewire-ohci, > but > that was the solution that made my kino/kdenlive worked beautifully The implication is that you switched from ohci1394 + ieee1394 + raw1394 ( /dev/raw1394 ) --- libraw1394 + libiec61883 + kino to firewire-ohci + firewire-core ( /dev/fw* ) --- libraw1394 + libiec61883 + kino i.e. to different newer FireWire kernel drivers and a different character device file interface. This is basically what the blueprint "Enable new Firewire stack in default kernel config" is about. (See box at the right side of this page.) The new kernel drivers are simpler, better performing, more compliant to specifications, and more secure than the older drivers. In contrast to Ubuntu's raw1394 access policy, firewire-core's device files are created with more liberal access permissions for devices which need to be (and are safe to be) accessed by userspace programs such as kino. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 514965] Re: raw1394_start_read return values not as documented
Discussion at linux1394-devel: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13805 -- raw1394_start_read return values not as documented https://bugs.launchpad.net/bugs/514965 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Re comment 56...59: > So when i have copied all the scenes to the computer, > you can work and edit the scenes without having the camera installed. > But when you want to export it to example mpeg or what ever, you cant > the following error "Error setting the IEEE 1394 port (host adaptor)" I tested this with Kino 1.3.3 on Gentoo Linux right now. While it is true that there is a message about failure to set the 1394 port when the "Export" mode is entered (which starts with the IEEE 1394 export tab up front), this failure does not prevent one from switching to any of the file export tabs and export to a file there. (I tried DV file export.) If file export does not work for you, then it is _not_ related to IEEE 1394 nor to Ubuntu's permission policy.(If it were, then I would have been able to reproduce it on Gentoo Linux.) The recommendation to try Kino 1.3.4 still stands though in case of any remaining export troubles. If an update still does not help --- or if it helps but Ubuntu package repositories (Universe or whatever) do not provide Kino 1.3.4 yet --- then please open a new bug. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
Robert Petersen wrote: > I am running Ubunto 9.10, and Kino 1.3.3 [...] > the biggest problem is actually that I have to plugin the camera to > use the program. So when i have copied all the scenes to the computer, > you can work and edit the scenes without having the camera installed. > But when you want to export it to example mpeg or what ever, you cant > the following error "Error setting the IEEE 1394 port (host adaptor)" This is a different bug. You could report it separately in a new bug entry. But before that, please test the current version of Kino first (version 1.3.4), which appears to be available as a package now. (I saw that Debian packaged it, hence I guess it is also available on Ubuntu. I don't have Debian or Ubuntu myself.) > So the fact that I went from windows to Linux was the free software, > but as I can see here, this problem has been there for around 4 years > now!! Free software means, among else, that distributors and/or users can fix problems themselves if they have the necessary knowledge or experience. And indeed, the /dev/raw1394 permissions problem - does not exist on several other distributions than Ubuntu, - can be fixed by Ubuntu users by adding a local udev rule (there is guidance somewhere on the Ubuntu wiki (help.ubuntu.com) as well as on the upstream wiki, see comment 55), - is going to be fixed in Ubuntu as well in a future release, when Ubuntu fully switches to newer kernel drivers which implement a superior device access concept and thus address the security concerns that were brought up by Ubuntu package maintainers and many others. On the other hand, free software does _not_ mean that everything works immediately or is being fixed for you, at no cost, in a matter of hours. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6290] Re: DV capture over Firewire is broken (no rights for /dev/raw1394)
I suspect they will fix it in a future Ubuntu release by replacing the kernel drivers ohci1394 + ieee1394 + raw1394 by the kernel drivers firewire-ohci + firewire-core. Presently, those newer drivers are already shipped in Ubuntu's kernel packages in parallel with the older drivers. The older ones are the default and the newer ones can be enabled by editing a respective system configuration file (kernel module blacklist, http://ieee1394.wiki.kernel.org/index.php/Juju_Migration #How_to_suppress_auto-loading) as administrator. Well, the other possible workaround on current Ubuntu also requires editing or creating a system configuration file (udev rule file for raw1394, http://ieee1394.wiki.kernel.org/index.php/FAQ#How_to_get_access_to_raw1394_as_unprivileged_user.3F). I doubt that the Ubuntu udev maintainer will suddenly reconsider his preference and re-introduce such a raw1394 rule, therefore expect to have to wait for a next release (Lucid perhaps?) to get this bug fixed by a switch to firewire-core as default kernel driver. -- DV capture over Firewire is broken (no rights for /dev/raw1394) https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 27287] Re: external firewire sbp2 login timeout
PS: Here is an article about the inner workings of Drobo and what this implies for its support by Linux (not FireWire-specific): http://groups.google.com/group/drobo-talk/web/linux-support?hl=en Due to Drobo and DroboPro firmware limitations, it is currently impractical to use a logical unit size larger than the default 2.0 TiB under Linux: http://groups.google.com/group/drobo-talk/browse_thread/thread/34f08da1708d2f7b I.e. if you have more than 2 TB net disk space built into the Drobo or DroboPro, it needs to be exposed to Linux as a 2nd and perhaps 3rd logical unit indeed. -- external firewire sbp2 login timeout https://bugs.launchpad.net/bugs/27287 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 27287] Re: external firewire sbp2 login timeout
Adam, the failure mode which you are reporting is different. a) The other reporters got a login timeout i.e. no login response. You get a login failure i.e. an error response. b) The problem reported by the others seemed to be generic, while I suspect your problem to be specific to the disk enclosure which you are using. According to the vendor OUI of the device, it is from Data Robotics, i.e. a Drobo or a DroboPro. Which one is it? How much disk capacity is in it (how many disks of what size, and how much of it is usable according to Data Robotics' size calculator)? Your log in comment 20 shows that one logical unit of 2.19 TB/ 1.99 TiB size was detected and should be fully functional (in the session you logged: /dev/sdb as the block device, with a single partition on it: /dev/sdb1). Furthermore, the log shows that two further logical units on this device were detected, but the sbp2 driver got an error status when it attempted to log in into these two logical units. Should your Drobo or DroboPro expose three logical units? What do you get when you connect it via USB? Are you able to test it with Windows or OS X? Is a current firmware installed on the Drobo or DroboPro? As far as I have read, Drobo and DroboPro will divide their total available disk space --- minus space required for redundancy etc. --- into logical units whose size can be configured with Data Robotics' dashboard application for Windows and OS X, or with the community- maintained drobo-utils for Linux. The default size of the logical units is 2 TiB (or TB?). (As a side note: If you want to use logical units bigger than 2.0 TiB over FireWire, you need a recent FireWire kernel driver update, released in the kernel.org versions 2.6.31, 2.6.30.5, and 2.6.27.30: http://ieee1394.wiki.kernel.org/index.php/Release_Notes . Without this driver update, FireWire disks larger than 2.0 TiB will be shown as merely 2.0 TiB sized. This is _not_ related to the login failures to your 2nd and 3rd logical unit though.) -- external firewire sbp2 login timeout https://bugs.launchpad.net/bugs/27287 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 27287] Re: external firewire sbp2 login timeout
I don't see anything related to 1394 in david's comments. Wrong bug number? - Those who still have sbp2 login failures should please try the following: - Make sure to have a somewhat recent kernel package which has firewire-ohci.ko installed in parallel with ohci1394.ko. - Switch from the drivers ohci1394 + ieee1394 + sbp2 to the drivers firewire-ohci + firewire-core + firewire-sbp2 by editing a module blacklist file: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#How_to_suppress_auto-loading This suggestion is because firewire-core + firewire-sbp2 bring enhancements WRT SBP-2 login (and further enhancements, e.g. to 1394a/S400 throughput). Alas I cannot be more specific which kernel package version is minimally required for this and which particular modprobe configuration file to edit since I don't have Ubuntu installed myself. -- external firewire sbp2 login timeout https://bugs.launchpad.net/bugs/27287 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313009] Re: dvgrab Error:no DV with Panasonic NV-MX500EG
The patch mentioned in comment #2 has been merged in mainline kernels 2.6.29, 2.6.28.5, and 2.6.27.16. I.e. it's fixed in Karmic. Do you know whether those 2.6.x.y updates went into Jaunty and Intrepid kernel packages? -- dvgrab Error:no DV with Panasonic NV-MX500EG https://bugs.launchpad.net/bugs/313009 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 186434] Re: K3B cannot detect DVD writer on Firewire (Sony DVD RW DRU-710A)
Lite-On DH-20A4P is not an USB drive, it is an ATAPI drive. Apparently you are using it in an extra USB enclosure or with an USB adapter. Which one? Check for firmware updates not only for the Lite-On ATAPI drive but also for the USB--IDE/ATAPI bridge. -- K3B cannot detect DVD writer on Firewire (Sony DVD RW DRU-710A) https://bugs.launchpad.net/bugs/186434 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 186434] Re: K3B cannot detect DVD writer on Firewire (Sony DVD RW DRU-710A)
Comment #0: >>> This device has both USB and Firewire interface. The bug described >>> below is ONLY relevant to the Firewire interface. Functions through >>> USB work as expected. Comment #3: > I have got same problem Ubuntu 9.04. > İ am using external usb dvd writer. It can't be /entirely/ the same problem. Please post all relevant messages from /var/log/messages (or from the dmesg command). Also, check whether Lite-On offers any firmware updates. -- K3B cannot detect DVD writer on Firewire (Sony DVD RW DRU-710A) https://bugs.launchpad.net/bugs/186434 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Since this seems to fix it, you can permanently replace ohci1394 + ieee1394 + sbp2 by the newer drivers firewire-ohci + firewire-core + firewire-sbp2. Check for relevant configuration files with "grep -r -e firewire -e 1394 /etc/mod*" and have a look at http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#How_to_suppress_auto-loading (I don't have Ubuntu installed here hence I don't know which particular config files need to be changed.) -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Re comment 33: No, this issue is not in ohci1394, it's in ieee1394's nodemgr thread and sbp2's device probe. Try the following: # modprobe -r ohci1394 # modprobe firewire-ohci && modprobe firewire-sbp2 Then plug the device in. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 414765] Re: empathy is not able to list jabber chat rooms at other servers
I forgot something ... ;-) ste...@cumputer:~$ uname -a Linux cumputer 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linux ste...@cumputer:~$ apt-cache policy telepathy-gabble telepathy-gabble: Installiert: 0.8.1-1~ppa9.04+1 Kandidat: 0.8.1-1~ppa9.04+1 Versions-Tabelle: *** 0.8.1-1~ppa9.04+1 0 500 http://ppa.launchpad.net jaunty/main Packages 100 /var/lib/dpkg/status 0.7.22-1ubuntu3 0 500 http://de.archive.ubuntu.com jaunty/universe Packages best regards Stefan -- empathy is not able to list jabber chat rooms at other servers https://bugs.launchpad.net/bugs/414765 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 414765] Re: empathy is not able to list jabber chat rooms at other servers
This bug appears in Ubuntu 9.04 with "http://ppa.launchpad.net/telepathy/ppa/ubuntu"; enabled (Linux cumputer 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linux). The bug also appears in Ubuntu 9.10 alpha4 (i386 Live-CD). best regards Stefan -- empathy is not able to list jabber chat rooms at other servers https://bugs.launchpad.net/bugs/414765 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 414765] Re: empathy is not able to list jabber chat rooms at other servers
** Summary changed: - empathy is not able to join some jabber chat rooms + empathy is not able to list jabber chat rooms at other servers -- empathy is not able to list jabber chat rooms at other servers https://bugs.launchpad.net/bugs/414765 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 414765] [NEW] empathy is not able to list jabber chat rooms at other servers
Public bug reported: Empathy is not able to list the correct chat rooms in the "Join Room" dialog. Every time it shows the chat rooms of "conference.jabber.org" (I'm registered there) and not the chat rooms of the server where I want to connect to (e.g. "conference.ubuntu-jabber.de"). So I'm not able to join some chat rooms. ** Affects: empathy (Ubuntu) Importance: Undecided Status: New -- empathy is not able to list jabber chat rooms at other servers https://bugs.launchpad.net/bugs/414765 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
OK, this is how it should be; raw1394 _should_ be automatically loaded with that when a DV device appears. Could be that the drivers have a special problem with your particular camera. Your local change to the udev rules does not influence autoloading, only how device file ownership is set up when /dev/raw1394 is created. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
Why does Ubuntu (or only your two test boxes?) not load raw1394 automatically when a DV device is plugged in? Are the module aliases somehow missing in Ubuntu's raw1394? (Run "modinfo raw1394".) Or does Ubuntu have a "blacklist raw1394" directive somewhere in /etc? (Run "grep -r 'blacklist raw1394' /etc/".) Or was the ieee1394 driver for some reason unable to identify your camera as DV device, thus never generated the hotplug even (so-called uevent) which would tell the userland to load raw1394? (The dmesg output would help to answer this.) See my previous comment. I would like to get more info about what's happening on Ubuntu since I do not have Ubuntu installed myself, hence can't check myself easily. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317227] Re: skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP
> I read in another bug though that ubuntu devs don't want bugs filed > upstream and instead want them filed with LP: ... > This inconsistency makes it difficult to know when to file upstream and > when not to. I'm not speaking for Canonical, I'm not even using Ubuntu. I'm only watching this bug because I am one of the upstream kernel driver developers (ieee1394; Carl's report was loosely related to 1394). If there is a possibility that a bug is an upstream bug --- and if your distributor has no manpower to look at bugs and to get in touch with upstream themselves --- then file a report with upstream. Best would be of course if one of you could test an unmodified kernel.org kernel for your report; ideally the latest release*. (Note, reports about kernels with proprietary drivers inserted into them do not have much value for bugzilla.kernel.org because such kernels cannot really be debugged.) *) Does Ubuntu have packages of vanilla kernels? -- skb_over_panic skbuff.c:128 invalid opcode: [1] SMP https://bugs.launchpad.net/bugs/317227 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317227] Re: skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP
> Does the fact that this bug has not been touched in 3 months mean there is no desire to fix it? It more likely means that nobody is here who knows the driver well enough to suggest a fix. You could report to upstream: net...@vger.kernel.org, Cc: Ayaz Abdulla (forcedeth developer). Upstream will be more interested in reports about untainted kernels though. Vanilla 2.6.29(.1) perhaps. -- skb_over_panic skbuff.c:128 invalid opcode: [1] SMP https://bugs.launchpad.net/bugs/317227 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317227] Re: skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP
> Does the fact that this bug has not been touched in 3 months mean there is no desire to fix it? I more likely means that nobody is here who knows the driver well enough to suggest a fix. You could report to upstream: net...@vger.kernel.org, Cc: Ayaz Abdulla (forcedeth developer). Upstream will be more interested in reports about untainted kernels though. Vanilla 2.6.29(.1) perhaps. -- skb_over_panic skbuff.c:128 invalid opcode: [1] SMP https://bugs.launchpad.net/bugs/317227 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 329277] Re: ieee1394 port not recognized
How does "lspci -v" show the controller? The PCI IDs look like from the Texas Instruments TSB43AB** family. The messages ohci1394: fw-host0: Get PHY Reg timeout [0x/0x/100] indicate that the drivers were unable to perform the last steps of initialization. For now I don't know why. What if you load the new alternative drivers instead of the old ones? According to your lspci, the new ones are installed in parallel already. The new drivers were quite buggy in kernel 2.6.24 though. # modprobe -r ohci1394 # modprobe firewire-ohci -- ieee1394 port not recognized https://bugs.launchpad.net/bugs/329277 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
454abp , if you use workaround 9 (i.e. 1 and 8 as in the patch) and the file manager freezes during iPod access, what do you get from "dmesg"? (If the UI becomes very unresponsive, try [Ctrl][Alt][F1] to get a text console.) -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
The patch from comment 16 has been merged in upstream released kernels 2.6.29-rc4, 2.6.28.5, and 2.6.27.16. -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
PeterNSteinmetz, this is different from the other reporters' issues. Yours is likely bad hardware, perhaps bad firmware. The drivers can't do anything about it. It could perhaps be caused by old revisions of 1394b physical interface chips (TI TSB81BA3 erratum without software workaround). If you have a 1394a (FireWire 400) device at hand, plug this into the bus too. This forces the bus to use slower and safer 1394a arbitration instead of 1394b arbitration. (But it can still work with 800 Mb/s data rate if the FireWire 400 device is located at an end of the bus, i.e. not between the FireWire 800 devices.) -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320099] Re: Ubuntu becomes unrepsonsive on resume with external firewire disk attached
Is it sufficient to remove only sbp2 but leave ohci1394 (and ieee1394 of course) loaded during suspend, with the disk attached? -- Ubuntu becomes unrepsonsive on resume with external firewire disk attached https://bugs.launchpad.net/bugs/320099 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 311771] Re: WD My Book doesn't properly unmount on PC shutdown
Well, unmounting a read-only filesystem may very well go through without any SCSI request... Anyway. Maybe the WD My Book does not handle the SCSI START STOP UNIT command like the Linux SCSI core expects. You could try adding a device quirks workaround which influences the parameters for this SCSI command. You can activate this workaround ad hoc by # modprobe sbp2 # echo 0x20 > /sys/module/sbp2/parameters/workarounds Then plug the disk in. You can enable this workaround permanently, i.e. persistent after any reboots and startups, by # echo "options sbp2 workarounds=0x20" >> /etc/modprobe.d/options But another reason could be that the WD My Book returns wrong SCSI status if it gets commands while in standby, leading the kernel's SCSI core to believe that all was fine and it hadn't to send START STOP UNIT at all. Then I don't see what could be done about it. -- WD My Book doesn't properly unmount on PC shutdown https://bugs.launchpad.net/bugs/311771 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
[raw1394 not loaded automatically] Could you post the output of "modinfo raw1394"? I'd like to check whether all device identifiers are in there as they should be. May be necessary to run it as root or to run it as "/sbin/modinfo raw1394". Also, if you have the camcorder around, please plug it in/ switch it on and post the result of "dmesg | tail -100" or at least the part of that which relates to the camcorder. [driver upgrade] Well, I didn't suggest that Ubuntu users should go try test kernels. This was just meant as a note that there is some development going on which will address the Ubuntu maintainers' security concerns (which I don't quite share). [promise of a works-out-of-the-box experience] Well, I don't know what promises Ubuntu really made. Anyway; reports like yours are important to come closer to that goal. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Oliver: I could not reproduce the problem with a brand-new LaCie Little Disk 500 GB on a few different controllers. But I found a little oddness of that disk in the process: http://marc.info/?l=linux1394-devel&t=12334064382 However, at least I have got an older CD-RW which shows the same symptoms as you and clarkkent435 reported if I attach it to Texas Instruments controllers (sometimes also on other controllers) so that I can work on it when I have some time to spare. (Well, from my own perspective as upstream driver maintainer, it's all fixed in the new firewire drivers.) Oliver, would it help to power the Little Disk via the USB power cable, then plug it into FireWire? -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 298533] Re: dv1394 driver is unsupported
For the record: The capture stalls which Carl mentioned are tracked in bug 298579. -- dv1394 driver is unsupported https://bugs.launchpad.net/bugs/298533 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 298533] Re: dv1394 driver is unsupported
dvgrab v3 uses only raw1394, not the dv1394 kernel module. The dv1394 special-purpose driver will actually stay in the kernel as log as the whole ieee1394 driver stack. But the new alternative firewire stack, which is meant to replace the ieee1394 stack eventually, won't provide an interface with binary compatibility to the dv1394 driver's interface. I guess I should change the dv1394 driver to emit the scary log message only when actually opened by an application, not immediately when the driver is initialized. -- dv1394 driver is unsupported https://bugs.launchpad.net/bugs/298533 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300239] Re: raw1394 DV sampling should work out-of-the-box
(I am maintainer of the upstream kernel's IEEE 1394 driver subsystem. I don't have Ubuntu myself.) > 8. Realize you need to modprobe raw1394 module into your running kernel. This could be a problem with Ubuntu's udev setup, or it could be a problem at the kernel level or hardware level. Whenever a DV/ miniDV/ HDV camcorder is plugged in and is recognized as such by the ieee1394 base driver (which needs the ohci1394 underneath), ieee1394 emits a hotplug event which should cause raw1394 be loaded automatically. raw1394's insertion should cause udev to create the /dev/raw1394 file, and at least that latter part apparently works for you. > 9. Also realize you must have special privileges in order to access the > device, > which are not granted to you by default. > 10. Grant yourself some privileges, or simply run the video editing > application > as root (via gksu). It is policy in Ubuntu to grant only the root user access to the /dev/raw1394 file. Most other distributions which provide the raw1394 driver grant every user in a "video" group or something like that access to /dev/raw1394. This is because of security concerns of the Ubuntu maintainers; see bug 6290. However, there is light at the end of the tunnel since we are getting new firewire drivers into shape which will allow distributors to implement finer grained access policies. The new drivers don't use a single device file for all devices but a file for each FireWire node (e.g. one for the controller, one for a plugged-in camera...). There appear to be Jaunty test kernel packages which have the new drivers enabled in parallel to the old ones for advanced users to try them. See also bug 276463 (driver migration) and bug 311804 (libraw1394 migration; libraw1394 v2 is required to freely switch between old drivers and new drivers, libraw1394 v2.0.1 enables fine-grained access permission policy). > a. You'll manage to start capturing video, and hope you wont drop > any frames which is rarely the case, as usually several frames are > dropped every now and again due to buffer underruns (what the...??) > even in no encoding capture mode (raw). So there are problems during FireWire I/O or related to disk I/O. There is DMA enabled for the harddisk, right? (hdparm -i /dev/... lists available and currently active DMA modes. It is highly likely that the kernel did enable DMA properly.) > b. You'll still get a "No camera found" error, which truely I'm in the > dark as to why. Could be the same as http://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 https://bugzilla.redhat.com/show_bug.cgi?id=449252 https://bugzilla.redhat.com/show_bug.cgi?id=477279 http://sourceforge.net/mailarchive/forum.php?thread_name=7aea52800901260333i2a47825dv95a838cad3e5ee90%40mail.gmail.com&forum_name=kino-dev Do you have a Panasonic or Samsung camcorder? It could presumably also happen with other camcorders though; it's just that we only discovered the nature of the problem and its solution very recently. > What I expected to happen, since things should 'just work', is that once > I plug in a camcorder to the 1394 jack, I'll get a popup window asking > me if I want to capture video from the device. Yes, that would be good to have. Would have to be implemented in Gnome and/or KDE. I don't know, maybe there is already integration of this sort between kernel -- KDE 4-- kdenlive. (kdenlive is in active development, while kino is retired to low maintenance mode.) > I also expect that a simple user, using the computer, wont need to > meddle with privileges, in order to get the actual device working for > them, That's, as mentioned, mostly a Ubuntu-specific problem, to be fixed in the short term by the user himself and in the long term by switching to the new drivers with more flexible permissions policy. Ironically, the new drivers are sponsored by Red Hat. Good for all Linux users but regarding the /dev/raw1394 issue especially good for Ubuntu users. > and will be able to make simple home movie DVDs easy, using some > simple editing tool (KINO?) out-of-the-box. DV capture does actually work out-of-the-box for quite a lot of people, besides the missing pop-up dialogue when a camera was plugged in, and besides Ubuntu's bug 6290. -- raw1394 DV sampling should work out-of-the-box https://bugs.launchpad.net/bugs/300239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320898] Re: Cant use firewire for DV capture
Please post the output of dmesg, at least everything from when the ohci1394 and ieee1394 driver initialize the controller and when the camcorder is plugged in/ switched on. -- Cant use firewire for DV capture https://bugs.launchpad.net/bugs/320898 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320099] Re: Ubuntu becomes unrepsonsive on resume with external firewire disk attached
Are there also no relevant messages left in the system log? What is the brand and exact model of the FireWire disk? -- Ubuntu becomes unrepsonsive on resume with external firewire disk attached https://bugs.launchpad.net/bugs/320099 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 311771] Re: WD My Book doesn't properly unmount on PC shutdown
The Western Digital FireWire disks have some non-standard power savings features which WD apparently tested only with some Windows PCs without care for compliance to the SCSI specs or IEEE 1394 specs. Are there any messages in the system log from when the system tries to unmount the disk, e.g. SCSI errors? (I am not a Ubuntu user myself, hence don't know into which log file you should look. It is typically /var/log/messages.) What happens if you manually unmount the disk after it went into standby? Does anything interesting appear in the output of "dmesg" then? -- WD My Book doesn't properly unmount on PC shutdown https://bugs.launchpad.net/bugs/311771 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302380] Re: rm: cannot remove `raw1394-': Read-only file system
This seems to be a packaging mistake. The /dev/raw1394 file should neither be created nor deleted by a package script. It should be automatically created and deleted by udev whenever the raw1394 kernel module is loaded and unloaded. -- rm: cannot remove `raw1394-': Read-only file system https://bugs.launchpad.net/bugs/302380 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 300157] Re: OpenCV and IEEE 1394 (FireWire) fails, libdc1394-13 vs libdc1394-22 conflict
> How do we suggest this to the upstream devs through Launchpad? Not at all. You go to the upstream developer contacts. The OpenCV project has its forum, perhaps there you can find somebody who would be interested in a port from the libdc1394 v1 API to the v2 API. If specific advice is needed in such an API port, the libdc1394-devel mailinglist will be a perfect place to ask. -- OpenCV and IEEE 1394 (FireWire) fails, libdc1394-13 vs libdc1394-22 conflict https://bugs.launchpad.net/bugs/300157 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 298579] Re: dvgrab, Error: no camera exists
> lhz: Yours is a different bug. Please open a new one and include the output from "dmesg" Also make a short not here about the new bug number. -- dvgrab, Error: no camera exists https://bugs.launchpad.net/bugs/298579 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 298579] Re: dvgrab, Error: no camera exists
lhz: Yours is a different bug. Please open a new one and include the output from "dmesg", including the portions where ohci1394 and ieee1394 initialize the controller and from when the camcorder was plugged in/ switched on. Back to Carl's bug: Discussion without definite result went on at http://sourceforge.net/mailarchive/forum.php?thread_name=492048AD.4010201%40personnelware.com&forum_name=kino-dev http://sourceforge.net/mailarchive/forum.php?thread_name=4921B92A.8050101%40personnelware.com&forum_name=kino-dev and possibly some other threads. It's a hardware problem which can very certainly /not/ be fixed in software. -- dvgrab, Error: no camera exists https://bugs.launchpad.net/bugs/298579 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 298549] Re: dvgrab -showstatus = segfault
I'm not sure, did you already post at kino-dev about this? It's perhaps fixed by libiec61883 1.2.0 (released 2009-01-15) or dvgrab 3.2 (2008-08-04) or dvgrab 3.3 (2009-01-15). -- dvgrab -showstatus = segfault https://bugs.launchpad.net/bugs/298549 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 283612] Re: ohci1394 driver loop at boot time (Iso Xmit # Context died)
The problem is that the ohci1394 driver gets only garbage when it performs MMIO accesses. The core kernel is unable to set up the memory- mapped IO correctly, I suppose due to an issue with the BIOS. Neither "pci=noacpi" nor suppressing to leave some of the applicable drivers off (by blacklisting them) is a good permanent solution. What you could try: - Look for a BIOS update. - Try the newest kernel that you can get your hand on. Is it possible to install Jaunty test kernel packages on Intrepid? - Report the problem together with data about your kernel and your mainboard to linux-a...@vger.kernel.org. -- ohci1394 driver loop at boot time (Iso Xmit # Context died) https://bugs.launchpad.net/bugs/283612 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 264201] Re: jackd crashed using freebob cannot complete execution of processing graph ... zombified
Is this problem perhaps limited to certain FireWire controllers? You can check with "lspci" for the controller type. Did the same hardware work with older kernels? -- jackd crashed using freebob cannot complete execution of processing graph ... zombified https://bugs.launchpad.net/bugs/264201 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
PeterNSteinmetz wrote on 2009-01-31: > there a large number of complaints that > > ieee1394: The root node is not cycle master capable; selecting a new > root node and resetting... > > Eventually this stops repeating. Could be flaky hardware or an issue between driver and firmware. Try unloading the 1394 drivers, then "modprobe ieee1394 disable_irm=1 && modprobe ohci1394". > And then there is the complaint > > ieee1394: Error parsing configrom for node 0-00:1023 These errors can be temporary (then they are harmless) or terminal (which would be bad). In your case its just temporary, otherwise the sbp2 driver would never be attached to the device. > I would certainly appreciate any other suggestions on what I could > try to get this tape drive working under ubuntu. It is reported to > work under FreeBSD, so perhaps I'll try that next. Like everybody else who reported here at this bug, you should try the new alternative firewire drivers as mentioned in comment 21. These new drivers are meant to replace the classic ones eventually, when the new drivers became feature-complete and fully stable. (firewire- core replaces ieee1394, raw1394, video1394. firewire-ohci replaces ohci1394. firewire-sbp2 replaces sbp2.) The new drivers are smaller, more correct, more secure, and better performing than the old ones. The one CD-RW of mine which behaves like described in this bug when attached to Texas Instruments controllers (and sometimes also on other controllers) works perfectly with the new drivers. As I wrote in comment 21, you get these new drivers if you install a Jaunty test kernel package; see bug 276463. But since you already modified your kernel, you could also configure the new drivers in into your current kernel. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
PeterNSteinmetz wrote on 2009-01-28: > I understand this chip has had issues in the past under Linux kernels, and I > see in the > dmesg that a workaround is being used. The comments in the source (sdp2.c) > for this > workaround note, however, that this may have been only necessary for their > older > products, and the lookup is using a wildcard for the model_id. > > So is it possible, with the latest firmware upgrades, that this workaround > itself is > causing the timeout on login? No, it doesn't. This particular workaround only influences behaviour of the SCSI layer which only kicks in after a successful login. > (the workaround seems to be chopping the length in the request to conform to > some > older windows bug) More precisely, it tells the Linux SCSI core how to set the ALLOCATION LENGTH parameter in the SCSI INQUIRY command. (See the SPC spec, section "Commands for all device types", "INQUIRY command", if you are interested in the details.) IIRC this was of more importance a few years ago in earlier revisions of the SCSI core. Nowadays the SCSI core sets it to 36 bytes in the first attempt of INQUIRY anyway. If the 36 byte INQUIRY is successful, the SCSI core will run a retry with a larger ALLOCATION LENGTH unless the device was blacklisted (because it returns wrong results with larger lengths or crashes or whatever). The reference to Windows in sbp2.c's comment basically means that popular Windows flavors apparently issue only 36 byte INQUIRYs, hence firmware authors don't easily notice if they made a mistake in their INQUIRY handler. So, the SBP2_WORKAROUND_INQUIRY_36 merely influences behaviour _after_ successful login and _after_ successful first INQUIRY SCSI transaction. Furthermore, an ALLOCATION LENGTH bigger than 36 bytes, if it is supported by the device, returns information that is mostly uninteresting for FireWire devices, except for marginally interesting claims of conformance to SCSI specifications in addition to the conformance claims made in the first 8 bytes of the INQUIRY response. > And if this is true, is there a way to turn off the workaround? So, you don't need to turn the hard-wired workaround off; yet you can do so easily: # echo 0x100 > /sys/module/sbp2/parameters/workarounds This, like any other echo command into sbp2's workaround parameter file, becomes effective at the next time a device is plugged in. # modinfo sbp2 has a brief overview of available workarounds flags. Note that usage of the workarounds module parameter is only meant as a measure of last resort, hence we don't provide actual documentation of it besides the sbp2.c source. > Or perhaps modify this module to identify the devices for which the > workaround is > really needed? This is impossible because we don't know which Initio firmwares are affected and whether they have any identifiers that differ from unaffected variants. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
I wrote: > This particular workaround only influences behaviour of the SCSI layer > which only kicks in after a successful login. This is actually true for all currently available sbp2 workarounds. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Registered as upstream bug at http://bugzilla.kernel.org/show_bug.cgi?id=12572 -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
I don't know yet when I be able to do something about this. Until then you could try the following if you want: Install the latest Jaunty kernel package (2.6.28 based). Boot that kernel. Then, # modprobe -r ohci1394 # modprobe firewire-ohci # modprobe firewire-sbp2 Then plug in the drive and hopefully enjoy smooth operation. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
revised patch posted at http://lkml.org/lkml/2009/1/28/456 My questions from comments 11 and 13 have already been answered by http://lkml.org/lkml/2009/1/28/428 -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
diefans, is this the LaCie Little Disk, USB 2.0 + FireWire 400, with shortcut button? -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
test patch posted at http://lkml.org/lkml/2009/1/24/83 -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
454abp and Kevin, please also post the result of "ls /sys/bus/ieee1394/devices/*/model_id" from when the iPod is connected. -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294391] Re: Firewire IPOD does not work since upgrade to 8.10
Kevin, what hardware platform do you have? Intel or AMD or...? Do you know on which chipset (nortbridge, southbridge) your maiboard is based on? -- Firewire IPOD does not work since upgrade to 8.10 https://bugs.launchpad.net/bugs/294391 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
