Re: Problems in 3.3.x with via VT6315

On Wed, May 09, 2012 at 08:21:29AM +0200, Clemens Ladisch wrote:
> Lluís Batlle i Rossell wrote:
> > # lsfirewirephy
> > timeout
> > timeout
> 
> (This should work directly after booting, before any hang.)

Yes, they work fine.

> All these symptoms indicate that the FireWire interrupt just isn't reported
> anymore.

Ok.

> > I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset,
> > same kernel, but in the phenomII it hangs (any of the two cameras we have,
> > colour and mono), and in the i7 not.
> 
> So this is probably not related with the VT6315 itself but with the system's
> interrupt routing.  Sometimes, this is caused by ACPI problems; try updating
> the BIOS, if possible.

I run the latest BIOS available two weeks ago. I wanted to get k8-powernow, and
hence updated the bios. But I really did not notice any change other than the
'nicer' bios configuration and boot screens.

I also run the latest microcode in the cpu. :)

> What is the entire output of dmesg immediately after booting?  What are the

Problems in 3.3.x with via VT6315

Hello,

here we have two computers, both with VT6315, running all x86_64, one is an
intel i7 and the other an amd Phenom II.

The I7 runs 2.6.35 and dc1394 cameras work perfectly in it.
The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang.
Then the process hangs too. Killing the process leaves it <defunct> (unrelated
to the parent accepting it or not). Using the same userland software in both
computers.

I can't test 3.3.4 on the I7 easily, but I imagine something could have got
broken for the VT6315 since 2.6.35.

Can anyone confirm that VT6315 works in 3.3.x kernels?

Regards,
Lluís.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

PCIe card recommendation

I need to buy 20 or so PCIe firewire 400 cards.  (10 machines, 2 cards
each, or 1 card with 2 bus/chips - I need to plug in 2 dv video
devices)

Has anyone shopped around recently?

Are there any I should avoid?

--

-- 
Carl K

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Multiple file descriptors and ISO receive contexts

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Multi-channel receive

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

Changes to the FireWire kernel drivers in Linux 3.3

Hi all,

Linux 3.3 has been released on Sunday.  This time there were only two
small changes to the FireWire drivers.

firewire-ohci:
  - Add workaround for the 1394 part of Creative SoundBlaster Audigy
    in order to fix transaction failures.
  - Fix random malfunctions of Ricoh PCI Express 1394 controllers by
    disabling MSI (message signaled interrupts).

These changes were also backmerged into kernel 3.2.6 and 3.0.21.  In
kernel 3.0.25, two forgotten older fixes from the 3.1 release were
backmerged (fix for recognition of some old camcorders; 32 bit userspace on
64 bit kernel compatibility fix).

Loosely related to FireWire (but also USB, SATA, and other interconnects):
Just last week between 3.3-rc7 and 3.3 final, some fixes for kernel
crashes at hot unplug of storage devices were committed.  E.g. an infamous
bug with card readers has been addressed.  Nevertheless I suspect that the
hunt for hot-unplug related bugs in and around the kernel's block layer is
not yet over.

Since there is so little to say about the FireWire kernel drivers, I use
this post to also remind of some library updates:
  - libraw1394 v2.0.8 on 2012-02-19 with bug fixes and performance
    improvement,
  - libdc1394 v2.2.0 on 2012-03-06 with bug fixes on Linux and with new
    Windows platform support,
  - ongoing libffado fixes and improvements in the FFADO development
    repository, without formal release yet.
--

-- 
Stefan Richter
-=====-===-- --== =-=--
http://arcgraph.de/sr/

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

Unable to access firewire hard drive

System: Slackware64-13.37
Kernel: 3.2.2
Libraw1394 2.0.7

# lspci | grep FireWire
01:06.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 04)

# lsmod | grep firewire
firewire_sbp2          10977  0 
firewire_ohci          26284  0 
firewire_core          41461  2 firewire_sbp2,firewire_ohci
crc_itu_t               1185  2 udf,firewire_core

#dmesg
firewire_core: created device fw1: GUID 0050770e00071002, S400, 3 config ROM 
retries
firewire_core: phy config: card 0, new root=ffc0, gap_count=5
scsi5 : SBP-2 IEEE-1394
firewire_sbp2: Workarounds for fw1.0: 0x20 (firmware_revision 0x012804, model_id 
0x000001)
firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries)
scsi 5:0:0:0: Direct-Access-RBC ST316002 2ACE                  PQ: 0 ANSI: 4
sd 5:0:0:0: Attached scsi generic sg4 type 14
sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB)
sd 5:0:0:0: [sdd] Write Protect is off
sd 5:0:0:0: [sdd] Mode Sense: 11 00 00 00
sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdd: sdd1
sd 5:0:0:0: [sdd] Attached SCSI disk

The device is a hard drive caddy with both USB and FireWire ports, and 
contains an NTFS formatted drive.

Under Windoze, the drive functions perfectly as either USB or FireWire (ie 
this is not a hardware fault!)

