linux-kernel - Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <200612171404.56278.gene.heskett@verizon.net>
Date:	Sun, 17 Dec 2006 14:04:56 -0500
From:	Gene Heskett <gene.heskett@...izon.net>
To:	linux-kernel@...r.kernel.org
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Linus Torvalds <torvalds@...l.org>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/