Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Monday 18 December 2006 10:45, Stefan Richter wrote: >Gene Heskett wrote: >> On Sunday 17 December 2006 20:05, Stefan Richter wrote: >>>What's missing in our implementation is that the use count of ohci1394 >>>goes up too once a "high-level driver" uses resources of a host driven >>>by ohci1394. >> >> This needs some tlc then I assume? > >Yes. It's now logged at http://bugzilla.kernel.org/show_bug.cgi?id=7701 >and will probably stay there until I do something about it myself. Thanks, that pretty well describes what happened here. >>>The FireWire stack has three layers: Low level (ohci1394 and pcilynx; >>>control the host bus adapter), >> >> The hardware > >Yes, or more precisely the built-in hardware, not hardware at the other >end of the wire. That was assumed when I wrote it :) >>>mid level (the ieee1394 core) >> >> which I assume (fuggly word) steers the high level stuff to the right >> entry points in the hardware handler? > >Yes. It implements common management functionality and makes actions >like "write into a register of a remote node" or "receive a stream into >a buffer" independent of the actual host adapter --- or at least that >was the intent when Linux' FireWire stack was designed. Years ago there >was actually another driver for a non-OHCI host adapter chip from >Adaptec; and there is a mostly functional but unmaintained out-of-tree >driver for a non-OHCI/ non-PCI adapter from Texas Instruments (TI > GP2Lynx). > >IOW the ieee1394 core provides a platform to stick application-level >drivers (protocol drivers) like for DV, IPv4 networking, SBP-2 storage >on top of it without having to care of how particular host adapter chips >are programmed. raw1394 basically extends ieee1394 to stick userspace >drivers on it. > >But as mentioned, this layering is partly violated in the actual >implementation. Also, the ieee1394 core is itself needlessly dependent >on a PCI kernel API, making it harder for embedded developers to add >their own low-level drivers than it ought to be. (So I was told; I >actually rarely hear from embedded development projects.) Typical :-) Don't let me distract you from more important work :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
Gene Heskett wrote: > On Sunday 17 December 2006 20:05, Stefan Richter wrote: >>What's missing in our implementation is that the use count of ohci1394 >>goes up too once a "high-level driver" uses resources of a host driven >>by ohci1394. > > This needs some tlc then I assume? Yes. It's now logged at http://bugzilla.kernel.org/show_bug.cgi?id=7701 and will probably stay there until I do something about it myself. >>The FireWire stack has three layers: Low level (ohci1394 and pcilynx; >>control the host bus adapter), > The hardware Yes, or more precisely the built-in hardware, not hardware at the other end of the wire. >>mid level (the ieee1394 core) > which I assume (fuggly word) steers the high level stuff to the right > entry points in the hardware handler? Yes. It implements common management functionality and makes actions like "write into a register of a remote node" or "receive a stream into a buffer" independent of the actual host adapter --- or at least that was the intent when Linux' FireWire stack was designed. Years ago there was actually another driver for a non-OHCI host adapter chip from Adaptec; and there is a mostly functional but unmaintained out-of-tree driver for a non-OHCI/ non-PCI adapter from Texas Instruments (TI GP2Lynx). IOW the ieee1394 core provides a platform to stick application-level drivers (protocol drivers) like for DV, IPv4 networking, SBP-2 storage on top of it without having to care of how particular host adapter chips are programmed. raw1394 basically extends ieee1394 to stick userspace drivers on it. But as mentioned, this layering is partly violated in the actual implementation. Also, the ieee1394 core is itself needlessly dependent on a PCI kernel API, making it harder for embedded developers to add their own low-level drivers than it ought to be. (So I was told; I actually rarely hear from embedded development projects.) -- Stefan Richter -=-=-==- ==-- =--=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Sunday 17 December 2006 20:05, Stefan Richter wrote: >Gene Heskett wrote: >> The camera has been turned back off, but yes, it works absolutely >> normally now. With no dv1394 in memory! >> >> Then with the camera on and kino controlling it: >> [EMAIL PROTECTED] ~]# lsmod|grep 1394 >> raw139432264 4 >> ohci1394 39088 0 >> ieee1394 305624 2 raw1394,ohci1394 >> >> So we still don't appear to have any use of/for ohci1394. What the >> heck is it supposed to be doing? > >What's missing in our implementation is that the use count of ohci1394 >goes up too once a "high-level driver" uses resources of a host driven >by ohci1394. This needs some tlc then I assume? >The FireWire stack has three layers: Low level (ohci1394 and pcilynx; >control the host bus adapter), The hardware >mid level (the ieee1394 core) which I assume (fuggly word) steers the high level stuff to the right entry points in the hardware handler? >and high level (protocol drivers: dv1394, eth1394, sbp2, video1394; and the >multi-purpose bridge to userspace: raw1394). The mid level is supposed >to isolate high-level drivers from hardware-specific drivers. ieee1394.ko >However dv1394 and video1394 break this architecture. Parts of them >access ohci1394 directly. Opps. Bad dog, no bisquit. >And in practice, sbp2 indirectly breaks this >architecture too because it never got decent DMA mapping implemented, >and what it got in this department bitrotted to a degree that it is >currently not really usable with pcilynx. (AFAIK, I don't have a PCILynx >controller.) I did, but junked it when it couldn't be made to talk to this camera. It was an old card I'd bought years ago, came in a Maxtor box IIRC. I could probably dig it up (I'm an inveterate packrat) and see if I could find an empty pci slot, but them are precious items in most systems, and test it, or maybe even fwd it to someone capable of investigating it. If its worth the effort, I have NDI how many of them there are out there. I chose to throw money at the problem, it wasn't much, $30 USD IIRC at WallyWorld, blisterpacked with Belkins logo on it. >BTW, sbp2 had the same problem with missing use count of ohci1394 too >until Linux < 2.6.17. But it's a little bit harder to get right in > raw1394. Humm, architectural? I wouldn't know right from wrong as my C skills have rusted away over the last 15 years something awful. >> Now, do I need dv1394 to do the export if I were to want to re-write >> the edited video back to the tape in the camera? > >I suppose Kino is exporting DV via raw1394 nowadays too. Raw1394 >definitely has the means for it. That got my curiosity bump itching, so I loaded about the first 5 minutes of the last wedding into kino from disk, clipped off some junk video at the begining, and this does use raw1394 to export back to the camera. Previewed it spends some time preprocessing it, about 33 seconds I'd guess, and then it shows on the camera's viewfinder. So then I did the real export, and here it appears kino has a buglet that Dan should be advised of. It starts the tape rolling while its doing this preparatory stuff, so its recording dead tape (I don't think its outputting black, but no data at all) for about 33 seconds after the camera's own preroll delay of about 3 seconds to load the tape around the drum. Other than that, it works just fine using raw1394 to move it back to the camera and hence to the tape. But, the export function screen has 5 more ways to do it. Next tab to the right is DV file, with 4 methods available there, DV avi type 1 DV avi type 2 OpenDML avi raw DV, which I apparently have used. There is a 5th choice, quicktime, but its greyed out, presumably because I don't have that library installed. Next tab is Stills, with a jpeg quality slider Next tab is audio with resampling at 3 speeds and encoding with 5 choices Next tab is mpeg with a plethora of choices for output Last tab is Other, currently set for std VOB and FFMPEG but has 15 choices in file format, and 4 in the profile selector. All told, its a Swiss Army Knife that really needs better docs rather than doing something, burning it to dvd or svcd and seeing it it will play on the target friends machinery. You can make a lot of coasters that way. I just found an Emerson TV with a builtin dvd that had no idea what to do with an svcd all my stuff played just fine. This latter isn't a kernel problem of course. >Anyway, I'm glad it sort of works for you now. Yes, rather nicely except for the exports start recording dead time, a kino problem obviously. Anyway, I'm a happy camper till the next time, but if by the time Dan does kino-1.0, that particular buglet isn't fixed, I'll still be happy as its otherwise a heck of a program. It fills a niche gap that none of the other video processing programs even try to do. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
Gene Heskett wrote: > The camera has been turned back off, but yes, it works absolutely normally > now. With no dv1394 in memory! > > Then with the camera on and kino controlling it: > [EMAIL PROTECTED] ~]# lsmod|grep 1394 > raw139432264 4 > ohci1394 39088 0 > ieee1394 305624 2 raw1394,ohci1394 > > So we still don't appear to have any use of/for ohci1394. What the heck > is it supposed to be doing? What's missing in our implementation is that the use count of ohci1394 goes up too once a "high-level driver" uses resources of a host driven by ohci1394. The FireWire stack has three layers: Low level (ohci1394 and pcilynx; control the host bus adapter), mid level (the ieee1394 core) and high level (protocol drivers: dv1394, eth1394, sbp2, video1394; and the multi-purpose bridge to userspace: raw1394). The mid level is supposed to isolate high-level drivers from hardware-specific drivers. However dv1394 and video1394 break this architecture. Parts of them access ohci1394 directly. And in practice, sbp2 indirectly breaks this architecture too because it never got decent DMA mapping implemented, and what it got in this department bitrotted to a degree that it is currently not really usable with pcilynx. (AFAIK, I don't have a PCILynx controller.) BTW, sbp2 had the same problem with missing use count of ohci1394 too until Linux < 2.6.17. But it's a little bit harder to get right in raw1394. > Now, do I need dv1394 to do the export if I were to want to re-write the > edited video back to the tape in the camera? I suppose Kino is exporting DV via raw1394 nowadays too. Raw1394 definitely has the means for it. Anyway, I'm glad it sort of works for you now. -- Stefan Richter -=-=-==- ==-- =--=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Sunday 17 December 2006 15:21, Stefan Richter wrote: [...] >What if you prevent dv1394 from ever being loaded, or don't build it in >the first place? CONFIG_IEEE1394_DV1394=n How about '# CONFIG_IEEE1394_DV1394 is not set'? Hand edited the .config and fired off my makeit script, which does it all & rebooted. [EMAIL PROTECTED] ~]# lsmod|grep 1394 raw139432264 0 ohci1394 39088 0 ieee1394 305624 2 raw1394,ohci1394 The camera has been turned back off, but yes, it works absolutely normally now. With no dv1394 in memory! Then with the camera on and kino controlling it: [EMAIL PROTECTED] ~]# lsmod|grep 1394 raw139432264 4 ohci1394 39088 0 ieee1394 305624 2 raw1394,ohci1394 So we still don't appear to have any use of/for ohci1394. What the heck is it supposed to be doing? Now, do I need dv1394 to do the export if I were to want to re-write the edited video back to the tape in the camera? This is something I believe I'm supposed to be able to do, but never have yet as I consider the tape a capture only medium due to incompatibilities with the vcr Joe Sixpack has. Just about everyone has a dvd player these days, so that is what I export to. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
(Cc linux1394-devel, for the record) Gene Heskett wrote: > On Sunday 17 December 2006 13:31, Stefan Richter wrote: >> Is your version of kino still using dv1394 or does it work without >> dv1394 loaded too? >> > AFAIK, its kino is 0.9.3. Ok, while kino is running I did a modprobe -rv > dc1394 and it removed dv1394.ko and ohci1394.ko When dv1394 is loaded, the use count of ohci1394 is incremented because dv1394 uses symbols of ohci1394. Likewise, when dv1394 is removed, ohci1394's use count is decremented which may render ohci1394 "unused". It will then be removed too. This is of course not desired in many cases. > Now when going to the capture screen is says the device /dev/raw1394 is > gone or the kernel module isn't loaded. raw1394 is still resident > according to an lsmod, so I'm puzzled as to why the device was removed > when the module is still present. raw1394 does not mark FireWire hosts as in use. I think we should add try_module_get(host->driver->owner) and module_put(host->driver->owner) either to initiation and release of requests, or to the raw1394_open() and raw1394_release() hooks for all hosts which are present when the file is opened, or simply to raw1394's add_host() and remove_host() hooks. I'll make a note on bugzilla.kernel.org and try to find a proper fix some time. > So I modprobe -rv raw1394 and it took > out raw1394 and ieee1394, then reloaded raw1394 which loaded ieee1394. > And kino is still without controls but does not now report the error at > the bottom of its screen. Quitting it and restarting it restores the > error. Then loading dv1394 also brings in ohci1394, and a recycle out and > back to the capture window restored the controls. > > So I removed dv1394, and reloaded only ohci1384, That's what was necessary after you removed dv1394. > but an attempt to change > screens in kino locked the box up tight, not even the x-clock in the > right corner was running and I had to hard reset it. This is, how should I put it, not good. Maybe raw1394 still held resources on behalf of kino which related to the host that first vanished, then reappeared as a new one. Anyway; raw1394 is supposed to handle life addition and removal of hosts, but we obviously missed something. > With 4 modules to play with and 4!=15, its the lack of the dv1394 module > that isn't exactly friendly, the other combo's just kill the controls. > > AIUI, it *should* be ohci1394 handling the controls stuff, so this > represents a bit of a puzzle. Or the AIUI is wrong :) ... What if you prevent dv1394 from ever being loaded, or don't build it in the first place? CONFIG_IEEE1394_DV1394=n -- Stefan Richter -=-=-==- ==-- =---= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Sunday 17 December 2006 13:31, Stefan Richter wrote: >Gene Heskett wrote: >... > >> while I didn't try >> to capture a 2 hour movie, I did use kino to control the camera >> playback, rewind etc stuff for about 10 minutes and had no problems >> whatsoever. > >... > >> The only entry in the messages log for all this was: >> >> Dec 17 12:47:13 coyote kernel: WARNING: The dv1394 driver is >> unsupported and will be removed from Linux soon. Use raw1394 instead. > >Is your version of kino still using dv1394 or does it work without >dv1394 loaded too? > AFAIK, its kino is 0.9.3. Ok, while kino is running I did a modprobe -rv dc1394 and it removed dv1394.ko and ohci1394.ko Now when going to the capture screen is says the device /dev/raw1394 is gone or the kernel module isn't loaded. raw1394 is still resident according to an lsmod, so I'm puzzled as to why the device was removed when the module is still present. So I modprobe -rv raw1394 and it took out raw1394 and ieee1394, then reloaded raw1394 which loaded ieee1394. And kino is still without controls but does not now report the error at the bottom of its screen. Quitting it and restarting it restores the error. Then loading dv1394 also brings in ohci1394, and a recycle out and back to the capture window restored the controls. So I removed dv1394, and reloaded only ohci1384, but an attempt to change screens in kino locked the box up tight, not even the x-clock in the right corner was running and I had to hard reset it. With 4 modules to play with and 4!=15, its the lack of the dv1394 module that isn't exactly friendly, the other combo's just kill the controls. AIUI, it *should* be ohci1394 handling the controls stuff, so this represents a bit of a puzzle. Or the AIUI is wrong :) >> Dec 17 12:47:13 coyote kernel: ieee1394: raw1394: /dev/raw1394 device >> initialized >> >> So whatever was done to the ieee1394 stuffs between 2.6.19 and >> 2.6.20-rc1 was a definite, and much appreciated improvement, > >... > >>From what went into linux/drivers/ieee1394 after 2.6.19 was released, >I'm puzzled how this happened. :-) Me too, but the whole combination does work. Remove only dv1394=locked up machine & hardware reset. I hope this is helpfull to the next step in your quest to get rid of dv1394. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
Gene Heskett wrote: ... > while I didn't try > to capture a 2 hour movie, I did use kino to control the camera playback, > rewind etc stuff for about 10 minutes and had no problems whatsoever. ... > The only entry in the messages log for all this was: > > Dec 17 12:47:13 coyote kernel: WARNING: The dv1394 driver is unsupported > and will be removed from Linux soon. Use raw1394 instead. Is your version of kino still using dv1394 or does it work without dv1394 loaded too? > Dec 17 12:47:13 coyote kernel: ieee1394: raw1394: /dev/raw1394 device > initialized > > So whatever was done to the ieee1394 stuffs between 2.6.19 and 2.6.20-rc1 > was a definite, and much appreciated improvement, ... >From what went into linux/drivers/ieee1394 after 2.6.19 was released, I'm puzzled how this happened. :-) -- Stefan Richter -=-=-==- ==-- =---= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Thursday 14 December 2006 22:17, Gene Heskett wrote: >On Thursday 14 December 2006 12:48, Stefan Richter wrote: >[...] > >>(Anyway, that's unrelated to Gene's issues.) > >And which I haven't had a chance to check yet, the camera is still in > the truck and I've been busier than a one legged man in an ass kicking > contest today. I did get 2.6.20-rc1 built and its whats running, but > that is as far as I got, too many other honeydo's. Tomorrow hopefully. > If I don't wind up using a backhoe for a divining rod, looking for our > sewer which is beginning to nag us occasionally. Stefan, I did get a chance to try it out just now, and while I didn't try to capture a 2 hour movie, I did use kino to control the camera playback, rewind etc stuff for about 10 minutes and had no problems whatsoever. Kino I believe, can only step forward and backwards one frame at a time in its edit window as nothing happened when I tried those direct to the camera while it was paused. I even went back and played spastic monkey on the controls, but was unable to trigger a segfault exit or any other kind of an error. The only entry in the messages log for all this was: Dec 17 12:47:13 coyote kernel: WARNING: The dv1394 driver is unsupported and will be removed from Linux soon. Use raw1394 instead. Dec 17 12:47:13 coyote kernel: ieee1394: raw1394: /dev/raw1394 device initialized So whatever was done to the ieee1394 stuffs between 2.6.19 and 2.6.20-rc1 was a definite, and much appreciated improvement, many thanks to all concerned, I probably owe somebody a pint (or more). -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
On Thursday 14 December 2006 12:48, Stefan Richter wrote: [...] > >(Anyway, that's unrelated to Gene's issues.) And which I haven't had a chance to check yet, the camera is still in the truck and I've been busier than a one legged man in an ass kicking contest today. I did get 2.6.20-rc1 built and its whats running, but that is as far as I got, too many other honeydo's. Tomorrow hopefully. If I don't wind up using a backhoe for a divining rod, looking for our sewer which is beginning to nag us occasionally. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
Gene Heskett wrote:
> On Wednesday 13 December 2006 22:32, Linus Torvalds wrote:
>>On Wed, 13 Dec 2006, Gene Heskett wrote:
>>> Ok, one not so silly Q (IMO) from the resident old fart. I saw,
>>> sometime in the past week, a relatively huge ieee1394 update go by.
>>> And I have some issues with the present 2.6.19 version causeing
>>> segfaults and kino go-aways when trying to capture from my firewire
>>> movie camera. Problems occur when trying to control the camera from
>>> kino.
>>>
>>> Is this patchset in this -rc1? If it is, I'll see if I can get a
>>> build to work and check it out.
This time everything which was in linux1394-2.6.git before the post
2.6.19 merge window went into 2.6.20-rc1. However it wasn't much
substantial stuff; we didn't get much done during the past few months.
Here is my pull message: http://lkml.org/lkml/2006/12/07/323
You can patch the ieee1394 drivers in 2.6.{19,18,16.x} to nearly the
same level as in 2.6.20-rc1 (that is, minus changesets which only
address in-kernel API changes) by means of the patchkit v212 from
http://me.in-berlin.de/~s5r6/linux1394/merged/. However I'm 99.9% sure
that it won't fix the problems you got.
>>-rc1 does include a reasonably big firewire update, but I'm not sure how
>>it will affect your camera usage. In fact, the ieee1394 people seem to
>> be trying to deprecate the dv1394 stuff, in favour of just raw1394 and
>> user-mode libraries.
That's right.
>>I think you can tell Kino to use either the DV or the raw interface, but
>>I'm not sure. If you can, try either. The raw interface seems to be
>>horribly misdesigned (security problems), but is the one to use.
These security issues are partly inherent to the IEEE 1394 architecture,
if I may say so. Dan Dennedy has a patch as work in progress to improve
raw1394's security towards devices as far as possible (while still
allowing non-root users access to /dev/raw1394, unless the administrator
thinks otherwise).
The other issue is security of the local host against attacks from
malicious external devices or other PCs. Here the issue is with
OHCI-1394's physical DMA feature and the fact that the sbp2 driver needs
it enabled. I'm planning to implement filtered physical DMA as a simple
security improvement and, at some day in a /distant/ future, implement a
DMA mapping in sbp2 to work completely without physical DMA.
(Anyway, that's unrelated to Gene's issues.)
--
Stefan Richter
-=-=-==- ==-- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
