Skip to content

L
linux
Switch branch/tag
  1. 13 Mar, 2008 7 commits
    • Stefan Richter's avatar
      firewire: update Kconfig help text · 0a8da30d
      Stefan Richter authored 
      Remove some less necessary information, point out that video1394 and
dv1394 should be blacklisted along with ohci1394.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      0a8da30d
    • Stefan Richter's avatar
      firewire: warn on fatal condition in topology code · a2cdebe3
      Stefan Richter authored 
      If this ever happens to anybody, we want to have it in his log.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      a2cdebe3
    • Jarod Wilson's avatar
      firewire: fw-sbp2: set single-phase retry_limit · 51f9dbef
      Jarod Wilson authored 
      Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).

Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).

Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.

The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).

Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: default avatarJarod Wilson <jwilson@redhat.com>
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      51f9dbef
    • Stefan Richter's avatar
      firewire: fw-ohci: Apple UniNorth 1st generation support · 11bf20ad
      Stefan Richter authored 
      Mostly copied from ohci1394.c.  Necessary for some older Macs, e.g.
PowerBook G3 Pismo and early PowerBook G4 Titanium.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      11bf20ad
    • Stefan Richter's avatar
      firewire: fw-ohci: PPC PMac platform code · ea8d006b
      Stefan Richter authored 
      Copied from ohci1394.c.  This code is necessary to prevent machine check
exceptions when reloading or resuming the driver.

Tested on a 1st generation PowerBook G4 Titanium, which also needs the
pci_probe() hunk.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>

I was able to reproduce the system exception on resume with a 3rd-gen
Titanium PowerBook G4 667, and this patch does let the system resume
successfully now.

Not quite clear if there was possibly an updated version coming using
pci_enable_device() instead of the pair of pmac_call_feature() calls,
but either way, this is a definite must-have, at least for older ppc
macs -- my Aluminum PowerBook G4/1.67 suspends and resumes without this
patch just fine.
Signed-off-by: default avatarJarod Wilson <jwilson@redhat.com>
Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ea8d006b
    • Stefan Richter's avatar
      firewire: endianess annotations · efbf390a
      Stefan Richter authored 
      Kills warnings from 'make C=1 CHECKFLAGS="-D__CHECK_ENDIAN__" modules':

drivers/firewire/fw-transaction.c:771:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.c:771:10:    expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.c:771:10:    got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.h:93:10:    expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10:    got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-ohci.c:1490:8: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1490:35: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1516:5: warning: cast to restricted type
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: default avatarJarod Wilson <jwilson@redhat.com>
      efbf390a
    • Stefan Richter's avatar
      firewire: endianess fix · 25df287d
      Stefan Richter authored 
      The generation of incoming requests was filled in in wrong byte order on
machines with big endian CPU.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: default avatarJarod Wilson <jwilson@redhat.com>
      25df287d
  3. 10 Mar, 2008 2 commits
  5. 09 Mar, 2008 8 commits
  7. 08 Mar, 2008 3 commits
    • Roland McGrath's avatar
      Fix waitid si_code regression · 6efcae46
      Roland McGrath authored 
      In commit ee7c82da ("wait_task_stopped:
simplify and fix races with SIGCONT/SIGKILL/untrace"), the magic (short)
cast when storing si_code was lost in wait_task_stopped.  This leaks the
in-kernel CLD_* values that do not match what userland expects.
Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6efcae46
    • Herbert Xu's avatar
      [CRYPTO] skcipher: Fix section mismatches · f13ba2f7
      Herbert Xu authored 
      The previous patch to move chainiv and eseqiv into blkcipher created
a section mismatch for the chainiv exit function which was also called
from __init.  This patch removes the __exit marking on it.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f13ba2f7
    • Roland McGrath's avatar
      x86_64: make ptrace always sign-extend orig_ax to 64 bits · 84c6f604
      Roland McGrath authored 
      This makes 64-bit ptrace calls setting the 64-bit orig_ax field for a
32-bit task sign-extend the low 32 bits up to 64.  This matches what a
64-bit debugger expects when tracing a 32-bit task.

This follows on my "x86_64 ia32 syscall restart fix".  This didn't
matter until that was fixed.

The debugger ignores or zeros the high half of every register slot it
sets (including the orig_rax pseudo-register) uniformly.  It expects
that the setting of the low 32 bits always has the same meaning as a
32-bit debugger setting those same 32 bits with native 32-bit
facilities.

This never arose before because the syscall restart check never
matched any -ERESTART* values due to lack of sign extension.  Before
that fix, even 32-bit ptrace setting orig_eax to -1 failed to trigger
the restart check anyway.  So this was never noticed as a regression
of 64-bit debuggers vs 32-bit debuggers on the same 64-bit kernel.
Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
[ Changed to just do the sign-extension unconditionally on x86-64,
  since orig_ax is always just a small integer and doesn't need
  the full 64-bit range ]
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      84c6f604
  9. 07 Mar, 2008 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7