Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 10 12月, 2008 3 次提交
    • S
      firewire: fw-ohci: fix IOMMU resource exhaustion · 1d1dc5e8
      由 Stefan Richter 提交于 
      There is a DMA map/ unmap imbalance whenever a block write request
packet is sent and then dequeued with ohci_cancel_packet.  The latter
may happen frequently if the AR resp tasklet is executed before the AT
req tasklet for the same transaction.

Add the missing dma_unmap_single.  This fixes
https://bugzilla.redhat.com/show_bug.cgi?id=475156

Reported-by: Emmanuel Kowalski
Tested-by: Emmanuel Kowalski
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      1d1dc5e8
    • N
      ieee1394: node manager causes up to ~3.25s delay in freezing tasks · ec9a13cd
      由 Nigel Cunningham 提交于 
      The firewire nodemanager function "nodemgr_host_thread" contains a loop
that calls try_to_freeze near the top of the loop, but then delays for
up to 3.25 seconds (plus time to do work) before getting back to the top
of the loop. When starting a cycle post-boot, this doesn't seem to bite,
but it is causing a noticeable delay at boot time, when freezing
processes prior to starting to read the image.

The following patch adds invocation of try_to_freeze to the subloops
that are used in the body of this function. With these additions, the
time to freeze when starting to resume at boot time is virtually zero.
I'm no expert on firewire, and so don't know that we shouldn't check
the return value and jump back to the top of the loop or such like after
being frozen, but I submit it for your consideration.
Signed-off-by: NNigel Cunningham <nigel@tuxonice.net>

The delay until nodemgr freezes was up to 0.25s (plus time for node
probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
2.6.28-rc1, hence much more noticeable.

try_to_freeze() without any jump is correct.  The surrounding code in
the respective loops will catch whether another bus reset happens during
the freeze and handle it.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ec9a13cd
    • B
      radeonfb: Disable new color expand acceleration unless explicitely enabled · f3179748
      由 Benjamin Herrenschmidt 提交于 
      This new color expansion acceleration for radeonfb appears to trigger
problems with X on VT switch and suspend/resume on some machines. It
might be a problem in the VT layer or in X, but I haven't quite found
it yet, so in the meantime, this disables the acceleration by default,
reverting to 2.6.27 state. It can be enabled using the "accel_cexp"
module parameter or fbdev argument.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f3179748
  3. 09 12月, 2008 10 次提交
  5. 06 12月, 2008 4 次提交
  7. 05 12月, 2008 4 次提交
  9. 04 12月, 2008 16 次提交
  11. 03 12月, 2008 3 次提交
    • M
      block: fix setting of max_segment_size and seg_boundary mask · 0e435ac2
      由 Milan Broz 提交于 
      Fix setting of max_segment_size and seg_boundary mask for stacked md/dm
devices.

When stacking devices (LVM over MD over SCSI) some of the request queue
parameters are not set up correctly in some cases by default, namely
max_segment_size and and seg_boundary mask.

If you create MD device over SCSI, these attributes are zeroed.

Problem become when there is over this mapping next device-mapper mapping
- queue attributes are set in DM this way:

request_queue   max_segment_size  seg_boundary_mask
SCSI                65536             0xffffffff
MD RAID1                0                      0
LVM                 65536                 -1 (64bit)

Unfortunately bio_add_page (resp.  bio_phys_segments) calculates number of
physical segments according to these parameters.

During the generic_make_request() is segment cout recalculated and can
increase bio->bi_phys_segments count over the allowed limit.  (After
bio_clone() in stack operation.)

Thi is specially problem in CCISS driver, where it produce OOPS here

    BUG_ON(creq->nr_phys_segments > MAXSGENTRIES);

(MAXSEGENTRIES is 31 by default.)

Sometimes even this command is enough to cause oops:

  dd iflag=direct if=/dev/<vg>/<lv> of=/dev/null bs=128000 count=10

This command generates bios with 250 sectors, allocated in 32 4k-pages
(last page uses only 1024 bytes).

For LVM layer, it allocates bio with 31 segments (still OK for CCISS),
unfortunatelly on lower layer it is recalculated to 32 segments and this
violates CCISS restriction and triggers BUG_ON().

The patch tries to fix it by:

 * initializing attributes above in queue request constructor
   blk_queue_make_request()

 * make sure that blk_queue_stack_limits() inherits setting

 (DM uses its own function to set the limits because it
 blk_queue_stack_limits() was introduced later.  It should probably switch
 to use generic stack limit function too.)

 * sets the default seg_boundary value in one place (blkdev.h)

 * use this mask as default in DM (instead of -1, which differs in 64bit)

Bugs related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=471639
http://bugzilla.kernel.org/show_bug.cgi?id=8672Signed-off-by: NMilan Broz <mbroz@redhat.com>
Reviewed-by: NAlasdair G Kergon <agk@redhat.com>
Cc: Neil Brown <neilb@suse.de>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Mike Miller <mike.miller@hp.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      0e435ac2
    • D
      [MTD] [NAND] fix OOPS accessing flash operations over STM flash on PXA · e93f1be5
      由 Denis V. Lunev 提交于 
      STM 2Gb flash is a large-page NAND flash.  Set operations accordingly.
This field is dereferenced without a check in several places resulting in
OOPS.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Acked-by: NEric Miao <ymiao3@marvell.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      e93f1be5
    • M
      bnx2: Add workaround to handle missed MSI. · efba0180
      由 Michael Chan 提交于 
      The bnx2 chips do not support per MSI vector masking.  On 5706/5708, new MSI
address/data are stored only when the MSI enable bit is toggled.  As a result,
SMP affinity no longer works in the latest kernel.  A more serious problem is
that the driver will no longer receive interrupts when the MSI receiving CPU
goes offline.

The workaround in this patch only addresses the problem of CPU going offline.
When that happens, the driver's timer function will detect that it is making
no forward progress on pending interrupt events and will recover from it.

Eric Dumazet reported the problem.

We also found that if an interrupt is internally asserted while MSI and INTA
are disabled, the chip will end up in the same state after MSI is re-enabled.
The same workaround is needed for this problem. 
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Tested-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efba0180