linux1394-user Mailing List for IEEE 1394 for Linux (Page 11)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris Wj <chr...@gm...> - 2012-03-30 17:41:58
|
On Fri, Mar 30, 2012 at 3:09 AM, Clemens Ladisch <cl...@la...> wrote: > Stefan Richter wrote: > > Chris Wj wrote: > >>> I noticed that the libraw1394 code does not implement multi-channel > >>> reception yet. > > > > The fact that libraw1394 does not implement multi-channel reception via > > the current firewire kernel drivers is just a libraw1394 bug of the > > fixable, missing-feature kind. > > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. > > Is this problem applicable only to multi-channel receive mode? > > Regards, > Clemens > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > |
From: Chris Wj <chr...@gm...> - 2012-03-30 12:18:21
|
On Thursday, March 29, 2012, Stefan Richter <st...@s5...> wrote: > On Mar 29 Chris Wj wrote: >> With the new firewire-core (Juju) modules, I am no longer limited by the >> system's pagesize, correct? I am expecting S800 8K packets and the page >> size of the x86_64 system is set to 4K. > > This should indeed work. IIRC there are libdc1394 users who do actually > capture video streams with packets larger than 4 kiB. > > So our software supports that, but be warned that Texas Instruments > controllers will not work for you. They have a too small isochronous > reception FIFO and will inevitably give you corruption due to dropped (or > maybe incomplete?) packets. > > You are going to need Agere FW643E or FW643E2 controllers for this; they > have suitably large FIFOs. > > Also make sure that the two simultaneous streams won't overuse the > available bus bandwidth. Here are two tables with the constraints: > http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_can_I_work_out_the_frame_rate_from_the_packet_size > E.g. if you divided the overall isochronous bandwidth of an S800 bus > equally between two streams and keep a constant data rate throughout each > cycle, each stream's packets could be at most 75 MiB/s / 2 * 125 µs = 4.8 > kiB large. But I suppose the designer of the device and of its stream > format took this into account. > >> While I will not use it, I am curious about the multi-channel receive mode. >> Is it part of a specification? Is it basically creating a single contiguous >> buffer from the data from multiple channels? > > It is defined by OHCI-1394 v1.1 and also by its predecessor OHCI-1394 > v1.0. https://ieee1394.wiki.kernel.org/ has a page with links to various > specifications, among them "1394 Open Host Controller Interface > Specification" vulgo OHCI-1394 which is available at no cost. > > Multi-channel IR DMA is a variant of buffer-fill IR DMA. You find it > described in sections 10.2.1 and 10.6.1 of the spec. > > In your initial post you wrote that you want to process the two streams > separately and possibly in two threads. Multi-channel IR DMA is not a > good choice for this since the controller would just stuff all packets (of > all streams to which this DMA is told to listen to) into the reception > buffer in order of arrival. An application like yours would have to > separate the streams again before or during processing. > >>> I noticed that the libraw1394 code does not implement multi-channel >>> reception yet. > > The fact that libraw1394 does not implement multi-channel reception via > the current firewire kernel drivers is just a libraw1394 bug of the > fixable, missing-feature kind. When multi-channel reception was > implemented in the firewire kernel drivers, I started to write the > matching libraw1394 code but got distracted at 33 % completion. > > That said, libraw1394 is generally not recommended for new development. > This is not mant as a general deprecation of libraw1394; it will be > available and maintained for as long as there is FireWire support on > Linux. But libraw1394's API is lower-level than necessary and > than desirable in almost any application domain. Sure enough, the > alternative which would be the <linux/firewire-cdev.h> API, being an > ioctl(2)/read(2) based API, is naturally ugly and low-level too, but it > nevertheless is actually higher-level than <libraw1394/raw1394.h> in a few > respects. On the other hand, <linux/firewire-cdev.h> may provide more > control than <libraw1394/raw1394.h> to those who are keen on more control. > -- > Stefan Richter > -=====-===-- --== ====- > http://arcgraph.de/sr/ > Thank you very much for the helpful information. Time to get coding! Do you have any pointers to some example code that I can study? Best, -Chris |
From: Stefan R. <st...@s5...> - 2012-03-30 07:37:16
|
On Mar 30 Clemens Ladisch wrote: > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. Sigh. Thanks for the report. -- Stefan Richter -=====-===-- --== ====- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-03-30 07:06:47
|
Stefan Richter wrote: > Chris Wj wrote: >>> I noticed that the libraw1394 code does not implement multi-channel >>> reception yet. > > The fact that libraw1394 does not implement multi-channel reception via > the current firewire kernel drivers is just a libraw1394 bug of the > fixable, missing-feature kind. Well, there is the slight problem that the Juju IR buffer-fill code has the same problem that the old AR code had, i.e., if a packet has been split over three or more descriptors, the controller is not required to update the middle descriptor(s), so the descriptor parsing loop just stops. This might be easier to trigger because applications can submit buffers smaller than a page. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2012-03-29 23:50:24
|
On Mar 29 Chris Wj wrote: > With the new firewire-core (Juju) modules, I am no longer limited by the > system's pagesize, correct? I am expecting S800 8K packets and the page > size of the x86_64 system is set to 4K. This should indeed work. IIRC there are libdc1394 users who do actually capture video streams with packets larger than 4 kiB. So our software supports that, but be warned that Texas Instruments controllers will not work for you. They have a too small isochronous reception FIFO and will inevitably give you corruption due to dropped (or maybe incomplete?) packets. You are going to need Agere FW643E or FW643E2 controllers for this; they have suitably large FIFOs. Also make sure that the two simultaneous streams won't overuse the available bus bandwidth. Here are two tables with the constraints: http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_can_I_work_out_the_frame_rate_from_the_packet_size E.g. if you divided the overall isochronous bandwidth of an S800 bus equally between two streams and keep a constant data rate throughout each cycle, each stream's packets could be at most 75 MiB/s / 2 * 125 µs = 4.8 kiB large. But I suppose the designer of the device and of its stream format took this into account. > While I will not use it, I am curious about the multi-channel receive mode. > Is it part of a specification? Is it basically creating a single contiguous > buffer from the data from multiple channels? It is defined by OHCI-1394 v1.1 and also by its predecessor OHCI-1394 v1.0. https://ieee1394.wiki.kernel.org/ has a page with links to various specifications, among them "1394 Open Host Controller Interface Specification" vulgo OHCI-1394 which is available at no cost. Multi-channel IR DMA is a variant of buffer-fill IR DMA. You find it described in sections 10.2.1 and 10.6.1 of the spec. In your initial post you wrote that you want to process the two streams separately and possibly in two threads. Multi-channel IR DMA is not a good choice for this since the controller would just stuff all packets (of all streams to which this DMA is told to listen to) into the reception buffer in order of arrival. An application like yours would have to separate the streams again before or during processing. >> I noticed that the libraw1394 code does not implement multi-channel >> reception yet. The fact that libraw1394 does not implement multi-channel reception via the current firewire kernel drivers is just a libraw1394 bug of the fixable, missing-feature kind. When multi-channel reception was implemented in the firewire kernel drivers, I started to write the matching libraw1394 code but got distracted at 33 % completion. That said, libraw1394 is generally not recommended for new development. This is not mant as a general deprecation of libraw1394; it will be available and maintained for as long as there is FireWire support on Linux. But libraw1394's API is lower-level than necessary and than desirable in almost any application domain. Sure enough, the alternative which would be the <linux/firewire-cdev.h> API, being an ioctl(2)/read(2) based API, is naturally ugly and low-level too, but it nevertheless is actually higher-level than <libraw1394/raw1394.h> in a few respects. On the other hand, <linux/firewire-cdev.h> may provide more control than <libraw1394/raw1394.h> to those who are keen on more control. -- Stefan Richter -=====-===-- --== ====- http://arcgraph.de/sr/ |
From: Chris Wj <chr...@gm...> - 2012-03-29 19:47:56
|
On Thu, Mar 29, 2012 at 3:20 PM, Clemens Ladisch <cl...@la...> wrote: > Chris Wj wrote: > > So it seems like in my case, I will not want to use the multi-channel > > reception > > Yes; you just want to receive multiple channels. :) > > > can I use libraw1394? > > Yes. > > With the new firewire-core (Juju) modules, I am no longer limited by the system's pagesize, correct? I am expecting S800 8K packets and the page size of the x86_64 system is set to 4K. > > Regards, > Clemens > While I will not use it, I am curious about the multi-channel receive mode. Is it part of a specification? Is it basically creating a single contiguous buffer from the data from multiple channels? Best, Chris |
From: Clemens L. <cl...@la...> - 2012-03-29 19:20:48
|
Chris Wj wrote: > So it seems like in my case, I will not want to use the multi-channel > reception Yes; you just want to receive multiple channels. :) > can I use libraw1394? Yes. Regards, Clemens |
From: Chris Wj <chr...@gm...> - 2012-03-29 19:17:56
|
On Thu, Mar 29, 2012 at 2:36 PM, Clemens Ladisch <cl...@la...> wrote: > Chris Wj wrote: > > I am trying to figure out the best way to perform a multi-channel > > receive using the raw interface. > > Please note that the controller has a special mode to receive the > packets of multiple channels into one buffer, called multi-channel > reception. And the interface of the _old_ stack is called raw1394. > (The new stack's API doesn't have its own name; just call it Juju. :-) > > > Basically, I want to listen and read from 2 channels (0 and 1) and > > process their data separately. Can I set up 2 threads with 2 distinct > > handles to read from the same device but different channels? > > Yes. (The API does not require multiple threads.) > > > Regards, > Clemens > Clemens, thanks for the response. I very much appreciate it. So it seems like in my case, I will not want to use the multi-channel reception as I am expecting 2 distinct sets of data from the different channels even though it is from the same device, correct? If this is the case, can I use libraw1394? I noticed that the libraw1394 code does not implement multi-channel reception yet. This caused me to believe that I may not be able to use it for my use case. -Chris |
From: Clemens L. <cl...@la...> - 2012-03-29 18:36:38
|
Chris Wj wrote: > I am trying to figure out the best way to perform a multi-channel > receive using the raw interface. Please note that the controller has a special mode to receive the packets of multiple channels into one buffer, called multi-channel reception. And the interface of the _old_ stack is called raw1394. (The new stack's API doesn't have its own name; just call it Juju. :-) > Basically, I want to listen and read from 2 channels (0 and 1) and > process their data separately. Can I set up 2 threads with 2 distinct > handles to read from the same device but different channels? Yes. (The API does not require multiple threads.) Regards, Clemens |
From: Chris Wj <chr...@gm...> - 2012-03-29 16:52:01
|
Hey all. I am trying to figure out the best way to perform a multi-channel receive using the raw interface. The data is coming from a single device (custom, not common audio/video), but does not have to be joined together. The packet size is around 8K as well, so I have to use the new driver so I am not limited by the kernel pagesize. Basically, I want to listen and read from 2 channels (0 and 1) and process their data separately. Can I set up 2 threads with 2 distinct handles to read from the same device but different channels? I'm new to Firewire development so apologies if these are simple questions. Thanks much, Chris |
From: Stefan R. <st...@s5...> - 2012-03-20 18:51:02
|
On Mar 20 Stefan Richter wrote: > Loosely related to FireWire (but also USB, SATA, and other interconnects): > Just last week between 3.3-rc7 and 3.3 final, some fixes for kernel > crashes at hot unplug of storage devices were committed. E.g. an infamous > bug with card readers has been addressed. These fixes also went into kernel 3.2.12 and 3.0.25, released yesterday. -- Stefan Richter -=====-===-- --== =-=-- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-03-20 13:50:08
|
Hi all, Linux 3.3 has been released on Sunday. This time there were only two small changes to the FireWire drivers. firewire-ohci: - Add workaround for the 1394 part of Creative SoundBlaster Audigy in order to fix transaction failures. - Fix random malfunctions of Ricoh PCI Express 1394 controllers by disabling MSI (message signaled interrupts). These changes were also backmerged into kernel 3.2.6 and 3.0.21. In kernel 3.0.25, two forgotten older fixes from the 3.1 release were backmerged (fix for recognition of some old camcorders; 32 bit userspace on 64 bit kernel compatibility fix). Loosely related to FireWire (but also USB, SATA, and other interconnects): Just last week between 3.3-rc7 and 3.3 final, some fixes for kernel crashes at hot unplug of storage devices were committed. E.g. an infamous bug with card readers has been addressed. Nevertheless I suspect that the hunt for hot-unplug related bugs in and around the kernel's block layer is not yet over. Since there is so little to say about the FireWire kernel drivers, I use this post to also remind of some library updates: - libraw1394 v2.0.8 on 2012-02-19 with bug fixes and performance improvement, - libdc1394 v2.2.0 on 2012-03-06 with bug fixes on Linux and with new Windows platform support, - ongoing libffado fixes and improvements in the FFADO development repository, without formal release yet. -- Stefan Richter -=====-===-- --== =-=-- http://arcgraph.de/sr/ |
From: Peter C. <ch...@at...> - 2012-02-23 12:47:23
|
Many thanks! -- Pete ch...@at... On Wednesday 22 February 2012 19:11:36 Stefan Richter wrote: > On Feb 22 Peter Christy wrote: > > Can I leave it to you good folks to pursue? I'm quite happy to try out > > potential fixes to see if they work. > > Sure, I will come up with something when time permits and keep you Cc'ed in > case that tests with your disk are required or if upstream people ask for > more information or a different approach. |
From: Stefan R. <st...@s5...> - 2012-02-22 19:12:04
|
On Feb 22 Peter Christy wrote: > Can I leave it to you good folks to pursue? I'm quite happy to try out > potential fixes to see if they work. Sure, I will come up with something when time permits and keep you Cc'ed in case that tests with your disk are required or if upstream people ask for more information or a different approach. -- Stefan Richter -=====-===-- --=- =-==- http://arcgraph.de/sr/ |
From: Peter C. <ch...@at...> - 2012-02-22 18:38:41
|
OK, but as I intimated in my orignal post, I would not consider myself a programmer! I used to do 8-bit machine code and assembler as a hobby may years ago, and I can fumble my way around C to an extent, but that's about my limit. Knowing what to do here, or how to fix it is a bit over my head! Can I leave it to you good folks to pursue? I'm quite happy to try out potential fixes to see if they work. Cheers, -- Pete ch...@at... On Wednesday 22 February 2012 14:41:46 Stefan Richter wrote: > On Feb 22 Peter Christy wrote: > > On Monday 20 February 2012 22:54:15 you wrote: > > > as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then > > > power on + plug in the disk via FireWire. (Haven't tried this myself; > > > I hope udev keeps working despite being denied to run scsi_id.) > > > > Ha! Yes! When I did that, the drive was immediately recognised on > > switch-on, and a prompt appeared asking me if I wanted to mount it! > > > > I mounted it, and everything worked exactly as expected! > > > > Bingo! > > > > So, where do we go from here? > > I should put an HDD into my PL3507 based ODD bay and check whether its > firmware is afflicted in the same way. (It is evidently not affected when > running in MMC mode, but might be when running in RBC mode.) > > Then we should think about whether a fix should be implemented in scsi_id > or in /lib/udev/rules.d/60-persistent-storage.rules or in the kernel. > And then we should propose a fix at lin...@vg... and > lin...@vg... and see whether these folks like it. > > I tend to think that an udev rules¹ based fix is preferable. A scsi_id > based fix and more so a kernel based fix would be more general. But > issuing requests like Inquiry outside of the kernel and outside of stock > udev operations could be considered an "everyone is entitled to shoot > themselves in the foot" case. (Inquiry would be a perfectly safe request > in a world without firmware bugs.) > > ¹) http://reactivated.net/writing_udev_rules.html |
From: Stefan R. <st...@s5...> - 2012-02-22 14:42:09
|
On Feb 22 Peter Christy wrote: > On Monday 20 February 2012 22:54:15 you wrote: > > as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then > > power on + plug in the disk via FireWire. (Haven't tried this myself; I > > hope udev keeps working despite being denied to run scsi_id.) > > Ha! Yes! When I did that, the drive was immediately recognised on switch-on, > and a prompt appeared asking me if I wanted to mount it! > > I mounted it, and everything worked exactly as expected! > > Bingo! > > So, where do we go from here? I should put an HDD into my PL3507 based ODD bay and check whether its firmware is afflicted in the same way. (It is evidently not affected when running in MMC mode, but might be when running in RBC mode.) Then we should think about whether a fix should be implemented in scsi_id or in /lib/udev/rules.d/60-persistent-storage.rules or in the kernel. And then we should propose a fix at lin...@vg... and lin...@vg... and see whether these folks like it. I tend to think that an udev rules¹ based fix is preferable. A scsi_id based fix and more so a kernel based fix would be more general. But issuing requests like Inquiry outside of the kernel and outside of stock udev operations could be considered an "everyone is entitled to shoot themselves in the foot" case. (Inquiry would be a perfectly safe request in a world without firmware bugs.) ¹) http://reactivated.net/writing_udev_rules.html -- Stefan Richter -=====-===-- --=- =-==- http://arcgraph.de/sr/ |
From: Peter C. <ch...@at...> - 2012-02-22 09:43:58
|
On Monday 20 February 2012 22:54:15 you wrote: > On Feb 20 Clemens Ladisch wrote: > > Peter, as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then > power on + plug in the disk via FireWire. (Haven't tried this myself; I > hope udev keeps working despite being denied to run scsi_id.) Ha! Yes! When I did that, the drive was immediately recognised on switch-on, and a prompt appeared asking me if I wanted to mount it! I mounted it, and everything worked exactly as expected! Bingo! So, where do we go from here? Cheers, -- Pete ch...@at... |
From: Stefan R. <st...@s5...> - 2012-02-20 23:46:51
|
On Feb 20 Stefan Richter wrote: > Peter, as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then > power on + plug in the disk via FireWire. (Haven't tried this myself; I > hope udev keeps working despite being denied to run scsi_id.) > > But! According to the manual page of the scsi_id version which I have > here, scsi_id per default does not poke at devices which were not > whitelisted in /etc/scsi_id.config. So maybe the confusion comes from > somewhere else, I don't know. PS: Nope, /lib/udev/rules.d/60-persistent-storage.rules calls scsi_id with "--whitelisted" parameter, i.e. does indeed send an Inquiry request to each SCSI device, including FireWire attached ones. If this is the culprit, we probably should to turn to the udev folks to implement a more cautious handling of Prolific based FireWire devices. -- Stefan Richter -=====-===-- --=- =-=-= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-02-20 22:54:27
|
On Feb 20 Clemens Ladisch wrote: > Stefan Richter wrote: > > ... the FireWire firmware might return false size information, read from > > bogus offsets, or give whatever else false information. > > Peter Christy wrote: > | USB: > | ~$ xxd -g1 /dev/sdd | head -32 > | 0000000: fc 31 c0 8e d0 31 e4 8e d8 8e c0 be 00 7c bf 00 .1...1.......|.. > | 0000010: 06 b9 00 01 f3 a5 be ee 07 b0 08 ea 20 06 00 00 ............ ... > | 0000020: 80 3e b3 07 ff 75 04 88 16 b3 07 80 3c 00 74 04 .>...u......<.t. > | ... > | ~$ xxd -g1 /dev/sdd1 | head -32 > | 0000000: eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 .R.NTFS ..... > | 0000010: 00 00 00 00 00 f8 00 00 3f 00 ff 00 00 08 00 00 ........?....... > | 0000020: 00 00 00 00 80 00 80 00 ff 37 a1 12 00 00 00 00 .........7...... > | ... > | FireWire: > | ~$ xxd -g1 /dev/sdd | head -32 > | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S > | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack > | 0000020: 20 53 79 73 fc 31 c0 8e d0 31 e4 8e d8 8e c0 be Sys.1...1...... > | 0000030: 00 7c bf 00 06 b9 00 01 f3 a5 be ee 07 b0 08 ea .|.............. > | 0000040: 20 06 00 00 80 3e b3 07 ff 75 04 88 16 b3 07 80 ....>...u...... > | ... > | ~$ xxd -g1 /dev/sdd1 | head -32 > | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S > | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack > | 0000020: 20 53 79 73 eb 52 90 4e 54 46 53 20 20 20 20 00 Sys.R.NTFS . > | 0000030: 02 08 00 00 00 00 00 00 00 f8 00 00 3f 00 ff 00 ............?... > | 0000040: 00 08 00 00 00 00 00 00 80 00 80 00 ff 37 a1 12 .............7.. > | ... > > There's 36 bytes of garbage prepended to each sector, and the 36 bytes > from the end are missing. > > The system _did_ manage to find the correct first sector of the > partition, so it seems that this error did not occur when the kernel > first read the partition table. So maybe udev's scsi_id helper program asked for a Vital Product Data page, got it (or something else), and the firmware has a corrupted buffer pointer left over from that Inquiry. That's what PL3507 FireWire firmwares tend to do when faced with an Inquiry other than the very first one. Windows and presumably older Linux userspace might not have sent such an impertinent Inquiry. Peter, as a quick and dirty test, try "chmod a-x /lib/udev/scsi_id", then power on + plug in the disk via FireWire. (Haven't tried this myself; I hope udev keeps working despite being denied to run scsi_id.) But! According to the manual page of the scsi_id version which I have here, scsi_id per default does not poke at devices which were not whitelisted in /etc/scsi_id.config. So maybe the confusion comes from somewhere else, I don't know. -- Stefan Richter -=====-===-- --=- =-=-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-02-20 21:54:32
|
Stefan Richter wrote: > ... the FireWire firmware might return false size information, read from > bogus offsets, or give whatever else false information. Peter Christy wrote: | USB: | ~$ xxd -g1 /dev/sdd | head -32 | 0000000: fc 31 c0 8e d0 31 e4 8e d8 8e c0 be 00 7c bf 00 .1...1.......|.. | 0000010: 06 b9 00 01 f3 a5 be ee 07 b0 08 ea 20 06 00 00 ............ ... | 0000020: 80 3e b3 07 ff 75 04 88 16 b3 07 80 3c 00 74 04 .>...u......<.t. | ... | ~$ xxd -g1 /dev/sdd1 | head -32 | 0000000: eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 .R.NTFS ..... | 0000010: 00 00 00 00 00 f8 00 00 3f 00 ff 00 00 08 00 00 ........?....... | 0000020: 00 00 00 00 80 00 80 00 ff 37 a1 12 00 00 00 00 .........7...... | ... | FireWire: | ~$ xxd -g1 /dev/sdd | head -32 | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack | 0000020: 20 53 79 73 fc 31 c0 8e d0 31 e4 8e d8 8e c0 be Sys.1...1...... | 0000030: 00 7c bf 00 06 b9 00 01 f3 a5 be ee 07 b0 08 ea .|.............. | 0000040: 20 06 00 00 80 3e b3 07 ff 75 04 88 16 b3 07 80 ....>...u...... | ... | ~$ xxd -g1 /dev/sdd1 | head -32 | 0000000: 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b 20 53 tem formatRack S | 0000010: 79 73 74 65 6d 20 66 6f 72 6d 61 74 52 61 63 6b ystem formatRack | 0000020: 20 53 79 73 eb 52 90 4e 54 46 53 20 20 20 20 00 Sys.R.NTFS . | 0000030: 02 08 00 00 00 00 00 00 00 f8 00 00 3f 00 ff 00 ............?... | 0000040: 00 08 00 00 00 00 00 00 80 00 80 00 ff 37 a1 12 .............7.. | ... There's 36 bytes of garbage prepended to each sector, and the 36 bytes from the end are missing. The system _did_ manage to find the correct first sector of the partition, so it seems that this error did not occur when the kernel first read the partition table. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2012-02-20 19:22:05
|
On Feb 20 Clemens Ladisch wrote: > Peter Christy wrote: >> Under Windoze, the drive functions perfectly as either USB or FireWire (ie >> this is not a hardware fault!) It certainly isn't a hardware fault but a firmware fault. USB + FireWire disk enclosure have entirely different firmwares for the USB part and the FireWire part. Your disk enclosure contains a Prolific chip. Enclosures with this chip were regularly shipped with excessively buggy FireWire firmware (but proper USB firmware). >> Under Slackware, when connected as USB, the drive is immediately recognised, >> and a prompt appears on the desktop asking if I want to mount it. If I accept, >> it is mounted as /media/Video (the partition label). >> >> If I connect it as Firewire, although the kernel appears to recognise it (see >> demsg above), no prompt to mount it appears. Attempting to mount it manually >> creates an eror message saying it can't identify the filing system. Specifying >> ntfs-3g produces a "wrong super-block" error. > > Please show the output of these commands: > xxd -g1 /dev/sdd | head -32 > xxd -g1 /dev/sdd1 | head -32 > for both USB and FireWire. > >> sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB) > > Is this size exactly the same with USB and FireWire? Yep, the FireWire firmware might return false size information, read from bogus offsets, or give whatever else false information. [...] >> In other words, although the disk works fine under Windows, and under >> Linux as USB, it doesn't work under FireWire, as the system is unable to >> identify the partition, although it knows it exists! >> >> I haven't used this caddy for a while, but it used to work perfectly >> under the old FireWire stack. (I was unaware that there was a new stack >> until I started trying to debug this problem!) The change from ohci1394 + ieee1394 + sbp2 to firewire-ohci + firewire-core + firewire-sbp2 has very very little impact on the operation of FireWire storage devices. (The latter set of drivers is faster with 1394a and some mixed 1394b/1394a buses due to optimized bus arbitration gaps, anything else that concerns SBP-2 and its underpinnings hasn't changed much.) Much more impact have - changes in the kernel's SCSI and block layer drivers, - changes in the low-level userland, i.e. formerly HAL, now udev and their respective helper programs. The general trend, at least of the kernel side of the equation, is to more and more mimic the behaviour Windows, as far as details of Windows behavior become known. But this is only a general trend; there may well be occasional changes contrary to this. I can't say the same about low-level userland; this part of Linux might more rely on standards-compliant behavior of devices than the kernel itself does. Consumer-grade storage device firmwares do not really conform to any kind of standard; more commonly they are a heap of hacked-together stuff which just so happens to work with a somewhat current version of MS Windows with a narrow type of workload --- i.e. what the firmware coders did briefly test. Send an unexpected SCSI request to a Prolific FireWire firmware, and the firmware will hang (good, then it is at least immediately clear that the device got into trouble), or start mangling block addresses or data or whatever. >> I am not a programmer, though I would claim to be "computer literate". >> This may be an error on my part, but if so it is not obvious to me. >> Googling for solutions to this issue has produced a number of hits for >> Ubuntu users with the same problem, but no apparent solution! Do you have bookmarks of such discussions? It might be interesting to have a look at those. However, it is not uncommon that users identify as "the same problem" what in reality are quite different problems. This is to be expected, given how complex the whole hardware--firmware--OS-- application stack is nowadays. On a related note: I have a Prolific based enclosure myself, but with an optical drive in it instead of a HDD. For a time I also had a cheap Prolific based 2.5" HDD enclosure but its bridge board died a sudden and soon death. Is anybody aware of Prolific based devices still being sold anywhere? As IDE bridges, these chips are obsolete nowadays, but I have seen a case once where a FireWire-to-IDE bridge from another vendor was paired with an IDE-to-SATA bridge to make up a FireWire-to-SATA bridge board, presumably a few cents cheaper than with a native FireWire-to-SATA chip. Would be good to have a Prolific based HDD enclosure as a specimen for driver tests. My ODD enclosure works with HDDs too but it is inconvenient to swap the drives when needed. Plus, there seems to be quite a bit of variation between firmwares for the Prolific chip. -- Stefan Richter -=====-===-- --=- =-=-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-02-20 16:27:19
|
Peter Christy wrote: > Under Windoze, the drive functions perfectly as either USB or FireWire (ie > this is not a hardware fault!) > > Under Slackware, when connected as USB, the drive is immediately recognised, > and a prompt appears on the desktop asking if I want to mount it. If I accept, > it is mounted as /media/Video (the partition label). > > If I connect it as Firewire, although the kernel appears to recognise it (see > demsg above), no prompt to mount it appears. Attempting to mount it manually > creates an eror message saying it can't identify the filing system. Specifying > ntfs-3g produces a "wrong super-block" error. Please show the output of these commands: xxd -g1 /dev/sdd | head -32 xxd -g1 /dev/sdd1 | head -32 for both USB and FireWire. > sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB) Is this size exactly the same with USB and FireWire? Regards, Clemens |
From: Peter C. <ch...@at...> - 2012-02-20 16:11:31
|
System: Slackware64-13.37 Kernel: 3.2.2 Libraw1394 2.0.7 # lspci | grep FireWire 01:06.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 04) # lsmod | grep firewire firewire_sbp2 10977 0 firewire_ohci 26284 0 firewire_core 41461 2 firewire_sbp2,firewire_ohci crc_itu_t 1185 2 udf,firewire_core #dmesg firewire_core: created device fw1: GUID 0050770e00071002, S400, 3 config ROM retries firewire_core: phy config: card 0, new root=ffc0, gap_count=5 scsi5 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw1.0: 0x20 (firmware_revision 0x012804, model_id 0x000001) firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries) scsi 5:0:0:0: Direct-Access-RBC ST316002 2ACE PQ: 0 ANSI: 4 sd 5:0:0:0: Attached scsi generic sg4 type 14 sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB) sd 5:0:0:0: [sdd] Write Protect is off sd 5:0:0:0: [sdd] Mode Sense: 11 00 00 00 sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sd 5:0:0:0: [sdd] Attached SCSI disk The device is a hard drive caddy with both USB and FireWire ports, and contains an NTFS formatted drive. Under Windoze, the drive functions perfectly as either USB or FireWire (ie this is not a hardware fault!) Under Slackware, when connected as USB, the drive is immediately recognised, and a prompt appears on the desktop asking if I want to mount it. If I accept, it is mounted as /media/Video (the partition label). If I connect it as Firewire, although the kernel appears to recognise it (see demsg above), no prompt to mount it appears. Attempting to mount it manually creates an eror message saying it can't identify the filing system. Specifying ntfs-3g produces a "wrong super-block" error. Examining the disk with GParted indicates that the disk contains only "unallocated" space, when attached via FireWire! In other words, although the disk works fine under Windows, and under Linux as USB, it doesn't work under FireWire, as the system is unable to identify the partition, although it knows it exists! I haven't used this caddy for a while, but it used to work perfectly under the old FireWire stack. (I was unaware that there was a new stack until I started trying to debug this problem!) I am not a programmer, though I would claim to be "computer literate". This may be an error on my part, but if so it is not obvious to me. Googling for solutions to this issue has produced a number of hits for Ubuntu users with the same problem, but no apparent solution! Is anyone here able to offer advice or enlightenment, please? Cheers, -- Pete ch...@at... |
From: Stefan R. <st...@s5...> - 2012-02-19 15:15:08
|
Hi all, after needless delay, the next stable version 2.0.8 of libraw1394 (the Linux legacy programming interface to low-level IEEE 1394 I/O) is out there. The changes are: - Performance improvement: Configuration ROM access via raw1394_read() is dramatically faster and very robust now. We read the kernel's Configuration ROM cache instead of the actual register of the FireWire device. This should have been implemented already many years ago. - Interoperability fix: Internally retry raw1394_read/write/lock/lock64() after ack-busy response. Most notably this fixes control of some older Panasonic- based camcorders, e.g. Panasonic NV-DX110, Panasonic AG-EZ30, and Grundig Scenos DLC 2000. - Small bug fixes. Gitweb: https://git.kernel.org/?p=libs/ieee1394/libraw1394.git Git clone: git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git https://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git Tarball: https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.bz2 https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.gz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.xz https://www.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.sign ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.bz2 ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.gz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.xz ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libraw1394-2.0.8.tar.sign Due to kernel.org's upload mechanism, the gpg signature *.sign can only be used to verify the *.tar after unpacking one of the *.tar.{bz2,gz,xz}. Shortlog and diffstat since v2.0.8: Peter Hurley (2): Reset device fd upon error condition in handle_inotify() Process multiple inotify events Stefan Richter (5): redirect Config ROM reads into the kernel's ROM cache retry raw1394_read/write/lock/lock64 with delays after ack-busy Continue inotify event handling even after failure in one event Make a symbol static configure.ac, Changelog, NEWS etc.: update to version 2.0.8 ChangeLog | 24 ++++++++++ NEWS | 9 ++++ configure.ac | 2 +- src/fw.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++---- 4 files changed, 141 insertions(+), 10 deletions(-) -- Stefan Richter -=====-===-- --=- =--== http://arcgraph.de/sr/ |
From: Alexander N. <neu...@kd...> - 2012-01-14 17:04:29
|
On Tuesday 10 January 2012, Stefan Richter wrote: > On Jan 10 Clemens Ladisch wrote: > > Alexander Neundorf wrote: > > > I seem to have a strange problem with the irq_interval parameter of > > > raw1394_iso_recv_init(). > > > It seems to have an upper limit of 512. Is that possible ? > > > > No, this parameter itself does not have an upper limit. > > > > > If I set it to higher values than that, I still get the callback after > > > 512 packets have arrived. > > > > Actually, you get the callback after the correct number of packets. > > What you do not get is information about more than 512 of those packets. > > > > It would have been a good idea to document juju's 4 KB limit ... > > Clemens refers to an implementation limit deep down in the firewire-ohci > controller driver. There is a per-context temporary buffer used to > generate the "isochronous packets received" events. This buffer holds > isochronous packet header data and timestamps (usually 4 + 4 bytes per > packet) and is one page size big (usually 4 kBytes). Thanks for the quick reply, knowing that there is really this limit is basically good enough for me. Should I write a patch for libraw1394 which documents this ? Alex |