1.74. kernel

The Intel i350 Gigabit Network adapters failed to pass traffic in SR-IOV (Single Root I/O Virtualization) mode because multiple RX queues were being used, which the hardware does not support in this mode. With this update, the number of RX queues is now limited to one if SR-IOV gets enabled.

Previously, link power down could not be used. The code for it was already in place but was disabled. With this update, link power down has been enabled in the code and works as expected.

In some cases, a client skipped issuing a COMMIT call to the server when it determined that it will need to do another such call in the near future. Consequently, the NFS code failed to re-mark the inode as dirty, and the VFS file system failed to issue the call on the next pass. The inode had pages that needed to be cleaned but the inode itself was not marked as dirty. The kdump tuned writeback thresholds to a very low value in order to keep the page cache small. In this environment, the above bug often caused the client to become unresponsive when writing out the vmcore file. With this update, an upstream patch has been provided to address this issue and the hangs no longer occur.

The IDE error handling code uses the IDE interrupt handler and the general interrupt handler. This could lead to the erroneous execution of kexec/kdump code that was intended to only run at boot time. As a result, the asserted IDE IRQ line would be cleared without the interrupt being handled, which in turn caused the system to become unresponsive during the shut down of the kexec/kdump kernel. To fix this bug, a new test for the IRQ status, which should be IRQ_DISABLED, has been introduced to ensure that the code introduced for the kexec/kdump kernel only executes at boot time.

When the SMP (Symmetric Multi Processing) kernel ran the crash_kexec() function, the local Advanced Programmable Interrupt Controllers (APICs) could have pending interrupt requests (IRQs) in their vector tables. If there was more than one pending IRQ within the same 32-bit word in the Local APIC (LAPIC) vector table registers, the I/O APIC subsystem would enter setup with pending interrupts left in the LAPIC, causing various degrees of malfunctioning depending on the stuck interrupt vector. This update adds the MAX_LOOPS parameter to limit number of iterations and to provide enough time for the pending IRQs to be cleared if the loop was to lock-up for whatever reason, thus fixing this bug.

Previously, the domain_update_iommu_coherency() function set domains, by default, as coherent when the domain was not attached to any input/output memory management units (IOMMUs). Consequently, such a domain could update context entries non-coherently via the domain_context_mapping_one() function. To resolve this issue, domain_update_iommu_coherency() has been updated to use the safer default value and domains not attached to any IOMMU are now set as non-coherent.

If management firmware is present and a device is down, the firmware assumes control of the phy register. Previously, phy access was allowed from the host and it collided with firmware phy accesses, resulting in unpredictable behavior such as BMC (Baseboard Management Controller) LAN link being lost over time. With this update, the bug is fixed in the tg3 driver by only allowing phy accesses while the driver has control of the device.

In certain circumstances, the evdev_pass_event() function with a spinlock attached was interrupted and called again, eventually resulting in a deadlock. A patch has been provided to address this issue by disabling interrupts when the spinlock is obtained. This prevents the deadlock from occurring.

The unsolicited frame control infrastructure requires a table of DMA addresses for the hardware to look up the frame buffer location by an index. The hardware expects the elements of this table to be 64-bit quantities. Previously, the dma_addr_t parameter was wrongly used to reference these elements. Consequently, all unsolicited frame protocols were affected, particularly SATA-PIO and SMP, which prevented direct-attached SATA drives and expander-attached drives from being discovered. A patch has been provided to address this issue and SATA drives are now recognized correctly on 32-bit platforms.

A previous patch introduced with BZ#732775 had the following unintended consequence: if no poll method was defined for files in the /proc/ directory, processes could become unresponsive while they were reading files from this directory. This update restores the default poll behaviour for files in /proc/ that do not have any poll method defined, thus fixing this bug.

Note that procfs files are not real files and unless they may specifically produce more data after a time (such as /proc/kmsg), they should not be polled for more data as some of them cannot be polled for reading. For the most part, all the data they can produce are instantly available.

When directories mounted on a server are rearranged, they may then nest in a different order and clients may become unable to see or reassign the directories properly. Previously, the __d_unalias() and __d_materialise_dentry() functions did not provide loop prevention. As a consequence, NFS threads sometimes became unresponsive upon encountering a loop in the dentry tree. To fix this bug, this update adds additional loop checks and if a process tries to access a dentry that would otherwise cause the kernel to complete the loop, the ELOOP error code is returned and a message is logged.

With this update, the latest cciss driver has been provided, which adds support for new HP Smart Array controllers.