linux-kernel - Re: [git pull] FireWire fixes

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

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

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

Message-ID: <1284764773.2804.7.camel@maxim-laptop>
Date:	Sat, 18 Sep 2010 01:06:13 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [git pull] FireWire fixes

On Fri, 2010-09-17 at 14:47 +0200, Stefan Richter wrote: 
> Linus, please pull from the for-linus branch at
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus
> 
> to receive a hardware quirk entry and a small makefile correction.
> Thanks.
> 
> Heikki Lindholm (1):
>       firewire: ohci: activate cycle timer register quirk on Ricoh chips
That did it, the strange oops I had with new firewire stack is gone.
(I have the Ricoh chip in the laptop)


However the new stack is still very much unusable:

Running new stack on the laptop + old stack on the desktop gave me about
18-30 Mbit/s speeds varying all the time.
Running both with the new stack results in corrupted packets and sftp
exits immediately.

The problems I so hoped to be fixed in new stack still persist:

Cable disconection/reconnection still results in the link loss till
ifconfig down/up.

Suspend/resume also results in the link loss.

Driver still has panics on some occasions.

Best regards,
Maxim Levitsky




> 
> Stefan Richter (1):
>       firewire: nosy: fix build when CONFIG_FIREWIRE=N
> 
>  drivers/Makefile        |    2 +-
>  drivers/firewire/ohci.c |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> 
> Full log and diff:
> 
> commit 8702d33aa6e6d753ef99163afe48aba1323374ef
> Author: Stefan Richter <stefanr@...6.in-berlin.de>
> Date:   Wed Sep 15 13:02:44 2010 +0200
> 
>     firewire: nosy: fix build when CONFIG_FIREWIRE=N
>     
>     drivers/firewire/nosy* is a stand-alone driver that does not depend on
>     CONFIG_FIREWIRE.  Hence let make descend into drivers/firewire/ also
>     if that option is off.
>     
>     The stand-alone driver drivers/ieee1394/init_ohci1394_dma*  will soon be
>     moved into drivers/firewire/ too and will require the same makefile fix.
>     
>     Side effect:
>     As mentioned in https://bugzilla.novell.com/show_bug.cgi?id=586172#c24
>     this influences the order in which either firewire-ohci or ohci1394 is
>     going to be bound to an OHCI-1394 controller in case of a modular build
>     of both drivers if no modprobe blacklist entries are configured.
>     However, a user of such a setup cannot expect deterministic behavior
>     anyway.  The Kconfig help and the migration guide at
>     ieee1394.wiki.kernel.org recommend blacklist entries when a dual
>     IEEE 1394 stack build is being used.  (The coexistence period of the two
>     stacks is planned to end soon.)
>     
>     Cc: Michal Marek <mmarek@...e.cz>
>     Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 91874e0..0bbb456 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -50,7 +50,7 @@ obj-$(CONFIG_SPI)		+= spi/
>  obj-y				+= net/
>  obj-$(CONFIG_ATM)		+= atm/
>  obj-$(CONFIG_FUSION)		+= message/
> -obj-$(CONFIG_FIREWIRE)		+= firewire/
> +obj-y				+= firewire/
>  obj-y				+= ieee1394/
>  obj-$(CONFIG_UIO)		+= uio/
>  obj-y				+= cdrom/
> 
> commit 970f4be85ae6ecf97b711a3a2a1d5cecd3ea0534
> Author: Heikki Lindholm <holin@....fi>
> Date:   Mon Sep 6 22:30:45 2010 +0300
> 
>     firewire: ohci: activate cycle timer register quirk on Ricoh chips
>     
>     The Ricoh FireWire controllers appear to have the non-atomic cycle
>     timer register access bug, so, activate the driver workaround by
>     default.
>     
>     The behaviour was observed on:
>     Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] and
>     Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04).
>     
>     Signed-off-by: Heikki Lindholm <holin@....fi>
>     Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> 
> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
> index be29b0b..1b05896 100644
> --- a/drivers/firewire/ohci.c
> +++ b/drivers/firewire/ohci.c
> @@ -263,6 +263,7 @@ static const struct {
>  	{PCI_VENDOR_ID_JMICRON,	PCI_DEVICE_ID_JMICRON_JMB38X_FW, QUIRK_NO_MSI},
>  	{PCI_VENDOR_ID_NEC,	PCI_ANY_ID,	QUIRK_CYCLE_TIMER},
>  	{PCI_VENDOR_ID_VIA,	PCI_ANY_ID,	QUIRK_CYCLE_TIMER},
> +	{PCI_VENDOR_ID_RICOH,	PCI_ANY_ID,	QUIRK_CYCLE_TIMER},
>  	{PCI_VENDOR_ID_APPLE,	PCI_DEVICE_ID_APPLE_UNI_N_FW, QUIRK_BE_HEADERS},
>  };
>  
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/