- 28 Jan, 2009 3 commits
-
-
Stefan Richter authored
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3). Our previously too large limit doesn't matter though if the controller reports its max_receive correctly. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The hard-wired configuration of the top speed (until now S800) was unnecessary, remove it. If the local link layer controller supports S1600 or S3200, we now assume this speed for all present 1394b PHYs (except if they are behind 1394a repeaters) until nodemgr figured out the actual speed while fetching the config ROM. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 24 Jan, 2009 4 commits
-
-
Stefan Richter authored
This fixes a regression by "firewire: keep highlevel drivers attached during brief connection loss": There were 2 seconds unnecessary waiting added to the shutdown procedure of each controller. We use card->link as status flag to signal the device handler that there is no use to wait for a come-back. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . Tested-by: Mathias Beilstein Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . In a quick test with a JVC camcorder (which didn't malfunction like the reported camcorders), this change decreased the number of ack_busy_X from 16 in three runs of dvgrab to 4 in three runs of the same capture duration. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The present message is mostly just noise. We only need to be notified if the "active" flag does not go off before the retry loop terminates. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 20 Jan, 2009 3 commits
-
-
Stefan Richter authored
There are situations when nodes vanish from the bus and come back quickly thereafter: - When certain bus-powered hubs are plugged in, - when certain devices are plugged into 6-port hubs, - when certain disk enclosures are switched from self-power to bus power or vice versa and break the daisy chain during the transition, - when the user plugs a cable out and quickly plugs it back in, e.g. to reorder a daisy chain (works on Mac OS X if done quickly enough), - when certain hubs temporarily malfunction during high bus traffic. Until now, firewire-core reported affected nodes as lost to the highlevel drivers (firewire-sbp2 and userspace drivers). We now delay the destruction of device representations until after at least two seconds after the last bus reset. If a "new" device is detected in this period whose bus information block and root directory header match that of a device which is pending for deletion, we resurrect that device and send update calls to highlevel drivers. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Noticed by Jarod Wilson: The bus manager work was unnecessarily delayed each time the bus generation counter rolled over. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
-
Stefan Richter authored
The whole topology code only works if the old and new topologies which are compared come from immediately successive self ID complete events. If there happened bus resets without self ID complete events in the meantime, or self ID complete events with invalid selfIDs, the topology comparison could identify nodes wrongly, or more likely just corrupt kernel memory or panic right away. We now discard all nodes of the old topology and treat all current nodes as new ones if the current self ID generation is not the previous one plus 1. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
-
- 16 Jan, 2009 30 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (23 commits) ACPI PCI hotplug: harden against panic regression ACPI: rename main.c to sleep.c dell-laptop: move to drivers/platform/x86/ from drivers/misc/ eeepc-laptop: enable Bluetooth ACPI details ACPI: fix ACPI_FADT_S4_RTC_WAKE comment kprobes: check CONFIG_FREEZER instead of CONFIG_PM PM: Fix freezer compilation if PM_SLEEP is unset thermal fixup for broken BIOS which has invalid trip points. ACPI: EC: Don't trust ECDT tables from ASUS ACPI: EC: Limit workaround for ASUS notebooks even more ACPI: thinkpad-acpi: bump up version to 0.22 ACPI: thinkpad-acpi: handle HKEY event 6030 ACPI: thinkpad-acpi: clean-up fan subdriver quirk ACPI: thinkpad-acpi: start the event hunt season ACPI: thinkpad-acpi: handle HKEY thermal and battery alarms ACPI: thinkpad-acpi: clean up hotkey_notify() ACPI: thinkpad-acpi: use killable instead of interruptible mutexes ACPI: thinkpad-acpi: add UWB radio support ACPI: thinkpad-acpi: preserve radio state across shutdown ACPI: thinkpad-acpi: resume with radios disabled ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: netxen: include ipv6.h (fixes build failure) netxen: avoid invalid iounmap
-
James Bottomley authored
ACPI hotplug panic with current git head http://lkml.org/lkml/2009/1/10/136 Rather than reverting the entire commit that causes the crash: e8c331e9 "PCI hotplug: introduce functions for ACPI slot detection" simply harden against it while the changes to the hotplug code on this particularl machine are understood. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
Signed-off-by: Len Brown <len.brown@intel.com>
-
Jonathan McDowell authored
Although rfkill support for the EEE bluetooth device has been added to 2.6.28-rc the appropriate ACPI accessor definitions were not added, so the support was non functional. The patch below adds the get and set accessors and has been verified to work on an EEE 901. Signed-off-by: Jonathan McDowell <noodles@earth.li> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
-
David Brownell authored
Make the comment for ACPI_FADT_S4_RTC_WAKE match the ACPI spec; that bit has nothing to do with status bits. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Masami Hiramatsu authored
Check CONFIG_FREEZER instead of CONFIG_PM because kprobe booster depends on freeze_processes() and thaw_processes() when CONFIG_PREEMPT=y. This fixes a linkage error which occurs when CONFIG_PREEMPT=y, CONFIG_PM=y and CONFIG_FREEZER=n. Reported-by: Cheng Renquan <crquan@gmail.com> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Len Brown <len.brown@intel.com>
-
Rafael J. Wysocki authored
Freezer fails to compile if with the following configuration settings: CONFIG_CGROUPS=y CONFIG_CGROUP_FREEZER=y CONFIG_MODULES=y CONFIG_FREEZER=y CONFIG_PM=y CONFIG_PM_SLEEP=n Fix this by making process.o compilation depend on CONFIG_FREEZER. Reported-by: Cheng Renquan <crquan@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
-
Zhang Rui authored
ACPI thermal driver only re-evaluate VALID trip points. For the broken BIOS show in http://bugzilla.kernel.org/show_bug.cgi?id=8544 the active[0] is set to invalid at boot time and it will not be re-evaluated again. We can still get a single warning message at boot time. http://marc.info/?l=linux-kernel&m=120496222629983&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=12203 Signed-off-by: Zhang Rui<rui.zhang@intel.com> Tested-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Len Brown <len.brown@intel.com>
-
Dhananjay Phadke authored
Fixes a build error in absence of CONFIG_IPV6: drivers/net/netxen/netxen_nic_main.c:1189: error: implicit declaration of function 'ipv6_hdr' drivers/net/netxen/netxen_nic_main.c:1189: error: invalid type argument of '->' Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexey Starikovskiy authored
http://bugzilla.kernel.org/show_bug.cgi?id=9399 http://bugzilla.kernel.org/show_bug.cgi?id=11880Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
-
Dhananjay Phadke authored
For NX3031 only one I/O range is mapped, so unmapping other two which are used by older chips, causes this warning on ppc64. "Attempt to iounmap early bolted mapping at 0x0000000000000000" Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexey Starikovskiy authored
References: http://bugzilla.kernel.org/show_bug.cgi?id=11884Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstableLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable: Btrfs: fix ioctl arg size (userland incompatible change!) Btrfs: Clear the device->running_pending flag before bailing on congestion
-
Chris Mason authored
The structure used to send device in btrfs ioctl calls was not properly aligned, and so 32 bit ioctls would not work properly on 64 bit kernels. We could fix this with compat ioctls, but we're just one byte away and it doesn't make sense at this stage to carry about the compat ioctls forever at this stage in the project. This patch brings the ioctl arg up to an evenly aligned 4k. Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
Btrfs maintains a queue of async bio submissions so the checksumming threads don't have to wait on get_request_wait. In order to avoid extra wakeups, this code has a running_pending flag that is used to tell new submissions they don't need to wake the thread. When the threads notice congestion on a single device, they may decide to requeue the job and move on to other devices. This makes sure the running_pending flag is cleared before the job is requeued. It should help avoid IO stalls by making sure the task is woken up when new submissions come in. Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: serial: Add 16850 uart type support to OF uart driver hvc_console: Remove tty->low_latency powerpc: Get the number of SLBs from "slb-size" property powerpc: is_hugepage_only_range() must account for both 4kB and 64kB slices powerpc/ps3: printing fixups for l64 to ll64 conversion drivers/video powerpc/ps3: Printing fixups for l64 to ll64 conversion drivers/scsi powerpc/ps3: Printing fixups for l64 to ll64 conversion drivers/ps3 powerpc/ps3: Printing fixups for l64 to ll64 conversion sound/ppc powerpc/ps3: Printing fixups for l64 to ll64 conversion drivers/char powerpc/ps3: Printing fixups for l64 to ll64 conversion drivers/block powerpc/ps3: Printing fixups for l64 to ll64 conversion arch/powerpc powerpc/ps3: ps3_repository_read_mm_info() takes u64 * arguments powerpc/ps3: clear_bit()/set_bit() operate on unsigned longs powerpc/ps3: The lv1_ routines have u64 parameters powerpc/ps3: Use dma_addr_t down through the stack powerpc/ps3: set_dabr() takes an unsigned long powerpc: Cleanup from l64 to ll64 change drivers/scsi
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: sata_fsl: Return non-zero on error in probe() drivers/ata/pata_ali.c: s/isa_bridge/ali_isa_bridge/ to fix alpha build libata: New driver for OCTEON SOC Compact Flash interface (v7). libata: Add another column to the ata_timing table. sata_via: Add VT8261 support pata_atiixp: update port enabledness test handling [libata] get-identity ioctl: Fix use of invalid memory pointer
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] Skip deleted devices in __scsi_device_lookup_by_target() [SCSI] Add SUN Universal Xport to no attach blacklist [SCSI] iscsi_tcp: make padbuf non-static [SCSI] mpt fusion: Add Firmware debug support [SCSI] mpt fusion: Add separate msi enable disable for FC,SPI,SAS [SCSI] mpt fusion: Update MPI Headers to version 01.05.19 [SCSI] qla2xxx: Fix ISP restart bug in multiq code
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/i915: lock correct mutex around object unreference. drm/i915: add support for physical memory objects drm/i915: make LVDS fixed mode a preferred mode drm: handle depth & bpp changes correctly drm: initial KMS config fixes drm/i915: setup sarea properly in master_priv drm/i915: set vblank enabled flag correctly across IRQ install/uninstall drm/i915: don't enable vblanks on disabled pipes
-
Linus Torvalds authored
This reverts commit 98e6e286, as Yinghai Lu reports that it breaks kexec with at least the e1000 and e1000e drivers. The reason is that the shutdown sequence puts the hardware into D3 sleep, and the commit causes us to claim that it then is in D0 (running) state just because we don't understand the PM capabilities. Which then later makes "pci_set_power_state()" not do anything, and the device never wakes up properly and just returns 0xff to everything. Reported-by: Yinghai Lu <yinghai@kernel.org> Acked-by: From: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Michal Sojka authored
while I was looking over kernel sources I've found this small bug. Formerly, zero was returned even if an error happened. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Andrew Morton authored
drivers/ata/pata_ali.c:44: error: static declaration of 'isa_bridge' follows non-static declaration arch/alpha/include/asm/pci.h:274: error: previous declaration of 'isa_bridge' was here Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
David Daney authored
Cavium OCTEON processor support was recently merged, so now we have this CF driver for your consideration. Most OCTEON variants have *no* DMA or interrupt support on the CF interface so for these, only PIO is supported. Although if DMA is available, we do take advantage of it. Signed-off-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
David Daney authored
The forthcoming OCTEON SOC Compact Flash driver needs an additional timing value that was not available in the ata_timing table. I add a new column for dmack_hold time. The values were obtained from the Compact Flash specification Rev 4.1. Signed-off-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-