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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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
[
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
The help.ubuntu.com page and the Kino message are a bit outdated. With newer
kernels, the software stack looks like this:
hardware -- firewire-ohci (kernel driver) -- firewire-core (kernel driver) --
libraw1394 -- Kino
Please post the following information:
lspci -nn | grep 1394
grep
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
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
[
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.
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
--
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:
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
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
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
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
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
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
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),
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
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
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
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
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
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
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
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
** 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
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
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
+
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.
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
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
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
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
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
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.
-
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
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
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
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
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
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
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
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
** 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
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
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'
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 aabdu...@nvidia.com (forcedeth
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 aabdu...@nvidia.com
(forcedeth
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
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
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
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
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
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
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
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-develt=12334064382
However, at least I have got an older CD-RW which shows the same
[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/
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
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
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
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
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,
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
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
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.
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
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
(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.
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
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
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
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
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
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
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
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
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.
--
I agree with mbeili.
FYI, the patch is currently staged in kernel.org's linux1394-2.6.git's
fixes branch. I will push this for 2.6.29-rc circa in a week or so
together with some unrelated updates, and after that propose it for
inclusion into kernel.org's 2.6.28.y and 2.6.27.y. You may want to
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
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
1 - 100 of 186 matches
Mail list logo