Under Slackware, when connected as USB, the drive is immediately recognised, 
and a prompt appears on the desktop asking if I want to mount it. If I accept, 
it is mounted as /media/Video (the partition label).

If I connect it as Firewire, although the kernel appears to recognise it (see 
demsg above), no prompt to mount it appears. Attempting to mount it manually 
creates an eror message saying it can't identify the filing system. Specifying 
ntfs-3g produces a "wrong super-block" error.

Examining the disk with GParted indicates that the disk contains only 
"unallocated" space, when attached via FireWire!

In other words, although the disk works fine under Windows, and under Linux as 
USB, it doesn't work under FireWire, as the system is unable to identify the 
partition, although it knows it exists!

I haven't used this caddy for a while, but it used to work perfectly under the 
old FireWire stack. (I was unaware that there was a new stack until I started 
trying to debug this problem!)

I am not a programmer, though I would claim to be "computer literate". This 
may be an error on my part, but if so it is not obvious to me. Googling for 
solutions to this issue has produced a number of hits for Ubuntu users with 
the same problem, but no apparent solution!

Is anyone here able to offer advice or enlightenment, please?

Cheers,

--

-- 
Pete
christy <at> attglobal.net

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

Problem using raw1394_iso_recv_init() - the irq_interval parameter

Hi,

I seem to have a strange problem with the irq_interval parameter of 
raw1394_iso_recv_init().
It seems to have an upper limit of 512. Is that possible ?

If I set it to higher values than that, I still get the callback after 512 
packets have arrived.
>From looking at the libraw1394 2.0.7 sources I don't see anything like this.

This is on a Slackware 13.37, kernel 2.6.37.6, 32bit x86, juju stack, OHCI 
driver.

Before I was using much smaller values, so I'm not sure whether this is 
something new or not.

Thanks
Alex

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

libraw1394 and libiec61883 tarballs back on kernel.org

Hi all,

it took longer than necessary, but now the source release tarballs of
libraw1394 v0.5...v2.0.7 and libiec61883 v1.0.0...v1.2.0 are finally
available at their former place at kernel.org again:

    ftp://ftp.kernel.org/pub/linux/libs/ieee1394/
    http://www.kernel.org/pub/linux/libs/ieee1394/
    https://www.kernel.org/pub/linux/libs/ieee1394/

There is a general change of policies and processes at kernel.org:
Uploaded files are no longer gpg-signed by a daemon at kernel.org but by
the person who uploaded them.  Only signatures for the original *.tar files
are installed at kernel.org.  This means that you first need to uncompress
a downloaded file before you can verify its authenticity, e.g.:

    $ wget ftp://ftp.kernel.org/pub/linux/libs/ieee1394/libiec61883-1.2.0.tar.{xz,sign}
    $ xz -d libiec61883-1.2.0.tar.xz
    $ gpg --verify libiec61883-1.2.0.tar.sign

The tarballs at above URLs are the same as the ones that were there before
the kernel.org break-in last year, i.e. I did not generate new ones.  I did
not have own backups of all of them though; I had to collect some of them
from stale kernel.org FTP mirrors.  I verified their contents against git
checkouts of the respective versions though.

A pro pos:
  - Since wiki.kernel.org is still read-only, and with it the ToDo list of
    ieee1394.wiki.kernel.org, I entered the open issues of libraw1394 at
    https://redmine.user.in-berlin.de/projects/libraw1394/issues now.
    This one is read-only for you all too, so just post any issue reports
    to the mailing list.  Or better yet, post patches. 
  - libraw1394.git is still only two commits ahead of v2.0.7, but I should
    get a v2.0.8 release out sooner than later (with the usual loose
    semantics of "soon").
  - As before, libiec61883 is maintained by Dan; I am just his proxy for
    file upload to kernel.org.
--

-- 
Stefan Richter
-=====-===-- ---= ---==
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

Re: fw drive in 11.10 [solved]

On Sun, Jan 1, 2012 at 11:04 PM, Carl Karsten <carl <at> personnelware.com> wrote:
> On Sun, Jan 1, 2012 at 9:50 PM, Carl Karsten <carl <at> personnelware.com> wrote:
>> when I plug in a firewire drive, this is all I see in dmesg:
>>
>> [10518.283056] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
>> [10518.807684] firewire_core: created device fw1: GUID 00203702003442f7, S400
>>
>> If I boot the same box a live 10.04 all is fine.
>>
>> If I boot 11.10, plug in dv cam, kino, camera stream shows fine.
>>

modprobe firewire-sbp2

I wonder what was sposed to load that - like something in the hot plug system?

Doesn't solve the esata, but that isn't this lists problem :)

--

-- 
Carl K

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

fw drive in 11.10

when I plug in a firewire drive, this is all I see in dmesg:

[10518.283056] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
[10518.807684] firewire_core: created device fw1: GUID 00203702003442f7, S400

If I boot the same box a live 10.04 all is fine.

If I boot 11.10, plug in dv cam, kino, camera stream shows fine.

-
Carl K

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox