linux1394-user Mailing List for IEEE 1394 for Linux (Page 416)
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: Mark K. <mk...@co...> - 2001-02-26 23:05:48
|
Hi all, Being a fairly 'standards conscious' member here who unfortunately can't program device drivers if my life depended on it, if someone wants to help Gord out and push this code forward, and you find you could use any help from me, please know you'll get immediate responses. Mark -----Original Message----- From: Gord Peters [mailto:Gor...@sm...] Sent: Monday, February 26, 2001 2:28 PM To: Felix Tang; lin...@li...; lin...@li... Subject: Important IEEE 1394 driver problem (was RE: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). (fwd)) One of the more standards conscious memebers of this list has expressed concern about my telling people to do things this way in order to solve their problems. Just to note here, forcing the host controller to become the root node is _NOT_ standards compliant behavior and could cause major problems for anyone who is connecting more than one PC to the IEEE 1394 bus (since the computers will fight it out to become the root node forever). This behavior is something which has long plaugued the Linux IEEE 1394 driver, and although not immediately visible to everyone who uses it, is something which should be addressed ASAP. The way to address it is to implement bus management functionality in the driver so that it checks the capabilities of the root node in order to determine if the host controller should force itself (or another node) to become the root node. I have written a skeleton for bus management which optimizes the gap count, and will set the host controller to become the root node, but doesn't check the capabilities of all the nodes on the bus when it does this (which is not standards compliant). Unfortunately, I don't have time to complete this work right now, but if anyone has some spare time and/or is looking to do some work on the IEEE 1394 driver, I would recommend that they work on this problem since it is long overdue. If you are interested, my bus management patch can be found at http://che.eyep.net/ieee1394/ (the patch is a bit old, so it may need to be merged into the latest driver by hand). I'd be happy to answer any questions with regard to bus management and what it entails. ----- Gord Peters Software Developer Gor...@sm... SMART Technologies Inc. http://www.smarttech.com/ > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of Gord > Peters > Sent: Monday, February 26, 2001 4:06 PM > To: Felix Tang; lin...@li...; > lin...@li... > Subject: RE: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). > (fwd) > > > Make sure your host controller card is the root node. If not, isochronous > transmissions will not work properly (and will likely exhibit the behavior > you are seeing). You should see something like this in your > kernel messages > after the driver is installed: > > > ieee1394: detected 1 ohci1394 adapter > ohci1394_0: Got phy packet ctx=0 ... discarded > ohci1394_0: SelfID process finished (phyid 1, root) > > ^^^^ > If it says "not root" instead of "root", then you'll need to set the > attempt_root flag in the OHCI module to 1. > > There are two ways to do this: > > 1) If you are running the IEEE 1394 driver as kernel modules, when you > install the OHCI module, add "attempt_root=1" to the end of the > command (ie. > "insmod ohci1394.o attempt_root=1) > > 2) If you are running the IEEE 1394 driver within the kernel, > then look for > the following line in ohci1394.c: > > static int attempt_root = 0; > > and change it to: > > static int attempt_root = 1; > > then recompile and reinstall your kernel. > > Not a very nice solution, but it works. Let me know if that fixes your > problem. > > ----- > Gord Peters > Software Developer Gor...@sm... > SMART Technologies Inc. http://www.smarttech.com/ > > > > -----Original Message----- > > From: lin...@li... > > [mailto:lin...@li...]On Behalf Of Felix > > Tang > > Sent: Monday, February 26, 2001 3:23 PM > > To: lin...@li...; > > lin...@li... > > Subject: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). > > (fwd) > > > > > > In a letter originally to Chris Curmson... > > > > I have an ads pyro webcam which is purported to be dc2.0 compliant. So, > > coriander and samplegrab seems to be able to get information about the > > camera... it can get the feature set, start an iso transmission and then > > stalls at the dc1394_single_capture. Just curious if you have any ideas. > > > > Also, for libdc... dc1394_setup_camera doesn't exist anymore... > it may be > > renamed to dc1394_setup_capture. But it's called setup_camera in the > > comments. Confusing. ;) > > > > Thanks, > > > > Felix > > > > p.s. > > > > Oh... I've isolated it to... > > > > /* now we iterate till the data is here*/ > > while (_dc1394_all_captured!=0) > > { > > raw1394_loop_iterate(handle); > > } > > > > in dc1394_capture.c in dc1394_multi_capture (i.e. line 290). > > > > Felix > > > > > > > > > > _______________________________________________ > > mailing list lin...@li... > > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > > > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/lists/listinfo/linux1394-devel |
From: Felix T. <ta...@ee...> - 2001-02-26 23:02:28
|
All, I'm looking for the sample app by Dan Dennedy that was posted on Nov 11 2000. I've checked the archives but it doesn't contain the source. Thanks, Felix |
From: Gord P. <Gor...@sm...> - 2001-02-26 22:27:30
|
One of the more standards conscious memebers of this list has expressed concern about my telling people to do things this way in order to solve their problems. Just to note here, forcing the host controller to become the root node is _NOT_ standards compliant behavior and could cause major problems for anyone who is connecting more than one PC to the IEEE 1394 bus (since the computers will fight it out to become the root node forever). This behavior is something which has long plaugued the Linux IEEE 1394 driver, and although not immediately visible to everyone who uses it, is something which should be addressed ASAP. The way to address it is to implement bus management functionality in the driver so that it checks the capabilities of the root node in order to determine if the host controller should force itself (or another node) to become the root node. I have written a skeleton for bus management which optimizes the gap count, and will set the host controller to become the root node, but doesn't check the capabilities of all the nodes on the bus when it does this (which is not standards compliant). Unfortunately, I don't have time to complete this work right now, but if anyone has some spare time and/or is looking to do some work on the IEEE 1394 driver, I would recommend that they work on this problem since it is long overdue. If you are interested, my bus management patch can be found at http://che.eyep.net/ieee1394/ (the patch is a bit old, so it may need to be merged into the latest driver by hand). I'd be happy to answer any questions with regard to bus management and what it entails. ----- Gord Peters Software Developer Gor...@sm... SMART Technologies Inc. http://www.smarttech.com/ > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of Gord > Peters > Sent: Monday, February 26, 2001 4:06 PM > To: Felix Tang; lin...@li...; > lin...@li... > Subject: RE: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). > (fwd) > > > Make sure your host controller card is the root node. If not, isochronous > transmissions will not work properly (and will likely exhibit the behavior > you are seeing). You should see something like this in your > kernel messages > after the driver is installed: > > > ieee1394: detected 1 ohci1394 adapter > ohci1394_0: Got phy packet ctx=0 ... discarded > ohci1394_0: SelfID process finished (phyid 1, root) > > ^^^^ > If it says "not root" instead of "root", then you'll need to set the > attempt_root flag in the OHCI module to 1. > > There are two ways to do this: > > 1) If you are running the IEEE 1394 driver as kernel modules, when you > install the OHCI module, add "attempt_root=1" to the end of the > command (ie. > "insmod ohci1394.o attempt_root=1) > > 2) If you are running the IEEE 1394 driver within the kernel, > then look for > the following line in ohci1394.c: > > static int attempt_root = 0; > > and change it to: > > static int attempt_root = 1; > > then recompile and reinstall your kernel. > > Not a very nice solution, but it works. Let me know if that fixes your > problem. > > ----- > Gord Peters > Software Developer Gor...@sm... > SMART Technologies Inc. http://www.smarttech.com/ > > > > -----Original Message----- > > From: lin...@li... > > [mailto:lin...@li...]On Behalf Of Felix > > Tang > > Sent: Monday, February 26, 2001 3:23 PM > > To: lin...@li...; > > lin...@li... > > Subject: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). > > (fwd) > > > > > > In a letter originally to Chris Curmson... > > > > I have an ads pyro webcam which is purported to be dc2.0 compliant. So, > > coriander and samplegrab seems to be able to get information about the > > camera... it can get the feature set, start an iso transmission and then > > stalls at the dc1394_single_capture. Just curious if you have any ideas. > > > > Also, for libdc... dc1394_setup_camera doesn't exist anymore... > it may be > > renamed to dc1394_setup_capture. But it's called setup_camera in the > > comments. Confusing. ;) > > > > Thanks, > > > > Felix > > > > p.s. > > > > Oh... I've isolated it to... > > > > /* now we iterate till the data is here*/ > > while (_dc1394_all_captured!=0) > > { > > raw1394_loop_iterate(handle); > > } > > > > in dc1394_capture.c in dc1394_multi_capture (i.e. line 290). > > > > Felix > > > > > > > > > > _______________________________________________ > > mailing list lin...@li... > > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > > > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > |
From: Gord P. <Gor...@sm...> - 2001-02-26 21:05:40
|
Make sure your host controller card is the root node. If not, isochronous transmissions will not work properly (and will likely exhibit the behavior you are seeing). You should see something like this in your kernel messages after the driver is installed: ieee1394: detected 1 ohci1394 adapter ohci1394_0: Got phy packet ctx=0 ... discarded ohci1394_0: SelfID process finished (phyid 1, root) ^^^^ If it says "not root" instead of "root", then you'll need to set the attempt_root flag in the OHCI module to 1. There are two ways to do this: 1) If you are running the IEEE 1394 driver as kernel modules, when you install the OHCI module, add "attempt_root=1" to the end of the command (ie. "insmod ohci1394.o attempt_root=1) 2) If you are running the IEEE 1394 driver within the kernel, then look for the following line in ohci1394.c: static int attempt_root = 0; and change it to: static int attempt_root = 1; then recompile and reinstall your kernel. Not a very nice solution, but it works. Let me know if that fixes your problem. ----- Gord Peters Software Developer Gor...@sm... SMART Technologies Inc. http://www.smarttech.com/ > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of Felix > Tang > Sent: Monday, February 26, 2001 3:23 PM > To: lin...@li...; > lin...@li... > Subject: about the samplegrab program for ieee1394 (dc1.2 vs dc2.0). > (fwd) > > > In a letter originally to Chris Curmson... > > I have an ads pyro webcam which is purported to be dc2.0 compliant. So, > coriander and samplegrab seems to be able to get information about the > camera... it can get the feature set, start an iso transmission and then > stalls at the dc1394_single_capture. Just curious if you have any ideas. > > Also, for libdc... dc1394_setup_camera doesn't exist anymore... it may be > renamed to dc1394_setup_capture. But it's called setup_camera in the > comments. Confusing. ;) > > Thanks, > > Felix > > p.s. > > Oh... I've isolated it to... > > /* now we iterate till the data is here*/ > while (_dc1394_all_captured!=0) > { > raw1394_loop_iterate(handle); > } > > in dc1394_capture.c in dc1394_multi_capture (i.e. line 290). > > Felix > > > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > |
From: Felix T. <ta...@ee...> - 2001-02-26 20:22:33
|
In a letter originally to Chris Curmson... I have an ads pyro webcam which is purported to be dc2.0 compliant. So, coriander and samplegrab seems to be able to get information about the camera... it can get the feature set, start an iso transmission and then stalls at the dc1394_single_capture. Just curious if you have any ideas. Also, for libdc... dc1394_setup_camera doesn't exist anymore... it may be renamed to dc1394_setup_capture. But it's called setup_camera in the comments. Confusing. ;) Thanks, Felix p.s. Oh... I've isolated it to... /* now we iterate till the data is here*/ while (_dc1394_all_captured!=0) { raw1394_loop_iterate(handle); } in dc1394_capture.c in dc1394_multi_capture (i.e. line 290). Felix |
From: Robert S. <r.s...@ze...> - 2001-02-26 08:05:14
|
Hello Kurt, = H=E4usler Kurt wrote: > Are you sure, that the FireBoard400 is an OHCI board? We have the same > and ours is a PciLynx, although I know that there is also an OHCI > version around. > = > If it's PciLynx one, than simply loading the right module will do. Nope, it really seems to be a OHCI board (I have to look at what's the exact name of the card is). But it works now (access rights to /dev/raw1394 have been incorrect). = Thank you, anyway! Robert -- = _ / \ _ Dipl.-Ing. Robert Schwebel r.s...@ze... --/ \ / \/-------------------------------------------------------- \_/ ZEUTEC Opto-Elektronik GmbH www.zeutec.de Kieler Str. 211, 24786 Rendsburg, Germany Phone: +49-4331-136-653 Fax: +49-4331-136-651 +++ Neue Adresse! +++ New Address! +++ Neue Adresse! +++ New Address! ++++ |
From: Robert S. <r.s...@ze...> - 2001-02-26 08:05:14
|
Dan Dennedy wrote: > Did you install libraw1394 and make dev? Yes, I did: photon:/lib/modules/2.2.18/ieee1394 # ls -l /dev/raw1394 crw------- 1 root root 171, 0 Feb 23 10:41 /dev/raw1394 Oops, thank you very much for the hint! :-) The access rights have been the problem. It works now, yippee!!! :-) Robert -- _ / \ _ Dipl.-Ing. Robert Schwebel r.s...@ze... --/ \ / \/-------------------------------------------------------- \_/ ZEUTEC Opto-Elektronik GmbH www.zeutec.de Kieler Str. 211, 24786 Rendsburg, Germany Phone: +49-4331-136-653 Fax: +49-4331-136-651 +++ Neue Adresse! +++ New Address! +++ Neue Adresse! +++ New Address! ++++ |
From: Guido F. <gfiala@s.netic.de> - 2001-02-24 13:13:00
|
Has someone managed to compile and run the network adapter ip1394 or eth1394 with a 2.4 series kernel, and if so how? |
From: George S. <ru...@cm...> - 2001-02-23 20:15:16
|
Hello, I'm currently using a framegrabber (BT848) with a webcam for a computer vision project of mine. I'm looking to get a firewire card and a camera for my machine in order to increase the frame rate. Could anyone please recommend a setup that would work under Linux guaranteed? Thanks a lot! -george |
From: Dan D. <dde...@co...> - 2001-02-23 20:03:09
|
Did you install libraw1394 and make dev? From: "Robert Schwebel" <r.s...@ze...> > Hi! > > I'm doing my first steps with the following configuration: > > - FireBoard400 > - Sony DFW-X700 or XCD-X700 > > After patching the kernel and insmod'ding the drivers, how can I see an > image? I've tried the samplegrab example which was suggested on this > list some time ago, but it claims not to find the drivers: > |
From: <Kur...@pr...> - 2001-02-23 19:23:00
|
Hi Robert, > I'm doing my first steps with the following configuration: > > - FireBoard400 > - Sony DFW-X700 or XCD-X700 Are you sure, that the FireBoard400 is an OHCI board? We have the same and ours is a PciLynx, although I know that there is also an OHCI version around. If it's PciLynx one, than simply loading the right module will do. Kurt |
From: Dave C. <dc...@io...> - 2001-02-23 16:55:41
|
Dave Chavez wrote: > > Brion Vibber wrote: > > > > On Thu, 22 Feb 2001, Dave Chavez wrote: > > > > > I'm not sure if the current drivers/modules are supported under > > > the Linux 2.4.1 kernel. I have 2.4.1 with the patched version of > > > the ieee1394 drivers built into the kernel (ie, not modules). > > > The sbp2_1394 is compiled/loaded as a module. I have a Maxtor 80GB > > > drive attached to my machine (laptop), and I get I/O errors when I > > > sync the disk. > > > > It appears I am not alone after all... In case my earlier message was > > eaten alive by the list (I don't see it in the archives), I'm having > > errors on large writes (and sometimes reads) on my 40GB Maxtor under 2.4.1 > > + cvs'd 1394. Same with 2.4.2. Downgrading to 2.4.0 + cvs'd 1394 appears > > to solve the problem, so it's definately a conflict with something else in > > the kernel, don't know what. > > > > My errors look like this: > > > > ieee1394: sbp2: SBP2_SCSI_STATUS_CHECK_CONDITION > > [valid=0] Info fld=0x73600b0, Current bh08:01: sense key Illegal Request > > Additional sense indicates Invalid field in cdb > > SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000002 > > [valid=0] Info fld=0x73600b0, Current sd08:01: sense key Illegal Request > > Additional sense indicates Invalid field in cdb > > I/O error: dev 08:01, sector 10826816 > > > > Are these what you're getting? (I have a desktop system, using Maxtor's > > cheapie OHCI PCI card for the 1394 interface.) > > Yep. I'm using the laptop's internal ieee1394 port, which is > an OHCI Texas Instruments PCI1225 (accoring to /proc/interrupts). > I've built 2.4.2 and plan to test it today. If I have success, > I'll let you know. I was "slightly" more successful with 2.4.2, but still ran into problems. Eventually, I got an EXT2-fs related kernel panic. I think I might have to rollback to 2.4.0. (Note: I only moved up from 2.4.0 because I could only get VMWare to compile it's modules under 2.4.1 and not 2.4.0. Maybe I'll revisit this later.). Dave |
From: Dave C. <dc...@io...> - 2001-02-23 16:06:10
|
Brion Vibber wrote: > > On Thu, 22 Feb 2001, Dave Chavez wrote: > > > I'm not sure if the current drivers/modules are supported under > > the Linux 2.4.1 kernel. I have 2.4.1 with the patched version of > > the ieee1394 drivers built into the kernel (ie, not modules). > > The sbp2_1394 is compiled/loaded as a module. I have a Maxtor 80GB > > drive attached to my machine (laptop), and I get I/O errors when I > > sync the disk. > > It appears I am not alone after all... In case my earlier message was > eaten alive by the list (I don't see it in the archives), I'm having > errors on large writes (and sometimes reads) on my 40GB Maxtor under 2.4.1 > + cvs'd 1394. Same with 2.4.2. Downgrading to 2.4.0 + cvs'd 1394 appears > to solve the problem, so it's definately a conflict with something else in > the kernel, don't know what. > > My errors look like this: > > ieee1394: sbp2: SBP2_SCSI_STATUS_CHECK_CONDITION > [valid=0] Info fld=0x73600b0, Current bh08:01: sense key Illegal Request > Additional sense indicates Invalid field in cdb > SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000002 > [valid=0] Info fld=0x73600b0, Current sd08:01: sense key Illegal Request > Additional sense indicates Invalid field in cdb > I/O error: dev 08:01, sector 10826816 > > Are these what you're getting? (I have a desktop system, using Maxtor's > cheapie OHCI PCI card for the 1394 interface.) Yep. I'm using the laptop's internal ieee1394 port, which is an OHCI Texas Instruments PCI1225 (accoring to /proc/interrupts). I've built 2.4.2 and plan to test it today. If I have success, I'll let you know. Dave |
From: Robert S. <r.s...@ze...> - 2001-02-23 12:04:41
|
Hi! I'm doing my first steps with the following configuration: - FireBoard400 - Sony DFW-X700 or XCD-X700 After patching the kernel and insmod'ding the drivers, how can I see an image? I've tried the samplegrab example which was suggested on this list some time ago, but it claims not to find the drivers: ----------8<----------8<---------- robert@photon:~/tmp/sample > ./samplegrab (dc1394_control.c) Couldn't get raw1394 handle! Unable to aquire a raw1394 handle did you insmod the drivers? ----------8<----------8<---------- Yes, I did! :-) ----------8<----------8<---------- photon:~ # lsmod Module Size Used by raw1394 6376 0 ohci1394 20144 0 ieee1394 19240 0 [raw1394 ohci1394] ne2k-pci 4648 2 (autoclean) 8390 6420 0 (autoclean) [ne2k-pci] ----------8<----------8<---------- Here's the result from 'cat /dev/ohci1394': ----------8<----------8<---------- IEEE-1394 OHCI Driver status report: bus number: 0x3ff Node ID: 0x0 ### Host data ### node_count: 2 node_id : 0000FFC0 irm_id : 0000FFFF busmgr_id : 0000FFFF initialized ---Iso Receive DMA--- Current buf: 0 offset: 0 ---Async Receive DMA--- Ar req current buf: 0 offset: 96 AR resp current buf: 0 offset: 700 ---Async Transmit DMA--- AT req prg: 28 sent: 28 free: 32 branchAddrPtr: c0837008 AT req queue: first: 00000000 last: 00000000 AR resp prg: 0 sent: 0 free: 32 branchAddrPtr: 00000000 AT resp queue: first: 00000000 last: 00000000 ### HC Register dump ### Version : 01010000 GUID_ROM : 00000000 ATRetries : 00000822 CSRData : 00000000 CSRCompData : 00000000 CSRControl : 80000000 ConfigROMhdr: 04045f28 BusID : 31333934 BusOptions : f07da002 GUIDHi : 08144356 GUIDLo : 000019f3 ConfigROMmap: 00bdf000 PtdWrAddrLo : 00000000 PtdWrAddrHi : 00000000 VendorID : 00000000 HCControl : 008e0000 SelfIDBuffer: 00be2000 SelfIDCount : 00060014 IRMuChMaskHi: 00000000 IRMuChMaskLo: 00000000 IntEvent : 00700000 IntMask : 840300ff IsoXmIntEvnt: 00000000 IsoXmIntMask: 00000000 IsoRcvIntEvt: 00000000 IsoRcvIntMsk: 00000001 FairnessCtrl: 00000000 LinkControl : 00300200 NodeID : 8800ffc0 PhyControl : 0000017f IsoCyclTimer: 452d0a21 AsRqFilterHi: ffffffff AsRqFilterLo: ffffffff PhyReqFiltHi: ffffffff PhyReqFiltLo: ffffffff PhyUpperBnd : 00000000 AsRqTrCxtCtl: 00008054 AsRqTrCmdPtr: 00837002 AsRsTrCtxCtl: 00000040 AsRsTrCmdPtr: 00000000 AsRqRvCtxCtl: 00008409 AsRqRvCmdPtr: 00df9001 AsRsRvCtxCtl: 00008451 AsRsRvCmdPtr: 009a9001 IntEvent : 00700000 IsoRCtxCtl00: d0008400 IsoRCmdPtr00: 0082f001 IsoRCxtMch00: f0000000 IsoRCtxCtl01: 00000000 IsoRCmdPtr01: 00000000 IsoRCxtMch01: 00000000 IsoRCtxCtl02: 00000000 IsoRCmdPtr02: 00000000 IsoRCxtMch02: 00000000 IsoRCtxCtl03: 00000000 IsoRCmdPtr03: 00000000 IsoRCxtMch03: 00000000 IsoTCtxCtl00: 00000000 IsoTCmdPtr00: 00000000 IsoTCtxCtl01: 00000000 IsoTCmdPtr01: 00000000 IsoTCtxCtl02: 00000000 IsoTCmdPtr02: 00000000 IsoTCtxCtl03: 00000000 IsoTCmdPtr03: 00000000 IsoTCtxCtl04: 00000000 IsoTCmdPtr04: 00000000 IsoTCtxCtl05: 00000000 IsoTCmdPtr05: 00000000 IsoTCtxCtl06: 00000000 IsoTCmdPtr06: 00000000 IsoTCtxCtl07: 00000000 IsoTCmdPtr07: 00000000 ----------8<----------8<---------- Kernel is 2.2.18, libraw1394-0.8.2, libdc1394_0.8. Any idea? Bye, Robert -- _ / \ _ Dipl.-Ing. Robert Schwebel r.s...@ze... --/ \ / \/-------------------------------------------------------- \_/ ZEUTEC Opto-Elektronik GmbH www.zeutec.de Kieler Str. 211, 24786 Rendsburg, Germany Phone: +49-4331-136-653 Fax: +49-4331-136-651 +++ Neue Adresse! +++ New Address! +++ Neue Adresse! +++ New Address! ++++ |
From: Brion V. <br...@po...> - 2001-02-23 00:35:42
|
On Thu, 22 Feb 2001, Dave Chavez wrote: > I'm not sure if the current drivers/modules are supported under > the Linux 2.4.1 kernel. I have 2.4.1 with the patched version of > the ieee1394 drivers built into the kernel (ie, not modules). > The sbp2_1394 is compiled/loaded as a module. I have a Maxtor 80GB > drive attached to my machine (laptop), and I get I/O errors when I > sync the disk. It appears I am not alone after all... In case my earlier message was eaten alive by the list (I don't see it in the archives), I'm having errors on large writes (and sometimes reads) on my 40GB Maxtor under 2.4.1 + cvs'd 1394. Same with 2.4.2. Downgrading to 2.4.0 + cvs'd 1394 appears to solve the problem, so it's definately a conflict with something else in the kernel, don't know what. My errors look like this: ieee1394: sbp2: SBP2_SCSI_STATUS_CHECK_CONDITION [valid=0] Info fld=0x73600b0, Current bh08:01: sense key Illegal Request Additional sense indicates Invalid field in cdb SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000002 [valid=0] Info fld=0x73600b0, Current sd08:01: sense key Illegal Request Additional sense indicates Invalid field in cdb I/O error: dev 08:01, sector 10826816 Are these what you're getting? (I have a desktop system, using Maxtor's cheapie OHCI PCI card for the 1394 interface.) > ** When I plug in the device, I get the following message (to the console): > --------------------------------------------------------------------------- > ohci1394_0: Error in reception of self-id packetsSelf-id count: 80650004 q[0]: > 00652f9b This I'm not getting. -- brion vibber (br...@po... / vi...@us...) |
From: Dave C. <dc...@io...> - 2001-02-22 21:33:08
|
Hi all, I'm not sure if the current drivers/modules are supported under the Linux 2.4.1 kernel. I have 2.4.1 with the patched version of the ieee1394 drivers built into the kernel (ie, not modules). The sbp2_1394 is compiled/loaded as a module. I have a Maxtor 80GB drive attached to my machine (laptop), and I get I/O errors when I sync the disk. I have included below some of the output at different stages of the process, hoping it might give insight into the problem. (Note: I was able to get things working fairly well under the 2.4.0 kernel.) Any hints are greatly appreciated. Thanks in advance, Dave =================================================================== ** ieee1394-relevant boot messages: ------------------------------------ ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards PCI: Assigned IRQ 9 for device 00:0d.0 PCI: The same IRQ used for device 00:0a.1 ohci1394_0: remapped memory spaces reg 0xd0800000 ohci1394_0: allocated interrupt 9 ohci1394_0: soft reset finished ohci1394_0: max packet size = 2048 bytes ohci1394_0: 4 iso receive contexts available ohci1394_0: 8 iso transmit contexts available ohci1394_0: Receive DMA ctx=0 initialized ohci1394_0: Receive DMA ctx=1 initialized ohci1394_0: AT dma ctx=0 initialized ohci1394_0: AT dma ctx=1 initialized ohci1394_0: Receive DMA ctx=2 initialized ohci1394_0: resetting bus on request ieee1394: detected 1 ohci1394 adapter ohci1394_0: PhyControl: 0000017F ohci1394_0: SelfID process finished (phyid 1, root) ohci1394_0: selfid packet 0x807f8460 rcvd ieee1394: including selfid 0x60847f80 ohci1394_0: selfid packet 0x817f84d6 rcvd ieee1394: including selfid 0xd6847f81 ohci1394_0: This node self-id is 0x817f84d6 ohci1394_0: calling self-id complete ohci1394_0: Got phy packet ctx=0 ... discarded ieee1394: 1 host adapter initialized raw1394: /dev/raw1394 device initialized ** When I plug in the device, I get the following message (to the console): --------------------------------------------------------------------------- ohci1394_0: Error in reception of self-id packetsSelf-id count: 80650004 q[0]: 00652f9b ** The log (dmesg) shows: ------------------------- ohci1394_0: Bus reset ohci1394_0: SelfID process finished (phyid 1, root) ohci1394_0: Error in reception of self-id packetsSelf-id count: 80650004 q[0]: 00652f9b ohci1394_0: PhyControl: 000001FF ohci1394_0: PhyControl: 000001FF ohci1394_0: SelfID process finished (phyid 1, root) ohci1394_0: selfid packet 0x807f8460 rcvd ieee1394: including selfid 0x60847f80 ohci1394_0: selfid packet 0x817f84d6 rcvd ieee1394: including selfid 0xd6847f81 ohci1394_0: This node self-id is 0x817f84d6 ohci1394_0: calling self-id complete ieee1394: GUID request sent to node 0 ieee1394: guid transaction error: ack 2, rcode 6 ** Running testlibraw yields: ----------------------------- # ./testlibraw successfully got handle current generation number: 1 1 card(s) found nodes on bus: 2, card name: ohci1394 using first card found: 2 nodes on bus, local ID is 1, IRM is 63 doing transactions with custom tag handler trying to send read request to node 0... completed with 0x00020007, value 0x00000000 trying to send read request to node 1... completed with 0x00100000, value 0x86e8c933 using standard tag handler and synchronous calls trying to read from node 0... completed with 0x00020007, value 0x00000000 trying to read from node 1... completed with 0x00100000, value 0xf014ca33 testing FCP monitoring on local node got fcp command from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef got fcp response from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef polling for leftover messages ** Installing the SBP2 module (insmod sbp2_1394.o) yields: ---------------------------------------------------------- SBP-2 protocol driver for IEEE-1394 ieee1394: sbp2: Node ffc1, Found SBP-2 device ieee1394: sbp2: Logged into SBP-2 device ieee1394: sbp2: SBP-2 device max speed S400 and payload 2KB ** Running the rescan-scsi-bus.sh script displays: -------------------------------------------------- Host adapter 0 (sbp2) found. Scanning for device 0 0 0 0 ... NEW: Vendor: Maxtor Model: 1394 storage Rev: 55d Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 ieee1394: sbp2: UNIT ATTENTION - retry command SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB) Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: Maxtor Model: 1394 storage Rev: 55d Type: Direct-Access ANSI SCSI revision: 02 1 new device(s) found. 0 device(s) removed. |
From: C&D W. <wil...@ho...> - 2001-02-22 02:12:25
|
Hello Firewire wizes, I need to set up an isochronous transfer on a PCILynx FireWire card in linux. I have an ip over firewire driver. How can I set the registers in the board for this? I know what registers to set, I just don't know how. Do I need to alter the driver code or can I do it through an application? Hope you do not think of this as a trivial question. I need at least somewhere where I can get this kind of information. I need to get started. Thanks! Catheryne William _________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
From: Tim H. <ka...@ka...> - 2001-02-21 09:45:19
|
lspci should do it On Tue, 20 Feb 2001, Felix Tang wrote: > All, > > OK... this is semi-off topic. Does anyone know how I can find out what > i.link chipset is in the pcgz505ls? I am totally stumped because Sony > doesn't give useful information like that. > > I understand that the cxd3222 is ohci compliant BUT is it in this damn > notebook. > > Felix > > > On Thu, 15 Feb 2001, Tim Hurman wrote: > > > Yep, I have a Vaio F809K which has this chipset, it woks well, my setup > > is: > > 2.4.1 kernel > > latest linux1394 sources as the ones in 2.4.1 cause an interrupt kernel > > panic on insertion of a device. > > XFree86 4.02 as it copes a lot better with digital flatpanels and the > > hardware the vaio has. > > > > I also use devfs, however the video1394 has a probem with this and the > > device does not appear. > > > > Tim. > > > > On Wed, 14 Feb 2001, Felix Tang wrote: > > > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Wed, 14 Feb 2001 18:35:08 -0500 > > > From: James Fung <fu...@ey...> > > > To: Felix Tang <ta...@ey...> > > > Subject: Sony Vaio C1VE 1394 compat > > > > > > Has anyone tried Linux on the C1VE Vaio, or know what type of controller > > > it has? If so, does the 1394 controller work with the linux1394 drivers > > > (is it a CXD3222?) > > > > > > -James > > > > > > > > > _______________________________________________ > > > mailing list Lin...@li... > > > http://lists.sourceforge.net/lists/listinfo/linux1394-user > > > > > > > > _______________________________________________ > mailing list Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-user > |
From: Felix T. <ta...@ee...> - 2001-02-21 00:04:19
|
All, OK... this is semi-off topic. Does anyone know how I can find out what i.link chipset is in the pcgz505ls? I am totally stumped because Sony doesn't give useful information like that. I understand that the cxd3222 is ohci compliant BUT is it in this damn notebook. Felix On Thu, 15 Feb 2001, Tim Hurman wrote: > Yep, I have a Vaio F809K which has this chipset, it woks well, my setup > is: > 2.4.1 kernel > latest linux1394 sources as the ones in 2.4.1 cause an interrupt kernel > panic on insertion of a device. > XFree86 4.02 as it copes a lot better with digital flatpanels and the > hardware the vaio has. > > I also use devfs, however the video1394 has a probem with this and the > device does not appear. > > Tim. > > On Wed, 14 Feb 2001, Felix Tang wrote: > > > > > > > ---------- Forwarded message ---------- > > Date: Wed, 14 Feb 2001 18:35:08 -0500 > > From: James Fung <fu...@ey...> > > To: Felix Tang <ta...@ey...> > > Subject: Sony Vaio C1VE 1394 compat > > > > Has anyone tried Linux on the C1VE Vaio, or know what type of controller > > it has? If so, does the 1394 controller work with the linux1394 drivers > > (is it a CXD3222?) > > > > -James > > > > > > _______________________________________________ > > mailing list Lin...@li... > > http://lists.sourceforge.net/lists/listinfo/linux1394-user > > > |
From: Ken O. <ko...@ar...> - 2001-02-20 14:15:10
|
Sandhya Puthan Veettil wrote: > If anybody can help me - > Which is the latest version availble with included support for IEEE 1394? 2.4 is the latest Linux kernel which has IEEE 1394 support included, but from what I gather that version doesn't work. You'll need to download the latest source-code for the IEEE 1394 drivers and rebuild the kernel. Instructions for downloading the latest source is at: http://linux1394.sourceforge.net/howtos.html#upgrade -- ______________________________________________________________ Kenneth Ray Offer, II Sr. Systems Analyst Applied Research Laboratories/SDD University of Texas at Austin Office (512) 835-3859 FAX (512) 835-3259 Any opinions expressed above are mine and not necessarily those of my employer. |
From: Sandhya P. V. <sa...@mi...> - 2001-02-20 00:16:50
|
Hi, If anybody can help me - Which is the latest version availble with included support for IEEE 1394? Sandhya |
From: Felix T. <ta...@ee...> - 2001-02-15 23:25:41
|
The card works fine for me. As well as the 1394 card from SIIG. Felix On Thu, 15 Feb 2001, Sandhya Puthan Veettil wrote: > Hi, > > I am planning to buy a Orangelink Firewire PCI Board, to be inserted in a > Intel - Pentium II Linux Box running kernel 2.2.14.5-0. The card > specifications include : > > PCI 2.1 Compliant > OHCI-Link and PHY: NEC single chip; > 100 Mbit/s (12.5 MB/sec); 200 Mbit/s (25 MB/sec);400 Mbit/s (50 MB/sec) > > Is anybody aware of this board working/not working using the driver (patch) > available from sourceforge ? Can I go for it Or are there better choices ? > (I dont much worry about the price). Advice will be really appreciated. > > Also, Does anybody know whether I can also talk to another computer > (ofcourse firewire compatible) using this driver? (This is not my primary > intention though) > > > Thanks > Sandhya > > _______________________________________________ > mailing list Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-user > |
From: Brion V. <br...@po...> - 2001-02-15 22:49:23
|
Hello all... I recently got a 40GB Maxtor 1394 external hard drive & their cheapie little OHCI card (the rebate offer pulled me in, what can I say)... I was pleased to find that the SBP2 driver works well enough to mount the drive and read files from it (hurray!!), but I'm having some problems. First, it's rather slow for me. hdparm -tT gives dissapointing results: /dev/sda: Timing buffer-cache reads: 128 MB in 0.90 seconds =142.22 MB/sec Timing buffered disk reads: 64 MB in 10.44 seconds = 6.13 MB/sec I get >20MB/s read and >10MB/s write with this drive in Win98. Of course, Win98 also crashes if I go to sleep mode, then replug the drive, so it's a bit of a trade-off. :) Second, I get horrible horrible errors when I try to write any significant amount of data to the drive. Short text files seem okay, but copying an 18-meg AVI file gives me a whole series of these errors when the cache gets flushed to disk: ieee1394: sbp2: SBP2_SCSI_STATUS_CHECK_CONDITION [valid=0] Info fld=0xe8c30b0, Current bh08:01: sense key Illegal Request Additional sense indicates Invalid field in cdb SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000002 [valid=0] Info fld=0xe8c30b0, Current sd08:01: sense key Illegal Request Additional sense indicates Invalid field in cdb I/O error: dev 08:01, sector 39204800 (I ran a similar test a couple days ago and got Info fld=0x73600b0. A third test tonight has yet another value. But it's consistent each time.) I get these for gazillions of consecutive sector numbers, presumably the sectors being written to. After flushing the file back out of the cache and doing a compare with the original, most of the new file is full of garbage. :( I tried bumping the SBP2 driver down to 200Mbps with no change. I'm running Linux 2.4.1 with 1394 CVS'ed on Feb 10, and the Jan 29 SBP2 driver on a patched-up Red Hat 6.2 system. (x86 - Athlon 650, MS-6167 mobo with AMD 751 chipset, 256MB.) All 1394 stuff is modules; video1394 is compiled but not loaded. SCSI is compiled in, no real SCSI stuff though, just an ATAPI CD-RW and the 1394 hard disk. 1394 card is OHCI, comes in a Maxtor box but is manufactured by Indigita - IDT980PCI - with a Lucent Link/PHY chip - FW323-04 / 00285 / 1731225. The card seems to work fine for DV video capture in a brief test with Kino and a borrowed camera... The disk is the Maxtor 1394 External Storage 40GB, revision 55d. The card also shares its IRQ with a bunch of other devices (USB, ACPI, ethernet, and two video cards) thanks to my motherboard seeming to *have* only two available IRQs. But in theory this is not a problem... Since the Lucent chip is listed as "works" on the compatibility page, and Maxtor drives are listed as successfully tested in the sbp2 driver docs (and there are only two models that I'm aware of, my 40GB and the 80GB), I'm kind of at a loss here. Any suggestions? (Change kernel version, enable various freaky debug switches, etc?) Updated: SBP2_DEBUG_SPEWING doesn't seem to add any information. SBP2_DEBUG_SPEWING_MUCHO spits out too much for me... I can send some if anyone wants it though. :) I've tried to see how much data triggers the problem; so far it appears to be anything over 128k: if I copy 129k, I get two of these sector complaints. 4 at 130k, 23 at 140k, and 256 at 256k. But under 128k all is well. (Tested by dd'ing data from an existing file to a new file in one chunk of the given size, then immediately sync'ing. Same result when source is /dev/zero.) Interestingly, it's the *first* portion of the file that gets garbage, then the *last* 128k is okay. Wacky. I switched back to 400Mbps, tried copying a bunch of stuff again, this time no errors at sizes even up to 16MB, then it crapped out at the full 18MB, with differences starting 89k into the file. Sigh. More testing atfer a few minutes, more errors again at smaller sizes down to 129k, then fine at 128k and below as before. Huh. I've attached /proc/ohci1394 and the lspci -vv output on the card for your enjoyment. Need anything else, just holler. -- brion vibber (br...@po... / vi...@us...) |
From: Sandhya P. V. <sa...@mi...> - 2001-02-15 21:23:08
|
Hi, I am planning to buy a Orangelink Firewire PCI Board, to be inserted in a Intel - Pentium II Linux Box running kernel 2.2.14.5-0. The card specifications include : PCI 2.1 Compliant OHCI-Link and PHY: NEC single chip; 100 Mbit/s (12.5 MB/sec); 200 Mbit/s (25 MB/sec);400 Mbit/s (50 MB/sec) Is anybody aware of this board working/not working using the driver (patch) available from sourceforge ? Can I go for it Or are there better choices ? (I dont much worry about the price). Advice will be really appreciated. Also, Does anybody know whether I can also talk to another computer (ofcourse firewire compatible) using this driver? (This is not my primary intention though) Thanks Sandhya |
From: Tim H. <kan...@ka...> - 2001-02-15 09:06:18
|
Yep, I have a Vaio F809K which has this chipset, it woks well, my setup is: 2.4.1 kernel latest linux1394 sources as the ones in 2.4.1 cause an interrupt kernel panic on insertion of a device. XFree86 4.02 as it copes a lot better with digital flatpanels and the hardware the vaio has. I also use devfs, however the video1394 has a probem with this and the device does not appear. Tim. On Wed, 14 Feb 2001, Felix Tang wrote: > > > ---------- Forwarded message ---------- > Date: Wed, 14 Feb 2001 18:35:08 -0500 > From: James Fung <fu...@ey...> > To: Felix Tang <ta...@ey...> > Subject: Sony Vaio C1VE 1394 compat > > Has anyone tried Linux on the C1VE Vaio, or know what type of controller > it has? If so, does the 1394 controller work with the linux1394 drivers > (is it a CXD3222?) > > -James > > > _______________________________________________ > mailing list Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-user > |