linux1394-user Mailing List for IEEE 1394 for Linux (Page 7)
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: Jesús P. P. <jes...@gm...> - 2013-06-07 01:38:41
|
Actually I don't have access to that computer [the one with the firewire cameras] until next week [the security on the building where I work is enforced by id cards...]. I will meet with this person next week, I will send you the information as soon as possible, sorry for the delay... Regards, Jesus 2013/6/2 Clemens Ladisch <cl...@la...> > Jesús Pestana Puerta wrote: > >> And which 1394 controller? > > > > These are the modules ... > > Which controller chip? (see lspci) > > > Regards, > Clemens > |
From: Stefan R. <st...@s5...> - 2013-06-06 16:57:06
|
On Jun 01 Stefan Richter wrote: > while I don't have a scanner among my set of FireWire test > devices, I will try to get my hands on one of them and see how it will > behave (depending on available spare time). I will keep you posted on my > progress, if any. I now got an Epson Perfection 2450 Photo and did a first quick test with it, using a Texas Instruments TSB43AB22A based controller card, kernel 3.9, Gentoo Linux, sane-backends 1.0.23, skanlite 1.0. First I tested it on USB as a baseline, then switch it off, connected to FireWire, switched it back on, and tested again. It behaved the same on both interfaces. (The only thing was that I had to load the "sg" kernel module manually in order to make the scanner accessible via FireWire.) Here is the syslog from the FireWire session: [as root, to enable selfID logging: echo 2 > /sys/module/firewire_ohci/parameters/debug] Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: 2 selfIDs, generation 3, local node ID ffc1 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 807f8092, phy 0 [p-.] S400 gc=63 +0W Li Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 817f8cd0, phy 1 [c-.] S400 gc=63 -3W Lc Jun 6 18:19:16 stein kernel: firewire_core 0000:0d:00.0: rediscovered device fw7 Jun 6 18:19:16 stein kernel: firewire_core 0000:0d:00.0: phy config: new root=ffc1, gap_count=5 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: 2 selfIDs, generation 4, local node ID ffc1 Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 80458090, phy 0 [p-.] S400 gc=5 +0W L Jun 6 18:19:16 stein kernel: firewire_ohci 0000:0d:00.0: selfID 0: 81458cd2, phy 1 [c-.] S400 gc=5 -3W Lci Jun 6 18:19:19 stein kernel: scsi122 : SBP-2 IEEE-1394 Jun 6 18:19:19 stein kernel: firewire_sbp2 fw8.0: 127s mgt_ORB_timeout limited to 40s Jun 6 18:19:19 stein kernel: firewire_core 0000:0d:00.0: created device fw8: GUID 000048000005943d, S400 Jun 6 18:19:20 stein kernel: firewire_sbp2 fw8.0: logged in to LUN 0000 (0 retries) Jun 6 18:19:20 stein kernel: scsi 122:0:0:0: Processor EPSON GT-9700 1.05 PQ: 0 ANSI: 4 [as root: modprobe sg] Jun 6 18:26:22 stein kernel: scsi 122:0:0:0: Attached scsi generic sg7 type 3 (Embarrassingly, it took me a whole 7 minutes to figure out that sg's absence was the reason for skanlite's not finding the scanner right away.) Later this month I will probably get the opportunity to test a UMAX PowerLook 1100 Pro, which is hopefully close enough to your PowerLook 1000. -- Stefan Richter -=====-===-= -==- --==- http://arcgraph.de/sr/ |
From: Jesús P. P. <jes...@gm...> - 2013-06-02 19:22:25
|
Hello, Unfortunately I cannot answer that now (I do not have the computer here). I will answer this during the week. Sorry! Jesús 2013/6/2 Clemens Ladisch <cl...@la...> > Jesús Pestana Puerta wrote: > >> And which 1394 controller? > > > > These are the modules ... > > Which controller chip? (see lspci) > > > Regards, > Clemens > |
From: Clemens L. <cl...@la...> - 2013-06-02 19:03:42
|
Jesús Pestana Puerta wrote: >> And which 1394 controller? > > These are the modules ... Which controller chip? (see lspci) Regards, Clemens |
From: Jesús P. P. <jes...@gm...> - 2013-06-02 18:28:46
|
> What camera models do you have? I have two cameras from a company called "Videre Design". This company has stopped updating the drivers for their cameras. I believe that the company closed before the new firewire stack was released. The cameras I have do not even appear in their website as they have a resolution of 640x480 pixels and there are no such camera models in their website right now. So it is useless to try to ascertain which model I exactly have. My cameras worked badly with the new firewire stack. Even using just coriander the image transmission would stop working every now and then (meaning, it would probably stop working in less than 5 minutes). With the old firewire stack, only specific missuse of my software would trigger this problem. > And which 1394 controller? The are the modules I remove: sudo rmmod firewire_ohci sudo rmmod firewire_core These are the modules that I insert before starting my software: sudo insmod ieee1394.ko sudo insmod ohci1394.ko sudo insmod raw1394.ko sudo insmod video1394.ko > Is the software a standard IEEE 1394 based software like coriander, dvgrab, kino or the likes, or is it a generic software like skype etc., or is it a custom software written by yourself? I use coriander to test the cameras sometimes before running my software. Right now I almost never use coriander, as I have been able to debug the software enough to serve my needs. > Is the software accessing the kernel through a library or framework (libraw1394, libdc1394, gstreamer, dv4l, ...)? In order to acquire images I use only libdc1394 . All the interactions with the hardware are performed using libdc1394 function calls. The configuration, acquisition and releasing the cameras code is based on the example "grab_gray_image.c" of the libdc1394 library (libdc1394/libdc1394/examples/grab_gray_image.c). On the image processing stage of my software I use basically OpenCV and other open source libraries that are based on OpenCV. Please, do not hesitate in asking for more information, I hope this helped, Jesús Pestana 2013/6/2 Stefan Richter <st...@s5...> > On Jun 01 Jesús Pestana Puerta wrote: > > Recently, I had to put to work two old firewire cameras which drivers do > > not work well with the new firewire stack (firewire_ohci, firewire_sbp2, > > firewire_core). After a long time surfing the web for an answer to my > issue > > I came accross de following GitHub repository: > > https://github.com/veltzer/ieee1394 > [...] > > I must say that the code from the repository has allowed me to work with > > this cameras without problem on Ubuntu 12.04, on a machine with an Intel > > dual core processor (64bits). I have decided not to apply any Ubuntu > 12.04 > > updates on this machine. > [...] > > What camera models do you have? And which 1394 controller? (E.g. > "lspci -nn | grep 1394".) Is the software a standard IEEE 1394 based > software like coriander, dvgrab, kino or the likes, or is it a generic > software like skype etc., or is it a custom software written by yourself? > Is the software accessing the kernel through a library or framework > (libraw1394, libdc1394, gstreamer, dv4l, ...)? > -- > Stefan Richter > -=====-===-= -==- ---=- > http://arcgraph.de/sr/ > |
From: Stefan R. <st...@s5...> - 2013-06-02 14:46:09
|
On Jun 01 Jesús Pestana Puerta wrote: > Recently, I had to put to work two old firewire cameras which drivers do > not work well with the new firewire stack (firewire_ohci, firewire_sbp2, > firewire_core). After a long time surfing the web for an answer to my issue > I came accross de following GitHub repository: > https://github.com/veltzer/ieee1394 [...] > I must say that the code from the repository has allowed me to work with > this cameras without problem on Ubuntu 12.04, on a machine with an Intel > dual core processor (64bits). I have decided not to apply any Ubuntu 12.04 > updates on this machine. [...] What camera models do you have? And which 1394 controller? (E.g. "lspci -nn | grep 1394".) Is the software a standard IEEE 1394 based software like coriander, dvgrab, kino or the likes, or is it a generic software like skype etc., or is it a custom software written by yourself? Is the software accessing the kernel through a library or framework (libraw1394, libdc1394, gstreamer, dv4l, ...)? -- Stefan Richter -=====-===-= -==- ---=- http://arcgraph.de/sr/ |
From: Jesús P. P. <jes...@gm...> - 2013-06-02 04:28:49
|
Hello everyone, Please, first undestand that I am not fully experienced on firewire as I have started using it just recently, and also I have only worked on Ubuntu distributions. Thus I am not sure whether my feedback can be usable for you. I do believe that the sbp2 part of the old firewire stack is the module that you need to make your sensor work, but I am not 100% sure. Recently, I had to put to work two old firewire cameras which drivers do not work well with the new firewire stack (firewire_ohci, firewire_sbp2, firewire_core). After a long time surfing the web for an answer to my issue I came accross de following GitHub repository: https://github.com/veltzer/ieee1394 This repository currently provided the old firewire modules code for Ubuntu 11.x. The code can be compiled to obtain the firewire modules and install them on such Ubuntu version. After contacting the author of the above mentioned repository, he made some changes to the code on the repository to make it the modules be compilable and installable on Ubuntu 12.04. However he warned me that having a full reliable compatibility of the old firewire modules to Ubuntu 12.04 was something not to be expected due to several changes in recent versions of Ubuntu (sorry, but I cannot elaborate on the details since my knowledge of low level Ubuntu drivers is limited). I must say that the code from the repository has allowed me to work with this cameras without problem on Ubuntu 12.04, on a machine with an Intel dual core processor (64bits). I have decided not to apply any Ubuntu 12.04 updates on this machine. Sometimes I need to restart the old firewire modules because my software fails to initialize the cameras. I believe this is probably a bug on my software, which I have decided to ignore for my current work. My point is, this repository might be a solution to your problem, Jesus Pestana 2013/6/1 Stefan Richter <st...@s5...> > On Jun 01 Renan Calliari wrote: > > Hi people, > > > > I've never got firewire_sbp2 module working with my Scanner Umax > > Powerlook 1000. Instead I used sbp2 module and the scanner works well. > > So I decided upgrade from Fedora 12 (ieee1394 kmdl driver) to Fedora 18. > > Was Fedora 12 the most recent system which you tried successfully with > this scanner? > > > The scanner was recognized, the module send some commands to scanner and > > then stop work. > > > > Additional information > > > > $ uname -r > > 3.9.4-200.fc18.i686.PAE > > > > $ lsmod | grep -e 1394 -e firewire > > firewire_sbp2 18112 0 > > firewire_ohci 35451 0 > > firewire_core 55929 2 firewire_ohci,firewire_sbp2 > > crc_itu_t 12549 1 firewire_core > > > > $ lspci -vvv > > 02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 > > [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) (prog-if 10 [OHCI]) > > Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series > motherboard > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > > ParErr- Stepping- SERR+ FastB2B- DisINTx- > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium > > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > Latency: 64 (8000ns max), Cache Line Size: 16 bytes > > Interrupt: pin A routed to IRQ 20 > > Region 0: Memory at feaff800 (32-bit, non-prefetchable) > [size=2K] > > Region 1: I/O ports at dc00 [size=128] > > Capabilities: <access denied> > > Kernel driver in use: firewire_ohci > > > > $ dmesg > > [ 529.809589] firewire_core 0000:02:03.0: phy config: new root=ffc1, > gap_count=5 > > [ 560.384101] firewire_core 0000:02:03.0: giving up on node ffc0: > reading config rom failed: send error > > [ 701.744212] firewire_core 0000:02:03.0: phy config: new root=ffc1, > gap_count=5 > > [ 702.246920] firewire_core 0000:02:03.0: created device fw1: GUID > 00102b104100007b, S400 > > [ 702.309449] scsi4 : SBP-2 IEEE-1394 > > [ 702.514744] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > > [ 702.535186] scsi 4:0:0:0: Scanner UMAX PowerLook 1000 > V1.3 PQ: 0 ANSI: 2 > > [ 702.537121] scsi 4:0:0:0: Attached scsi generic sg4 type 6 > > [ 986.535423] scsi 4:0:0:0: timing out command, waited 120s > > [ 1107.153430] scsi 4:0:0:0: timing out command, waited 120s > > [ 1228.376368] scsi 4:0:0:0: timing out command, waited 120s > > I would be interested to learn which SCSI request timed out, or which > sequence of SCSI requests lead up to the time-out. But right now I don't > have a quick recipe how to enable SCSI command logging. > > At a higher level, can you describe which actions lead up to such timeout > events? Do they happen even without running any image acquisition > application, or is it happening only after you actually do run such an > application and start a scan? If the latter, does it happen at each and > every scan, or only randomly? > > (You can watch for the timeout events for example with a console window, > running "sudo tail -f /var/log/messages" in it. Or at least this is the > log file which most distributions seem to use to store kernel messages.) > > > I tried blacklist the modules and the scanner was not recognized > > blacklist firewire-ohci > > blacklist firewire-sbp2 > > blacklist firewire-net > > This disable FireWire support entirely --- except if FireWire drivers are > already loaded in initrd (initial RAM disk), in which such blacklist > directives would have to be brought into the initrd itself in order to be > effective. > > This does not bring back FireWire support through the older ohci1394 + > ieee1394 + sbp2 drivers because these are not present anymore in kernels > 2.6.37 or newer. > > [...] > > I tried this option in modprobe.d directory without success > > options sbp2 long_ieee1394_id=y > > This only affects how /dev/disk/by_id/* symlinks to FireWire HDDs and > ODDs are named if you still had the old sbp2 driver. It is immaterial to > scanners or/ and to the newer firewire-sbp2 driver. > > [...] > > Is there a source package for the old sbp2 module? > > I am currently not aware of anybody maintaining such a forward port. > There was a guy who kept porting some of the iee1394 drivers to kernels > newer than 2.6.36 in order to use them with FireWire audio devices, but I > do not remember who it was, how long he kept it up or is keeping it up, > and whether he provided sbp2 among those forward ports. > > Note that it is not obvious yet whether the current behaviour of the > scanner under Fedora 18 is caused by the FireWire kernel drivers or the > SCSI kernel drivers above it or by a userland component (udev or some > low-level desktop integration component or something along these lines) or > even by the scanning software itself. > > Anyhow; while I don't have a scanner among my set of FireWire test > devices, I will try to get my hands on one of them and see how it will > behave (depending on available spare time). I will keep you posted on my > progress, if any. > -- > Stefan Richter > -=====-===-= -==- ----= > http://arcgraph.de/sr/ > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > |
From: Stefan R. <st...@s5...> - 2013-06-01 14:45:23
|
On Jun 01 Renan Calliari wrote: > Hi people, > > I've never got firewire_sbp2 module working with my Scanner Umax > Powerlook 1000. Instead I used sbp2 module and the scanner works well. > So I decided upgrade from Fedora 12 (ieee1394 kmdl driver) to Fedora 18. Was Fedora 12 the most recent system which you tried successfully with this scanner? > The scanner was recognized, the module send some commands to scanner and > then stop work. > > Additional information > > $ uname -r > 3.9.4-200.fc18.i686.PAE > > $ lsmod | grep -e 1394 -e firewire > firewire_sbp2 18112 0 > firewire_ohci 35451 0 > firewire_core 55929 2 firewire_ohci,firewire_sbp2 > crc_itu_t 12549 1 firewire_core > > $ lspci -vvv > 02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 > [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) (prog-if 10 [OHCI]) > Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > ParErr- Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 64 (8000ns max), Cache Line Size: 16 bytes > Interrupt: pin A routed to IRQ 20 > Region 0: Memory at feaff800 (32-bit, non-prefetchable) [size=2K] > Region 1: I/O ports at dc00 [size=128] > Capabilities: <access denied> > Kernel driver in use: firewire_ohci > > $ dmesg > [ 529.809589] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > [ 560.384101] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error > [ 701.744212] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 > [ 702.246920] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 > [ 702.309449] scsi4 : SBP-2 IEEE-1394 > [ 702.514744] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > [ 702.535186] scsi 4:0:0:0: Scanner UMAX PowerLook 1000 V1.3 PQ: 0 ANSI: 2 > [ 702.537121] scsi 4:0:0:0: Attached scsi generic sg4 type 6 > [ 986.535423] scsi 4:0:0:0: timing out command, waited 120s > [ 1107.153430] scsi 4:0:0:0: timing out command, waited 120s > [ 1228.376368] scsi 4:0:0:0: timing out command, waited 120s I would be interested to learn which SCSI request timed out, or which sequence of SCSI requests lead up to the time-out. But right now I don't have a quick recipe how to enable SCSI command logging. At a higher level, can you describe which actions lead up to such timeout events? Do they happen even without running any image acquisition application, or is it happening only after you actually do run such an application and start a scan? If the latter, does it happen at each and every scan, or only randomly? (You can watch for the timeout events for example with a console window, running "sudo tail -f /var/log/messages" in it. Or at least this is the log file which most distributions seem to use to store kernel messages.) > I tried blacklist the modules and the scanner was not recognized > blacklist firewire-ohci > blacklist firewire-sbp2 > blacklist firewire-net This disable FireWire support entirely --- except if FireWire drivers are already loaded in initrd (initial RAM disk), in which such blacklist directives would have to be brought into the initrd itself in order to be effective. This does not bring back FireWire support through the older ohci1394 + ieee1394 + sbp2 drivers because these are not present anymore in kernels 2.6.37 or newer. [...] > I tried this option in modprobe.d directory without success > options sbp2 long_ieee1394_id=y This only affects how /dev/disk/by_id/* symlinks to FireWire HDDs and ODDs are named if you still had the old sbp2 driver. It is immaterial to scanners or/ and to the newer firewire-sbp2 driver. [...] > Is there a source package for the old sbp2 module? I am currently not aware of anybody maintaining such a forward port. There was a guy who kept porting some of the iee1394 drivers to kernels newer than 2.6.36 in order to use them with FireWire audio devices, but I do not remember who it was, how long he kept it up or is keeping it up, and whether he provided sbp2 among those forward ports. Note that it is not obvious yet whether the current behaviour of the scanner under Fedora 18 is caused by the FireWire kernel drivers or the SCSI kernel drivers above it or by a userland component (udev or some low-level desktop integration component or something along these lines) or even by the scanning software itself. Anyhow; while I don't have a scanner among my set of FireWire test devices, I will try to get my hands on one of them and see how it will behave (depending on available spare time). I will keep you posted on my progress, if any. -- Stefan Richter -=====-===-= -==- ----= http://arcgraph.de/sr/ |
From: Renan C. <ren...@te...> - 2013-06-01 13:10:56
|
Hi people, I've never got firewire_sbp2 module working with my Scanner Umax Powerlook 1000. Instead I used sbp2 module and the scanner works well. So I decided upgrade from Fedora 12 (ieee1394 kmdl driver) to Fedora 18. The scanner was recognized, the module send some commands to scanner and then stop work. Additional information $ uname -r 3.9.4-200.fc18.i686.PAE $ lsmod | grep -e 1394 -e firewire firewire_sbp2 18112 0 firewire_ohci 35451 0 firewire_core 55929 2 firewire_ohci,firewire_sbp2 crc_itu_t 12549 1 firewire_core $ lspci -vvv 02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (8000ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 20 Region 0: Memory at feaff800 (32-bit, non-prefetchable) [size=2K] Region 1: I/O ports at dc00 [size=128] Capabilities: <access denied> Kernel driver in use: firewire_ohci $ dmesg [ 529.809589] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 560.384101] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error [ 701.744212] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 702.246920] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 [ 702.309449] scsi4 : SBP-2 IEEE-1394 [ 702.514744] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [ 702.535186] scsi 4:0:0:0: Scanner UMAX PowerLook 1000 V1.3 PQ: 0 ANSI: 2 [ 702.537121] scsi 4:0:0:0: Attached scsi generic sg4 type 6 [ 986.535423] scsi 4:0:0:0: timing out command, waited 120s [ 1107.153430] scsi 4:0:0:0: timing out command, waited 120s [ 1228.376368] scsi 4:0:0:0: timing out command, waited 120s I tried blacklist the modules and the scanner was not recognized blacklist firewire-ohci blacklist firewire-sbp2 blacklist firewire-net [ 423.766103] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 454.344054] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error [ 608.274940] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 608.776140] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 I tried this option in modprobe.d directory without success options sbp2 long_ieee1394_id=y [ 365.753414] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 396.368071] firewire_core 0000:02:03.0: giving up on node ffc0: reading config rom failed: send error [ 537.562657] firewire_core 0000:02:03.0: phy config: new root=ffc1, gap_count=5 [ 538.065346] firewire_core 0000:02:03.0: created device fw1: GUID 00102b104100007b, S400 [ 538.208760] scsi4 : SBP-2 IEEE-1394 [ 538.413848] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) [ 538.434161] scsi 4:0:0:0: Scanner UMAX PowerLook 1000 V1.3 PQ: 0 ANSI: 2 [ 538.436127] scsi 4:0:0:0: Attached scsi generic sg4 type 6 [ 758.903434] scsi 4:0:0:0: timing out command, waited 120s Is there a source package for the old sbp2 module? Renan Calliari |
From: John S. <jhs...@ao...> - 2013-05-01 11:16:46
|
http://pressurewasher-uk.info/wp-content/plugins/tv1mod/bite.php?dntsaam831rqco ------------------------------- One of life's small satisfactions is copping first place on a newly opened checkout line. -- Libbie Fudim |
From: Christine M. <chr...@pr...> - 2013-04-30 08:36:27
|
Dear Linux User, Receive your $5000 Welcome Bonus How? 1. Download the software 2. Register a real money account 3. Deposit and receive your $5000 Welcome Bonus with all games included Click here to claim your bonus now http://promosyonnedir.net/c/click/883/82402954/01888.html Why? Flash/Download All games included Multilingual software Live dealers Fast Payouts & Support 24/7 Frequent player promotions This offer is only lasting for the next 48 hours from the top name in the online casino industry, MansionCasino.com Join now to claim your $5000 Welcome Bonus. http://promosyonnedir.net/c/click/883/82402954/01888.html MansionCasino.com is licensed and regulated to offer online gaming services under the jurisdiction of Gibraltar. © 2013 MansionCasino.com is an internationally registered trademark. To unsubscribe, click here http://promosyonnedir.net/c/unsub/403/82402954/01888.html |
From: Stefan R. <st...@s5...> - 2013-03-24 15:16:09
|
Hi everyone, Linux kernel 3.8 has been out for a few weeks already, and kernel 3.9 is currently available as release candidate 4. Here are release notes for the firewire kernel drivers: *Linux 3.8* firewire-net: - fix reception of fragmented multicast and broadcast datagrams firewire-sbp2: - pass through thin provisioning related opcodes to SPC-3 devices snd-scs1x: - New ALSA MIDI driver for Stanton SCS.1d and SCS.1m FireWire DJ controllers, written by Clemens Ladisch. (While MIDI is handled by the snd-scs1x driver, audio I/O with SCS.1m is handled by FFADO userspace drivers.) *Linux 3.9* Only some minor janitorial changes to the firewire subsystem went into this kernel. -- Stefan Richter -=====-===-= --== ==--- http://arcgraph.de/sr/ |
From: Greg S. <swa...@ya...> - 2013-03-18 12:43:49
|
http://www.construction-frankfurt.de/pqx/cjjtjmhqoqoo?nqhqciktpxociu |
From: A&M A. <new...@am...> - 2012-12-31 06:11:44
|
: http://webmail.am-architects.gr/wishes_2013/2013.html?utm_source=email+marketing&utm_campaign=AM+Wishes2013&utm_medium=email?utm_source=email+marketing&utm_campaign=AM+Wishes2013&utm_medium=email We, at A&M Architects Engineers and Project Managers, wish you a Happy and Creative New Year! : http://webmail.am-architects.gr/wishes_2013/2013.html?utm_source=email+marketing&utm_campaign=AM+Wishes2013&utm_medium=email?utm_source=email+marketing&utm_campaign=AM+Wishes2013&utm_medium=email You are receiving this email because you subscribed to am-architects.gr mailing list to receive news and updates for upcoming events. If you no longer wish to receive emails from in...@am... please unsubscribe. ---------------------------------------- This email was sent from A&M Architects to lin...@li.... Click here to unsubscribe http://list.mlgn2eu.com/unsubscribe?u=8ae5780d22688d976ebce9d8fb3db81c&id=0f55a446&e=ec48533c&c=b01af1d0&ln=en A&M Architects, in...@am..., Athens, 11257, Greece Email Marketing by www.mailigen.biz |
From: Garry N. <ru...@sp...> - 2012-12-28 00:25:32
|
<html> <head> <title>The Battlestar Galactica has landed at Red Flush</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <table id="Table_01" width="700" height="573" border="0" cellpadding="0" cellspacing="0" align="center"> <tr> <td height="166" colspan="2"> <a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Promo&camp=22Dec2012N&email=lin...@li...&BTag=Aff_0949_1430_REDFLUSH_OIT_RMDEN204&promo=battlestar-galactica-150-match&Lang=EN"><img src="http://runner01.loyal-play.com/CSImgHost/battlestar/BattleStar1.png" alt="" border="0"></a></td> </tr> <tr> <td width="28"> </td> <td width="672" height="193" valign="top" style="font-family:Tahoma, Geneva, sans-serif; font-size:12px; color:#666;"> <table width="665" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="340" valign="top" style="font-family:Tahoma, Geneva, sans-serif; font-size:12px; color:#666;"> <p><strong style="color:#c10000;">Welcome to the Battlestar Galactica!</strong></p> <p>One of the most famous spaceships of all time is docking at Red Flush Casino in an exciting new game: <a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Promo&camp=22Dec2012N&email=lin...@li...&BTag=Aff_0949_1430_REDFLUSH_OIT_RMDEN204&promo=battlestar-galactica-150-match&Lang=EN" style="color:#c10000;">Battlestar Galactica video slot</a>. <br> In honor of this intergalactic occasion, Red Flush Casino is giving away the chance to join the crew at our stellar Microgaming casino and explore the universe with the most anticipated game of the year! </p></td> <td width="325" valign="top" style="font-family:Tahoma, Geneva, sans-serif; font-size:12px; color:#666;"><p> </p> <p style="color:#c10000;"><strong>Battlestar Galactica Features</strong>:</p> <ul> <li>Never-before-seen bonus features!</li> <li>Normal, Run and Fight modes lets you get in on all the action as the Cyclons approach!</li> <li>Battlestar Galactica TV clips!</li> <li>Go from Civilian to Admiral with Ranking Achievements! </li> </ul></td> </tr> </table> </td> <td width="4"> </td> </tr> <tr> <td width="28"> </td> <td colspan="2" style="font-family:Tahoma, Geneva, sans-serif; font-size:18px; color:#c10000;"><p align="center"><strong>Here's your chance to embark on the voyage of a lifetime:<br/>Get 100% Match up to $300 on Battlestar Galactica video slot </strong></p></td> <td width="4"> </td> </tr> <tr> <td colspan="2"> <a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Promo&camp=22Dec2012N&email=lin...@li...&BTag=Aff_0949_1430_REDFLUSH_OIT_RMDEN204&promo=battlestar-galactica-150-match&Lang=EN"><img src="http://runner01.loyal-play.com/CSImgHost/battlestar/BattleStar5.png" alt="" border="0"></a></td> </tr> <tr> <td width="28"> </td> <td colspan="2" style="font-family:Tahoma, Geneva, sans-serif; font-size:12px; color:#666;"><p>The Cylons are coming⦠Luckily, Red Flush Casino has everything you need to save humankind, including a <a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Promo&camp=22Dec2012N&email=lin...@li...&BTag=Aff_0949_1430_REDFLUSH_OIT_RMDEN204&promo=battlestar-galactica-150-match&Lang=EN" style="color:#c10000;"><br/>Battlestar Galactica Survival Kit</a> which can be claimed immediately after you had made your first deposit! </p> <p> For more information on this great offer, please contact our dedicated <a href="https://pcmchat3.valueactive.eu/MgsChatWindow.aspx?MGS_PCM_CasinoId=1531&MGS_PCM_SessionLanguage=en&MGS_PCM_Resource=Email " target="_blank" style="color:#c10000;">24/7 support team</a>. <br> <strong style="color:#c10000;">Join the Red Flush Casino crew today and save the human race! </strong></p> <p><strong>So say we all!</strong></p> <p><strong>Red Flush Casino</strong><br> <a href="mailto:su...@re..." style="color:#c10000;"><strong>Email </strong></a><strong>|</strong> <a href="https://pcmchat3.valueactive.eu/MgsChatWindow.aspx?MGS_PCM_CasinoId=1531&MGS_PCM_SessionLanguage=en&MGS_PCM_Resource=Email " target="_blank" style="color:#c10000;"><strong> Live Chat</strong></a><br> <a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Terms&camp=22Dec2012N&email=lin...@li...&BTag=Aff_0949_1430_REDFLUSH_OIT_RMDEN204&promo=battlestar-galactica-150-match&Lang=EN" style="color:#c10000;">Terms and Conditions Apply</a></p> <p> </p></td> </tr> </table> <table width="490" border="0" cellpadding="0" cellspacing="0" align="center"> <tr> <td width="86" align="center"><img src="http://www.clubredgaming.net/static-graphics/footer/certified.png" alt="Ecogra" width="75" height="38" border="0" /></td> <td width="120"><img src="http://www.clubredgaming.net/static-graphics/footer/micorgaming.png" alt="Microgaming" width="148" height="38" border="0" /></td> <td width="120" align="center"><img src="http://www.clubredgaming.net/static-graphics/footer/Payout_langs.png" width="104" height="38" alt="img" /></td> <td width="118" align="center"><img src="http://www.clubredgaming.net/static-graphics/footer/MgsChatWindow-en.png" alt="24 hour support" width="107" height="45" border="0"></td> <td align="center" width="46"><img src="http://www.clubredgaming.net/static-graphics/footer/18.png" alt="" width="39" height="41" border="0"></td> </tr> <tr> <td colspan=5> <br /><a href="http://runner01.loyal-play.com/CSImgHost/index.php?Disp=CSRF&tb=Unsib&camp=22Dec2012N&email=lin...@li...&promo=battlestar-galactica-150-match&Lang=EN">Unsubscribe</a><br /><br /><img src="http://runner01.loyal-play.com/CSImgHost/GifGen.php?cname=22Dec2012N&email=lin...@li...&CS=RF"> </td> </tr> </table> </body> </html> |
From: Stefan R. <st...@s5...> - 2012-12-03 22:58:46
|
Hi all, linux 3.7, currently available as -rc8 and soon to be finally released, contains the following changes to the IEEE 1394 subsystem: firewire-core: - cdev ioctl ABI: On 64-bit architectures, the kernel wrote 4 bytes too many to non-zero fw_cdev_get_info.bus_reset. This could corrupt user memory in case of x86-32 userland on x86-64 kernel. This was fixed also in kernel 3.6.3, 3.5.7.1, 3.4.15, 3.2.32, 3.0.47. - Seed the random number generator with GUIDs of FireWire nodes. The purpose is not to add entropy but to achieve different seeds on different machines. - internal optimization concerning address handlers firewire-ohci: - More complete TI TSB41BA3D support. (Properly read the local selfID0.i bit. TSB41BA3D is a rarely used 1394b S400β phy.) sbp-target: - minor fixes Enjoy. -- Stefan Richter -=====-===-- ==-- ---== http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2012-10-25 17:52:17
|
on a different box I just ran it in a loop for 12 hours. no crash. On Wed, Oct 24, 2012 at 9:37 PM, eviljoel <evi...@li...> wrote: > I've ran it a lot and never saw it. > > - eviljoel > > > On Wed, Oct 24, 2012 at 5:23 PM, Carl Karsten <ca...@pe...> wrote: >> On Wed, Oct 24, 2012 at 5:02 PM, Stefan Richter >> <st...@s5...> wrote: >>>> On Oct 23 Carl Karsten wrote: >>>> > Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC >>>> > 2012 x86_64 x86_64 x86_64 GNU/Linux >>>> [...] >>>> > sudo ./async-loop-ck >>>> [...] >>>> > after about a min.. >>>> > >>>> > stack dump on the console, but I still have an ssh session running. >>>> > >>>> > top line of console: >>>> > unable to handle kernel NULL pointer dereference at 00000000000000690 >>> >>> Carl sent screenshots. I uploaded them to: >>> https://bugzilla.kernel.org/show_bug.cgi?id=49491 >>> https://bugzilla.kernel.org/attachment.cgi?id=84731 >>> https://bugzilla.kernel.org/attachment.cgi?id=84741 >>> >>> The call trace is: >>> in page_waitqueue+06e/0x90 >>> unlock_page+0x1d/0x40 >>> filemap_fault+0x3ba/0x3e0 >>> __do_fault+0x72/0x550 >>> ? rb_insert_color+0x110/0x150 >>> handle_pte_fault+0xfa0x200 >>> ? cpumask_any_but+0x2d/0x40 >>> handle_mm_fault+0x1f8/0x350 >>> do_page_fault+0x150/0x520 >>> ? mprotect_fixup+0x17d/0x2b0 >>> ? sys_mprotect+0x1f0/0x250 >>> page_fault+0x25/0x30 >>> >>> Carl, is this rare or frequent? >> >> Can't say. It has happened once. But I have only run >> ./async-loop-ck maybe 10 times. sometimes it has 'hung' and I ^Ced it. >> >> >> -- >> Carl K >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_sfd2d_oct >> _______________________________________________ >> mailing list Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux1394-user > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user -- Carl K |
From: eviljoel <evi...@li...> - 2012-10-25 02:37:20
|
I've ran it a lot and never saw it. - eviljoel On Wed, Oct 24, 2012 at 5:23 PM, Carl Karsten <ca...@pe...> wrote: > On Wed, Oct 24, 2012 at 5:02 PM, Stefan Richter > <st...@s5...> wrote: >>> On Oct 23 Carl Karsten wrote: >>> > Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC >>> > 2012 x86_64 x86_64 x86_64 GNU/Linux >>> [...] >>> > sudo ./async-loop-ck >>> [...] >>> > after about a min.. >>> > >>> > stack dump on the console, but I still have an ssh session running. >>> > >>> > top line of console: >>> > unable to handle kernel NULL pointer dereference at 00000000000000690 >> >> Carl sent screenshots. I uploaded them to: >> https://bugzilla.kernel.org/show_bug.cgi?id=49491 >> https://bugzilla.kernel.org/attachment.cgi?id=84731 >> https://bugzilla.kernel.org/attachment.cgi?id=84741 >> >> The call trace is: >> in page_waitqueue+06e/0x90 >> unlock_page+0x1d/0x40 >> filemap_fault+0x3ba/0x3e0 >> __do_fault+0x72/0x550 >> ? rb_insert_color+0x110/0x150 >> handle_pte_fault+0xfa0x200 >> ? cpumask_any_but+0x2d/0x40 >> handle_mm_fault+0x1f8/0x350 >> do_page_fault+0x150/0x520 >> ? mprotect_fixup+0x17d/0x2b0 >> ? sys_mprotect+0x1f0/0x250 >> page_fault+0x25/0x30 >> >> Carl, is this rare or frequent? > > Can't say. It has happened once. But I have only run > ./async-loop-ck maybe 10 times. sometimes it has 'hung' and I ^Ced it. > > > -- > Carl K > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |
From: Carl K. <ca...@pe...> - 2012-10-24 22:23:49
|
On Wed, Oct 24, 2012 at 5:02 PM, Stefan Richter <st...@s5...> wrote: >> On Oct 23 Carl Karsten wrote: >> > Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC >> > 2012 x86_64 x86_64 x86_64 GNU/Linux >> [...] >> > sudo ./async-loop-ck >> [...] >> > after about a min.. >> > >> > stack dump on the console, but I still have an ssh session running. >> > >> > top line of console: >> > unable to handle kernel NULL pointer dereference at 00000000000000690 > > Carl sent screenshots. I uploaded them to: > https://bugzilla.kernel.org/show_bug.cgi?id=49491 > https://bugzilla.kernel.org/attachment.cgi?id=84731 > https://bugzilla.kernel.org/attachment.cgi?id=84741 > > The call trace is: > in page_waitqueue+06e/0x90 > unlock_page+0x1d/0x40 > filemap_fault+0x3ba/0x3e0 > __do_fault+0x72/0x550 > ? rb_insert_color+0x110/0x150 > handle_pte_fault+0xfa0x200 > ? cpumask_any_but+0x2d/0x40 > handle_mm_fault+0x1f8/0x350 > do_page_fault+0x150/0x520 > ? mprotect_fixup+0x17d/0x2b0 > ? sys_mprotect+0x1f0/0x250 > page_fault+0x25/0x30 > > Carl, is this rare or frequent? Can't say. It has happened once. But I have only run ./async-loop-ck maybe 10 times. sometimes it has 'hung' and I ^Ced it. -- Carl K |
From: Stefan R. <st...@s5...> - 2012-10-24 22:02:18
|
> On Oct 23 Carl Karsten wrote: > > Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC > > 2012 x86_64 x86_64 x86_64 GNU/Linux > [...] > > sudo ./async-loop-ck > [...] > > after about a min.. > > > > stack dump on the console, but I still have an ssh session running. > > > > top line of console: > > unable to handle kernel NULL pointer dereference at 00000000000000690 Carl sent screenshots. I uploaded them to: https://bugzilla.kernel.org/show_bug.cgi?id=49491 https://bugzilla.kernel.org/attachment.cgi?id=84731 https://bugzilla.kernel.org/attachment.cgi?id=84741 The call trace is: in page_waitqueue+06e/0x90 unlock_page+0x1d/0x40 filemap_fault+0x3ba/0x3e0 __do_fault+0x72/0x550 ? rb_insert_color+0x110/0x150 handle_pte_fault+0xfa0x200 ? cpumask_any_but+0x2d/0x40 handle_mm_fault+0x1f8/0x350 do_page_fault+0x150/0x520 ? mprotect_fixup+0x17d/0x2b0 ? sys_mprotect+0x1f0/0x250 page_fault+0x25/0x30 Carl, is this rare or frequent? -- Stefan Richter -=====-===-- =-=- ==--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-10-24 06:40:28
|
On Oct 23 Carl Karsten wrote: > Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC > 2012 x86_64 x86_64 x86_64 GNU/Linux [...] > sudo ./async-loop-ck [...] > after about a min.. > > stack dump on the console, but I still have an ssh session running. > > top line of console: > unable to handle kernel NULL pointer dereference at 00000000000000690 > (not sure how many 0's, and I hope I don't need to transcribe the > whole screen..) If possible, take a digital photograph and upload it somewhere (e.g. bugzilla.kernel.org) or send it to me and I attach it at bugzilla. -- Stefan Richter -=====-===-- =-=- ==--- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2012-10-24 02:01:01
|
model name : Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz cpu MHz : 3200.000 /sys/bus/firewire/devices/fw0 0x001e8c00004166f5 /sys/bus/firewire/devices/fw1 0x0011066600000566 /sys/bus/firewire/devices/fw2 0x001e8c00004166f5 /sys/bus/firewire/devices/fw3 0x0011066600000566 Linux cnt2 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux System manufacturer System Version System Product Name Description: Ubuntu 12.04 LTS Codename: precise juser@cnt2:~$ lspci |grep 1394 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) juser@cnt2:~/fwdiag-cleanup$ ./async-loop-ck 0 firewire device nodes found. Four device nodes are required to operate. (Each physical firewire device should have two device nodes. One for sending, one for receiving.) juser@cnt2:~/fwdiag-cleanup$ sudo !! sudo ./async-loop-ck [sudo] password for juser: 0, node_id: 65473, local_node_id: 65473, devices[ 0 ]->receiveDescriptor: /dev/fw0 1, node_id: 65472, local_node_id: 65472, devices[ 1 ]->receiveDescriptor: /dev/fw1 2, node_id: 65473, local_node_id: 65472, devices[ 1 ]->sendDescriptor: /dev/fw2 3, node_id: 65472, local_node_id: 65473, devices[ 0 ]->sendDescriptor: /dev/fw3 Main process: starting receiver Main: receiver started, pid: 2195; waiting 4 seconds... Receiver child process 2195 starting... Main process: starting sender Main: sender started, pid: 2196 Main process, waiting for child processes to finish... Sender child process 2196 starting... after about a min.. stack dump on the console, but I still have an ssh session running. top line of console: unable to handle kernel NULL pointer dereference at 00000000000000690 (not sure how many 0's, and I hope I don't need to transcribe the whole screen..) -- Carl K |
From: Carl K. <ca...@pe...> - 2012-10-23 17:24:16
|
On Tue, Oct 23, 2012 at 6:28 AM, Clemens Ladisch <cl...@la...> wrote: > Carl Karsten wrote: >> A friend is helping me by coding up a diagnostic tool. It is meant to >> test firewire hardware. We don't have a baseline to know the quality >> of the hardware we are testing, so we are not sure if the results are >> due to faulty hardware or faulty code or we just don't know how to >> interpret the results. >> >> Main process: starting receiver >> Main: receiver started, pid: 11109; waiting 4 seconds... >> Receiver child process 11109 starting... >> unexpected packet: 0x7cf2c >> unexpected packet: 0x7cf2d >> unexpected packet: 0x7cf2e >> unexpected packet: 0x7cf2f >> unexpected packet: 0x7cf30 >> unexpected packet: 0x7cf31 >> unexpected packet: 0x7cf32 >> unexpected packet: 0x7cf33 >> unexpected packet: 0x7cf34 >> unexpected packet: 0x7cf35 >> unexpected packet: 0x7cf36 >> unexpected packet: 0x7cf37 >> unexpected packet: 0x7cf38 >> unexpected packet: 0x7cf39 >> Main process: starting sender > > This looks as if there are some leftover packets from the last run. > In theory, this should not be possible because received packets that > are not handled by anybody get thrown away immediately. > >> And sometimes it gets stuck: >> >> Sender child process 11517 starting... >> send error: 0x10 > > 0x10 is RCODE_SEND_ERROR, and usually means that the sending queue is > full. However, the test program takes care to queue less packets than > that, so in this case it might indicate that the controller thinks it > still has some left-over packets (which might be the same problem as > the previous one). > > It's possible to get such errors when multiple senders are run > simultaneously, but assuming that this is not the case, this looks > rather like a hardware error. > > Please name names (i.e., the chip). > Hewlett-Packard F.06 HP EliteBook 8530w Linux pc9d 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Description: Ubuntu 11.10 Onboard chip: /sys/bus/firewire/devices/fw0 0x5566778811223344 (yes. that really is the GUD, which I have found on quite a few HPs.) 86:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 06) pcie card in the slot /sys/bus/firewire/devices/fw1 0x01020304000003d8 05:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200A IEEE-1394a-2000 Controller (PHY/Link) (rev 01) -- Carl K |
From: Clemens L. <cl...@la...> - 2012-10-23 11:45:56
|
Carl Karsten wrote: > A friend is helping me by coding up a diagnostic tool. It is meant to > test firewire hardware. We don't have a baseline to know the quality > of the hardware we are testing, so we are not sure if the results are > due to faulty hardware or faulty code or we just don't know how to > interpret the results. > > Main process: starting receiver > Main: receiver started, pid: 11109; waiting 4 seconds... > Receiver child process 11109 starting... > unexpected packet: 0x7cf2c > unexpected packet: 0x7cf2d > unexpected packet: 0x7cf2e > unexpected packet: 0x7cf2f > unexpected packet: 0x7cf30 > unexpected packet: 0x7cf31 > unexpected packet: 0x7cf32 > unexpected packet: 0x7cf33 > unexpected packet: 0x7cf34 > unexpected packet: 0x7cf35 > unexpected packet: 0x7cf36 > unexpected packet: 0x7cf37 > unexpected packet: 0x7cf38 > unexpected packet: 0x7cf39 > Main process: starting sender This looks as if there are some leftover packets from the last run. In theory, this should not be possible because received packets that are not handled by anybody get thrown away immediately. > And sometimes it gets stuck: > > Sender child process 11517 starting... > send error: 0x10 0x10 is RCODE_SEND_ERROR, and usually means that the sending queue is full. However, the test program takes care to queue less packets than that, so in this case it might indicate that the controller thinks it still has some left-over packets (which might be the same problem as the previous one). It's possible to get such errors when multiple senders are run simultaneously, but assuming that this is not the case, this looks rather like a hardware error. Please name names (i.e., the chip). Regards, Clemens |
From: eviljoel <evi...@li...> - 2012-10-23 04:19:09
|
Hey All, I'm the guy currently working on this code. I can't really say I'm the author because it is based on some code that another guy wrote who based it off of a udev test (or something like that). But I'm also here to answer any questions you might have for me. Thanks, eviljoel On Mon, Oct 22, 2012 at 10:40 AM, Carl Karsten <ca...@pe...> wrote: > A friend is helping me by coding up a diagnostic tool. It is meant to > test firewire hardware. We don't have a baseline to know the quality > of the hardware we are testing, so we are not sure if the results are > due to faulty hardware or faulty code or we just don't know how to > interpret the results. > > Could someone help review this? > > https://gitorious.org/~eviljoel/cfk_misc/fwdiag-cleanup/ > > 1 box with 2 controllers, cable between the 2, here is what the > results look like: > > ************************************ > (veyepar)juser@pc9d:~/fwdiag-cleanup$ sudo ./async-loop-ck > 0, node_id: 65473, local_node_id: 65473, devices[ 0 > ]->receiveDescriptor: /dev/fw0 > 1, node_id: 65472, local_node_id: 65472, devices[ 1 > ]->receiveDescriptor: /dev/fw1 > 2, node_id: 65472, local_node_id: 65473, devices[ 0 ]->sendDescriptor: /dev/fw2 > 3, node_id: 65473, local_node_id: 65472, devices[ 1 ]->sendDescriptor: /dev/fw3 > Main process: starting receiver > Main: receiver started, pid: 11107; waiting 4 seconds... > Receiver child process 11107 starting... > Main process: starting sender > Main: sender started, pid: 11108 > Main process, waiting for child processes to finish... > Sender child process 11108 starting... > > Received 524289389 bytes = 500.00 MB in 511745 packets in 21 seconds > ...receiver finished > > Sent 524288119 bytes = 500.00 MB in 511753 packets in 21 seconds > ...sender finished > Main: processes finished > > Main process: starting receiver > Main: receiver started, pid: 11109; waiting 4 seconds... > Receiver child process 11109 starting... > unexpected packet: 0x7cf2c > unexpected packet: 0x7cf2d > unexpected packet: 0x7cf2e > unexpected packet: 0x7cf2f > unexpected packet: 0x7cf30 > unexpected packet: 0x7cf31 > unexpected packet: 0x7cf32 > unexpected packet: 0x7cf33 > unexpected packet: 0x7cf34 > unexpected packet: 0x7cf35 > unexpected packet: 0x7cf36 > unexpected packet: 0x7cf37 > unexpected packet: 0x7cf38 > unexpected packet: 0x7cf39 > Main process: starting sender > Main: sender started, pid: 11110 > Main process, waiting for child processes to finish... > Sender child process 11110 starting... > > Received 524289257 bytes = 500.00 MB in 511746 packets in 32 seconds > ...receiver finished > > Sent 524288119 bytes = 500.00 MB in 511753 packets in 28 seconds > ...sender finished > Main: processes finished > ************************************ > > And sometimes it gets stuck: > > ************************************ > (veyepar)juser@pc9d:~/fwdiag-cleanup$ sudo ./async-loop-ck > 0, node_id: 65472, local_node_id: 65472, devices[ 0 > ]->receiveDescriptor: /dev/fw0 > 1, node_id: 65473, local_node_id: 65473, devices[ 1 > ]->receiveDescriptor: /dev/fw1 > 2, node_id: 65472, local_node_id: 65473, devices[ 1 ]->sendDescriptor: /dev/fw2 > 3, node_id: 65473, local_node_id: 65472, devices[ 0 ]->sendDescriptor: /dev/fw3 > Main process: starting receiver > Main: receiver started, pid: 11516; waiting 4 seconds... > Receiver child process 11516 starting... > Main process: starting sender > Main: sender started, pid: 11517 > Main process, waiting for child processes to finish... > Sender child process 11517 starting... > send error: 0x10 > ************************************ > > -- > Carl K > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |