Thread: Changes to the FireWire kernel drivers in Linux 3.1
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: Stefan R. <st...@s5...> - 2011-10-02 10:50:58
|
Hi all,
Linux 3.1 is due to be released later this month; it is currently
available as release candidate 8. Among the usual small corrections and
improvements, the following changes to the IEEE 1394 kernel drivers were
released:
Documentation:
- Some introductory documentation to the <linux/firewire-cdev.h> API was
added in Documentation/ABI/stable/firewire-cdev. Inline documentation
in the API header file was improved.
- Added documentation of the firewire-core and firewire-sbp2 sysfs ABIs
in Documentation/ABI/stable/sysfs-bus-firewire.
<linux/firewire-cdev.h> API corrections:
- The error return in case of an unknown ioctl number no has errno set
to ENOTTY instead of EINVAL. Also fixed in kernel 3.0.1.
- The first FW_CDEV_IOC_GET_INFO ioctl is clarified to start reception of
bus reset events; earlier bus reset events are discarded. This ensures
events with well-defined closure value under all circumstances. Also
fixed in kernel 3.0.1.
- Fixed an issue with 32 bit userland drivers on top of 64 bit kernel,
resulting in FW_CDEV_IOC_GET_INFO failing with EFAULT. libraw1394 and
libdc1394 were not affected by this issue.
firewire-core:
- Fixed "giving up on config rom" failures in detection of some older
Panasonic based camcorders, e.g. Panasonic AG-EZ30 and NV-DX110,
Grundig Scenos DLC 2000.
(The fix addresses transaction failures to these camcorders which had
more severe effect on the current driver stack than on the linux1394
drivers of kernel 2.6.36 and older. While basic DV capture without
AV/C control works with these camcorders now, more work at the
userland library is necessary for full interoperability. This has
been discussed on linux1394-devel but not yet finalized.)
firewire-ohci:
- Continuing the optimization work that was released in kernel 3.0,
CPU utilization during packet queueing was reduced further, benefiting
all higherlevel 1394 kernel drivers and userland drivers.
- Fix I/O and PM suspend with O2Micro PCIe FireWire controllers by
blacklisting MSI on them. Also to be fixed in kernel 3.0.5.
- A fix in the core kernel's memory management addresses firewire-ohci
startup failures with kernels that were configured for a maximum number
of CPUs of something else than a power of two. This was a regression
since kernel 2.6.38. Also fixed in kernel 3.0.3.
firewire-sbp2:
- Fix panic when the module was unloaded while a management transaction
was still pending, e.g. login. This was a regression since kernel 3.0.
As long as the kernel.org services are still down, source code and
tarballs are available at the following locations:
Linux kernel:
git:
git://github.com/torvalds/linux
gitweb:
https://github.com/torvalds/linux
tarballs:
https://github.com/torvalds/linux/downloads
IEEE 1394 kernel subsystem:
git:
git://git.user.in-berlin.de/s5r6/linux1394.git
IEEE 1394 base libraries:
git:
git://git.user.in-berlin.de/s5r6/libraw1394.git
git://git.user.in-berlin.de/s5r6/libiec61883.git
gitweb:
https://redmine.user.in-berlin.de/projects/libraw1394/repository
https://redmine.user.in-berlin.de/projects/libiec61883/repository
tarballs:
https://redmine.user.in-berlin.de/projects/libraw1394/files
https://redmine.user.in-berlin.de/projects/libiec61883/files
Enjoy,
--
Stefan Richter
-=====-==-== =-=- ---=-
http://arcgraph.de/sr/
|
|
From: Stefan R. <st...@s5...> - 2011-10-05 21:51:51
|
On Oct 02 Stefan Richter wrote: > Linux 3.1 is due to be released later this month; it is currently > available as release candidate 8. Among the usual small corrections and > improvements, the following changes to the IEEE 1394 kernel drivers were > released: [...] PS, unrelated to the 1394 subsystem but related to 1394 storage devices: The last few kernel releases had multiple bugs WRT hot removal of hard disks, CD ROM drives, card readers and so on. The word is that the last known one of these bugs has been fixed in 3.1-rc9 from yesterday. -- Stefan Richter -=====-==-== =-=- --=-= http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-11-03 18:05:44
|
On Oct 05 Stefan Richter wrote: > PS, unrelated to the 1394 subsystem but related to 1394 storage devices: > The last few kernel releases had multiple bugs WRT hot removal of hard > disks, CD ROM drives, card readers and so on. The word is that the last > known one of these bugs has been fixed in 3.1-rc9 from yesterday. Not true. Sadly, the Linux block layer remains buggy WRT device removal. AFAIU a thorough rework of the block layer with introduction of proper reference counting is required to get this class of bugs really fixed. Considering that there was a steady, frequent stream of related bug reports for about a year now, and presumed fix after presumed fix was applied without ultimate progress in the matter, it is easy to make an estimate how quick this is going to be resolved. While I did not see a kernel panic anymore myself lately, processes and kernel threads tend to fall into uninterruptible wait state if a storage device is removed. Note to self: Always kill udisks-deamon before removing a CD-ROM drive or a card reader, to reduce exposure to race conditions. -- Stefan Richter -=====-==-== =-== ---== http://arcgraph.de/sr/ |
|
From: Allan D. <al...@fa...> - 2011-11-03 22:16:27
|
On 04/11/11 05:05, Stefan Richter wrote: > On Oct 05 Stefan Richter wrote: >> PS, unrelated to the 1394 subsystem but related to 1394 storage devices: >> The last few kernel releases had multiple bugs WRT hot removal of hard >> disks, CD ROM drives, card readers and so on. The word is that the last >> known one of these bugs has been fixed in 3.1-rc9 from yesterday. > > Not true. Sadly, the Linux block layer remains buggy WRT device removal. > AFAIU a thorough rework of the block layer with introduction of proper > reference counting is required to get this class of bugs really fixed. > Considering that there was a steady, frequent stream of related bug reports > for about a year now, and presumed fix after presumed fix was applied > without ultimate progress in the matter, it is easy to make an estimate > how quick this is going to be resolved. > > While I did not see a kernel panic anymore myself lately, processes and > kernel threads tend to fall into uninterruptible wait state if a storage > device is removed. > > Note to self: Always kill udisks-deamon before removing a CD-ROM drive or > a card reader, to reduce exposure to race conditions. Is it viable to add reference counting to your corner of the world so that at least the 1394 subsystem keeps itself nice? |
|
From: Stefan R. <st...@s5...> - 2011-11-04 09:52:44
|
On Nov 04 Allan Duncan wrote: > On 04/11/11 05:05, Stefan Richter wrote: [storage device unplug bugs] > > AFAIU a thorough rework of the block layer with introduction of proper > > reference counting is required to get this class of bugs really fixed. [...] > Is it viable to add reference counting to your corner of the world so > that at least the 1394 subsystem keeps itself nice? As far as I can tell, the race conditions in block request queue management happen at a level at which the transport drivers (1394, SATA, USB...) are unable to save the day with their own reference counting or locking. -- Stefan Richter -=====-==-== =-== --=-- http://arcgraph.de/sr/ |
|
From: Jack C. <jac...@ma...> - 2011-11-23 02:13:49
|
Stephan Richter, I have been relying on Ubuntu 11.10 and I must reboot to minimize expose to this problem. Also, I redistribute a shareware application in a bootable iso file, and I need to remaster when this is fixed. Please send a heads-up when you know anything positive about this problem. Thanks. Jack Chaney On Nov 3, 2011, at 11:05 AM, Stefan Richter wrote: > On Oct 05 Stefan Richter wrote: >> PS, unrelated to the 1394 subsystem but related to 1394 storage devices: >> The last few kernel releases had multiple bugs WRT hot removal of hard >> disks, CD ROM drives, card readers and so on. The word is that the last >> known one of these bugs has been fixed in 3.1-rc9 from yesterday. > > Not true. Sadly, the Linux block layer remains buggy WRT device removal. > AFAIU a thorough rework of the block layer with introduction of proper > reference counting is required to get this class of bugs really fixed. > Considering that there was a steady, frequent stream of related bug reports > for about a year now, and presumed fix after presumed fix was applied > without ultimate progress in the matter, it is easy to make an estimate > how quick this is going to be resolved. > > While I did not see a kernel panic anymore myself lately, processes and > kernel threads tend to fall into uninterruptible wait state if a storage > device is removed. > > Note to self: Always kill udisks-deamon before removing a CD-ROM drive or > a card reader, to reduce exposure to race conditions. > -- > Stefan Richter > -=====-==-== =-== ---== > http://arcgraph.de/sr/ > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |
|
From: Stefan R. <st...@s5...> - 2011-11-26 09:36:15
|
On Nov 22 Jack Chaney wrote: [block layer bugs WRT device removal] > I have been relying on Ubuntu 11.10 and I must reboot to minimize > expose to this problem. Also, I redistribute a shareware application > in a bootable iso file, and I need to remaster when this is fixed. > > Please send a heads-up when you know anything positive about this > problem. Thanks. This is not what you are waiting for to hear, but alas the current 3.2.0-rc still contains issues of this kind: http://marc.info/?l=linux-scsi&m=132214509516626 -- Stefan Richter -=====-==-== =-== ==-=- http://arcgraph.de/sr/ |
|
From: Michal S. <hra...@ce...> - 2011-11-26 12:00:42
|
On 26 November 2011 10:36, Stefan Richter <st...@s5...> wrote: > On Nov 22 Jack Chaney wrote: > [block layer bugs WRT device removal] >> I have been relying on Ubuntu 11.10 and I must reboot to minimize >> expose to this problem. Also, I redistribute a shareware application >> in a bootable iso file, and I need to remaster when this is fixed. >> >> Please send a heads-up when you know anything positive about this >> problem. Thanks. > > This is not what you are waiting for to hear, but alas the current > 3.2.0-rc still contains issues of this kind: > http://marc.info/?l=linux-scsi&m=132214509516626 For me the latest 3.2 rc fixed an issue with kernel bug when removing an USB floppy so there are some improvements. Or maybe I was just lucky and did not see the error because the block device happened to always go away at the right time. 3.2 is worth some testing I guess, though. Thanks Michal |
|
From: Stefan R. <st...@s5...> - 2011-12-25 21:51:28
|
On Nov 26 Michal Suchanek wrote: > On 26 November 2011 10:36, Stefan Richter <st...@s5...> wrote: > > On Nov 22 Jack Chaney wrote: > > [block layer bugs WRT device removal] > >> I have been relying on Ubuntu 11.10 and I must reboot to minimize > >> expose to this problem. Also, I redistribute a shareware application > >> in a bootable iso file, and I need to remaster when this is fixed. > >> > >> Please send a heads-up when you know anything positive about this > >> problem. Thanks. > > > > This is not what you are waiting for to hear, but alas the current > > 3.2.0-rc still contains issues of this kind: > > http://marc.info/?l=linux-scsi&m=132214509516626 > > For me the latest 3.2 rc fixed an issue with kernel bug when removing > an USB floppy so there are some improvements. > > Or maybe I was just lucky and did not see the error because the block > device happened to always go away at the right time. > > 3.2 is worth some testing I guess, though. 3.2-rc7 panics if a program has a /dev/sr* open and issues an ioctl after the device was unplugged. Happens with 1394 CD-ROMs and USB CD-ROMs and is 100% reproducible. http://marc.info/?l=linux-scsi&m=132484684720593 When you plan to unplug a CD-ROM or card reader or any other drive which announced itself as a removable media device (or when you don't plan to unplug it but happen to trip over the cable), and you don't think you have any program running anymore which still has a /dev/sr* open, then remember: If udisks-daemon or hald is running, it may open the device at any moment and thus trigger the same kernel panic right after device removal. -- Stefan Richter -=====-==-== ==-- ==--= http://arcgraph.de/sr/ |
Thanks for helping keep SourceForge clean.
X