Tilman Schmidt [Fri, 26 Jan 2007 08:56:56 +0000 (00:56 -0800)]
[PATCH] Gigaset ISDN driver error handling fixes
Fix several flaws in the error handling of the Siemens Gigaset ISDN driver,
including one that would cause an Oops when connecting more than one device
of the same type.
Ingo Molnar [Fri, 26 Jan 2007 08:56:55 +0000 (00:56 -0800)]
[PATCH] ACPI: fix cpufreq regression
Recently cpufreq support on my laptop (Lenovo T60) broke completely: when
it's plugged into AC it would never go higher than 1 GHz - neither 1.3 GHz
nor 1.83 GHz is possible - no matter which governor (userspace, speed or
ondemand) is used.
After some cpufreq debugging i tracked the regression back to the following
(totally correct) bug-fix commit:
[PATCH] Correct bound checking from the value returned from _PPC method.
This bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.
The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.
My laptop (Lenovo T60) has the following performance states supported:
Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.
now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:
And this is the point where my laptop's BIOS returns the incorrect value of
'2'. Note that it has not sent any notification event, so the value is
probably not really intentional (possibly spurious), and Windows likely
doesnt query it after bootup either. Maybe the value is kept at '2'
normally, and is only set to the real value when a true asynchronous event
(such as AC plug event, battery switch, etc.) occurs.
So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info() call,
but only evaluate it if _PPC is present during CPU object init, or if it's
notified during an asynchronous event. This change is more permissive than
the previous logic, so it definitely shouldnt break any existing system.
This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!
Atsushi Nemoto [Fri, 26 Jan 2007 08:56:54 +0000 (00:56 -0800)]
[PATCH] SPI: alternative fix for spi_busnum_to_master
If a SPI master device exists, udev (udevtrigger) causes kernel crash, due
to wrong kobj pointer in kobject_uevent_env(). This problem was not in
2.6.19.
The backtrace (on MIPS) was:
[<8024db6c>] kobject_uevent_env+0x54c/0x5e8
[<802a8264>] store_uevent+0x1c/0x3c (in drivers/class.c)
[<801cb14c>] subsys_attr_store+0x2c/0x50
[<801cb80c>] flush_write_buffer+0x38/0x5c
[<801cb900>] sysfs_write_file+0xd0/0x190
[<80181444>] vfs_write+0xc4/0x1a0
[<80181cdc>] sys_write+0x54/0xa0
[<8010dae4>] stack_done+0x20/0x3c
flush_write_buffer() passes kobject of spi_master_class.subsys to
subsys_addr_store(), then subsys_addr_store() passes a pointer to a struct
subsystem to store_uevent() which expects a pointer to a struct
class_device. The problem seems subsys_attr_store() called instead of
class_device_attr_store().
This mismatch was caused by commit 3bd0f6943520e459659d10f3282285e43d3990f1, which overrides kset of master
class. This made spi_master_class.subsys.kset.ktype NULL so
subsys_sysfs_ops is used instead of class_dev_sysfs_ops.
The commit was to fix spi_busnum_to_master(). Here is a patch fixes
this function in other way, just searching children list of
class_device.
Roland McGrath [Fri, 26 Jan 2007 08:56:52 +0000 (00:56 -0800)]
[PATCH] x86_64 ia32 vDSO: define arch_vma_name
This patch makes x86_64 define arch_vma_name for CONFIG_IA32_EMULATION. This
makes the ia32 vDSO mapping appear in /proc/PID/maps with "[vdso]" for ia32
processes, as it does on native i386.
Roland McGrath [Fri, 26 Jan 2007 08:56:50 +0000 (00:56 -0800)]
[PATCH] x86_64 ia32 vDSO: use VM_ALWAYSDUMP
This patch fixes ia32 core dumps on x86_64 to include just one phdr for the
vDSO vma. Currently it writes a confused format with two phdrs for the
address, one without contents and one with. This patch removes the
special-case core writing macros for the ia32 vDSO. Instead, it uses
VM_ALWAYSDUMP in the vma. This changes core dumps so they no longer include
the non-PT_LOAD phdrs from the vDSO, consistent with fixed native i386 core
dumps.
Roland McGrath [Fri, 26 Jan 2007 08:56:49 +0000 (00:56 -0800)]
[PATCH] i386 vDSO: use VM_ALWAYSDUMP
This patch fixes core dumps to include the vDSO vma, which is left out now.
It removes the special-case core writing macros, which were not doing the
right thing for the vDSO vma anyway. Instead, it uses VM_ALWAYSDUMP in the
vma; there is no need for the fixmap page to be installed. It handles the
CONFIG_COMPAT_VDSO case by making elf_core_dump use the fake vma from
get_gate_vma after real vmas in the same way the /proc/PID/maps code does.
This changes core dumps so they no longer include the non-PT_LOAD phdrs from
the vDSO. I made the change to add them in the first place, but in turned out
that nothing ever wanted them there since the advent of NT_AUXV. It's cleaner
to leave them out, and just let the phdrs inside the vDSO image speak for
themselves.
Roland McGrath [Fri, 26 Jan 2007 08:56:48 +0000 (00:56 -0800)]
[PATCH] Add VM_ALWAYSDUMP
This patch adds the VM_ALWAYSDUMP flag for vm_flags in vm_area_struct. This
provides a clean explicit way to have a vma always included in core dumps, as
is needed for vDSO's.
Roland McGrath [Fri, 26 Jan 2007 08:56:47 +0000 (00:56 -0800)]
[PATCH] Fix gate_vma.vm_flags
This patch fixes the initialization of gate_vma.vm_flags and
gate_vma.vm_page_prot to reflect reality. This makes the "[vdso]" line in
/proc/PID/maps correctly show r-xp instead of ---p, when gate_vma is used
(CONFIG_COMPAT_VDSO on i386).
Roland McGrath [Fri, 26 Jan 2007 08:56:46 +0000 (00:56 -0800)]
[PATCH] Fix CONFIG_COMPAT_VDSO
I wouldn't mind if CONFIG_COMPAT_VDSO went away entirely. But if it's there,
it should work properly. Currently it's quite haphazard: both real vma and
fixmap are mapped, both are put in the two different AT_* slots, sysenter
returns to the vma address rather than the fixmap address, and core dumps yet
are another story.
This patch makes CONFIG_COMPAT_VDSO disable the real vma and use the fixmap
area consistently. This makes it actually compatible with what the old vdso
implementation did.
Justin Clacherty [Fri, 26 Jan 2007 08:56:44 +0000 (00:56 -0800)]
[PATCH] spi: fix error setting the spi mode in pxa2xx_spi.c
Currently the spi mode can be set to the wrong mode if you are switching
from any mode other than mode 0. This is because the mode is set using a
bitwise or on uncleared bits. The following patch clears the mode bits
before setting the new mode. I've also modified it to use the appropriate
defines from pxa-regs.h for readability.
Joerg Roedel [Fri, 26 Jan 2007 08:56:42 +0000 (00:56 -0800)]
[PATCH] KVM: SVM: Propagate cpu shutdown events to userspace
This patch implements forwarding of SHUTDOWN intercepts from the guest on to
userspace on AMD SVM. A SHUTDOWN event occurs when the guest produces a
triple fault (e.g. on reboot). This also fixes the bug that a guest reboot
actually causes a host reboot under some circumstances.
Avi Kivity [Fri, 26 Jan 2007 08:56:41 +0000 (00:56 -0800)]
[PATCH] KVM: MMU: Report nx faults to the guest
With the recent guest page fault change, we perform access checks on our
own instead of relying on the cpu. This means we have to perform the nx
checks as well.
Software like the google toolbar on windows appears to rely on this
somehow.
Avi Kivity [Fri, 26 Jan 2007 08:56:41 +0000 (00:56 -0800)]
[PATCH] KVM: MMU: Perform access checks in walk_addr()
Check pte permission bits in walk_addr(), instead of scattering the checks all
over the code. This has the following benefits:
1. We no longer set the accessed bit for accessed which fail permission checks.
2. Setting the accessed bit is simplified.
3. Under some circumstances, we used to pretend a page fault was fixed when
it would actually fail the access checks. This caused an unnecessary
vmexit.
4. The error code for guest page faults is now correct.
The fix helps netbsd further along booting, and allows kvm to pass the new mmu
testsuite.
Leonard Norrgard [Fri, 26 Jan 2007 08:56:38 +0000 (00:56 -0800)]
[PATCH] KVM: SVM: Fix SVM idt confusion
There's an obvious typo in svm_{get,set}_idt, causing it to access the ldt
instead.
Because these functions are only called for save/load on AMD, the bug does not
impact normal operation. With the fix, save/load works as expected on AMD
hosts.
Linus Torvalds [Fri, 26 Jan 2007 20:53:20 +0000 (12:53 -0800)]
Write back inode data pages even when the inode itself is locked
In __writeback_single_inode(), when we find a locked inode and we're not
doing a data-integrity sync, we used to just skip writing entirely,
since we didn't want to wait for the inode to unlock.
However, there's really no reason to skip writing the data pages, which
are likely to be the the bulk of the dirty state anyway (and the main
reason why writeback was started for the non-data-integrity case, of
course!)
Linus Torvalds [Fri, 26 Jan 2007 20:47:06 +0000 (12:47 -0800)]
Resurrect 'try_to_free_buffers()' VM hackery
It's not pretty, but it appears that ext3 with data=journal will clean
pages without ever actually telling the VM that they are clean. This,
in turn, will result in the VM (and balance_dirty_pages() in particular)
to never realize that the pages got cleaned, and wait forever for an
event that already happened.
Technically, this seems to be a problem with ext3 itself, but it used to
be hidden by 'try_to_free_buffers()' noticing this situation on its own,
and just working around the filesystem problem.
This commit re-instates that hack, in order to avoid a regression for
the 2.6.20 release. This fixes bugzilla 7844:
http://bugzilla.kernel.org/show_bug.cgi?id=7844
Peter Zijlstra points out that we should probably retain the debugging
code that this removes from cancel_dirty_page(), and I agree, but for
the imminent release we might as well just silence the warning too
(since it's not a new bug: anything that triggers that warning has been
around forever).
Patrick McHardy [Fri, 26 Jan 2007 09:07:59 +0000 (01:07 -0800)]
[NETFILTER]: nf_conntrack_pptp: fix NAT setup of expected GRE connections
When an expected connection arrives, the NAT helper should be called to
set up NAT similar to the master connection. The PPTP conntrack helper
incorrectly checks whether the _expected_ connection has NAT setup before
calling the NAT helper (which is never the case), instead of checkeing
whether the _master_ connection is NATed.
Patrick McHardy [Fri, 26 Jan 2007 09:07:30 +0000 (01:07 -0800)]
[NETFILTER]: nf_nat_pptp: fix expectation removal
When removing the expectation for the opposite direction, the PPTP NAT
helper initializes the tuple for lookup with the addresses of the
opposite direction, which makes the lookup fail.
Patrick McHardy [Fri, 26 Jan 2007 09:06:47 +0000 (01:06 -0800)]
[NETFILTER]: nf_nat: fix ICMP translation with statically linked conntrack
When nf_nat/nf_conntrack_ipv4 are linked statically, nf_nat is initialized
before nf_conntrack_ipv4, which makes the nf_ct_l3proto_find_get(AF_INET)
call during nf_nat initialization return the generic l3proto instead of
the AF_INET specific one. This breaks ICMP error translation since the
generic protocol always initializes the IPs in the tuple to 0.
Change the linking order and put nf_conntrack_ipv4 first.
We can't elide the skb_set_owner_w() here because things like certain
netfilter targets (such as owner MATCH) need a socket to be set on the
SKB for correct operation.
Thanks to Jan Engelhardt and other netfilter list members for
pointing this out.
Roland McGrath [Fri, 26 Jan 2007 01:19:51 +0000 (17:19 -0800)]
[PATCH] x86_64: fix put_user for 64-bit constant
On x86-64, a put_user call using a 64-bit pointer and a constant value that
is > 0xffffffff will produce code that doesn't assemble. This patch fixes
the asm construct to use the Z constraint for 32-bit constants.
[DECNET]: Handle a failure in neigh_parms_alloc (take 2)
While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong. So handle the
failure.
Michael Chan [Thu, 25 Jan 2007 23:49:56 +0000 (15:49 -0800)]
[BNX2]: Fix 2nd port's MAC address.
On the 5709, we need to add the proper offset to calculate the shared
memory base address of the 2nd port correctly. Otherwise, the 2nd
port's MAC address and other information will be the same as the 1st
port.
Tejun Heo [Thu, 25 Jan 2007 10:40:05 +0000 (19:40 +0900)]
libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli
Some uli controllers have stuck SIMPLEX bit which can't be cleared
with ata_pci_clear_simplex(), but the controller is capable of doing
DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX
which makes libata ignore the simplex bit and use it in sata_uli.
Tejun Heo [Thu, 25 Jan 2007 10:16:28 +0000 (19:16 +0900)]
ahci: improve and limit spurious interrupt messages, take#3
We're still seeing a lot of issues with NCQ implementation in drive
firmwares. Sprious FISes during NCQ command phase occur on many
drives and some of them seem potentially dangerous (at least to me).
Until we find the solution, spurious messages can give us more info.
Improve and limit them such that more info can be reported while not
disturbing users too much.
Tejun Heo [Thu, 25 Jan 2007 11:46:59 +0000 (20:46 +0900)]
sata_via: don't diddle with ATA_NIEN in ->freeze
vt6420 completely loses its ability to raise IRQ for ATAPI devices if
ATA_NIEN is diddled with in ->freeze. Further investigation is
necessary to determine whether this problem is shared on other
controllers but it doesn't seem to be at this point.
Make vt6420's ->freeze only clear IRQ to fix this problem. This makes
vt6420 relatively more prone to IRQ storms but the controller is way
too braindamaged to worry about that anyway.
Baruch Even [Thu, 25 Jan 2007 21:35:06 +0000 (13:35 -0800)]
[TCP]: Fix sorting of SACK blocks.
The sorting of SACK blocks actually munges them rather than sort,
causing the TCP stack to ignore some SACK information and breaking the
assumption of ordered SACK blocks after sorting.
The sort takes the data from a second buffer which isn't moved causing
subsequent data moves to occur from the wrong location. The fix is to
use a temporary buffer as a normal sort does.
Jiri Kosina [Tue, 23 Jan 2007 13:02:53 +0000 (14:02 +0100)]
USB HID: fix hid_blacklist clash for 0x08ca/0x0010
commit d8c8a393166d6283003fb111d0b4a40931c0eda4 introduced a clash in
hid_blacklist for 0x08ca/0x0010 (GTCO vs. AIPTEK). As the vendor of
GTCO device doesn't seem to be interested in supporting their legacy
HW with this conflicting ids, it is OK to remove it.
Catalin Marinas [Wed, 24 Jan 2007 17:47:08 +0000 (18:47 +0100)]
[ARM] 4111/1: Allow VFP to work with thread migration on SMP
The current lazy saving of the VFP registers is no longer possible
with thread migration on SMP. This patch implements a per-CPU
vfp-state pointer and the saving of the VFP registers at every context
switch. The registers restoring is still performed in a lazy way.
Catalin Marinas [Thu, 25 Jan 2007 13:16:47 +0000 (14:16 +0100)]
[ARM] 4112/1: Only ioremap to supersections if DOMAIN_IO is zero
Supersections do not have a field for the domain and it is always
0. This patch prevents the creation of supersections during ioremap
when DOMAIN_IO is not zero (i.e. !defined(CONFIG_IO_36)).
sk_run_filter() returns either 0 or an unsigned 32-bit
length which says how much of the packet to retain.
If that 32-bit unsigned integer is larger than the packet,
this is fine we just leave the packet unchanged.
The above commit caused all filter return values which
were negative when interpreted as a signed integer to
indicate a packet drop, which is wrong.
Based upon a report and initial patch by Raivis Bucis.
[IPV4]: Fix the fib trie iterator to work with a single entry routing tables
In a kernel with trie routing enabled I had a simple routing setup
with only a single route to the outside world and no default
route. "ip route table list main" showed my the route just fine but
/proc/net/route was an empty file. What was going on?
Thinking it was a bug in something I did and I looked deeper. Eventually
I setup a second route and everything looked correct, huh? Finally I
realized that the it was just the iterator pair in fib_trie_get_first,
fib_trie_get_next just could not handle a routing table with a single entry.
So to save myself and others further confusion, here is a simple fix for
the fib proc iterator so it works even when there is only a single route
in a routing table.
Linus Torvalds [Wed, 24 Jan 2007 20:31:28 +0000 (12:31 -0800)]
Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] Fix wrong checksum calculation on 64-bit MIPS
[MIPS] VPE loader: Initialize lists before they're actually being used ...
[MIPS] Fix reported amount of freed memory - it's in kB not bytes
[MIPS] vr41xx: need one more nop with mtc0_tlbw_hazard()
[MIPS] SMTC: Fix module build by exporting symbol
[MIPS] SMTC: Fix TLB sizing bug for TLB of 64 >= entries
[MIPS] Fix APM build
[MIPS] There is no __GNUC_MAJOR__
The problem is the commit replaces some unsigned long with __be32. On
64bit MIPS, a __be32 (i.e. unsigned int) value is represented as a
sign-extented 32-bit value in a 64-bit argument register. So the
address 192.168.0.1 (0xc0a80001) is passed as 0xffffffffc0a80001 to
csum_tcpudp_nofold() but the asm code in the function expects
0x00000000c0a80001, therefore it returns a wrong checksum. Explicit
cast to unsigned long is needed to drop high 32bit.
Ralf Baechle [Wed, 24 Jan 2007 19:13:08 +0000 (19:13 +0000)]
[MIPS] VPE loader: Initialize lists before they're actually being used ...
kspd which due to makefile order happens to be initialized before the
vpe loader causes references to vpecontrol lists before they're actually
been initialized.
Alexey Dobriyan [Tue, 23 Jan 2007 18:30:14 +0000 (21:30 +0300)]
[MIPS] There is no __GNUC_MAJOR__
Gcc major version number is in __GNUC__. As side effect fix checking
with sparse if sparse was built with gcc 4.1 and mips cross-compiler
is 3.4.
Sparse will inherit version 4.1, __GNUC__ won't be filtered from
"-dM -E -xc" output, sparse will pick only new major, effectively becoming
gcc version 3.1 which is unsupported.
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
[CIFS] Fix oops when Windows server sent bad domain name null terminator
[CIFS] cifs sprintf fix
[CIFS] Remove 2 unneeded kzalloc casts
[CIFS] Update CIFS version number
Linus Walleij [Sun, 21 Jan 2007 19:08:33 +0000 (20:08 +0100)]
[ARM] 4102/1: Allow for PHYS_OFFSET on any valid 2MiB address
This patchs allows the offset to the first page of
physical memory to be on any 2MB boundary
whereas the previous code could only handle psysical
offset to any 16MB boundary (0xNN000000) or any 1MB
boundary below 0x01000000 (e.g. 0x00N00000). The
problem is a consequence of the orr one-byte syntax,
so we fix this and we can place the first bank of
memory at 0x28e00000. I have also included an explicit
check that disallow compilation when PHYS_OFFSET is
not on a 2MiB boundary. head.S would be the proper place
to have this at since this is the first file that
attempts to use PHYS_OFFSET during compile.
Russell King [Mon, 22 Jan 2007 18:59:42 +0000 (18:59 +0000)]
[ARM] Fix AMBA serial drivers for non-first serial ports
Using console=ttyAM1 or console=ttyAMA1 resulted in an oops during
boot due to trying to drive the console before that port had been
registered. Fix this by checking whether the port is present before
allowing console setup to proceed.
Ben Dooks [Tue, 16 Jan 2007 11:56:58 +0000 (12:56 +0100)]
[ARM] 4096/1: S3C24XX: change return code form s3c2410_gpio_getcfg()
The s3c2410_gpio_getcfg() currently returns
a value which is dependant on the GPIO no
passed in. Now we have more generic constants
it is sensible to use those as return codes
so that any function dealing with >1 GPIO
does not need to do it's own number processing.
Since this function is only currently used in
pm.c, it is easy to fixup (and correct pm.c
to use the generic constants)
Pavel Pisa [Fri, 12 Jan 2007 08:57:22 +0000 (09:57 +0100)]
[ARM] 4092/1: i.MX/MX1 CPU Frequency scaling latency definition
The transition latency has to be defined and reasonably
small to allow on-demand and conservative governors.
The value has been defined according to manual.
The imx_set_target() protected against seen out of range
requests now.
Andrew Victor [Tue, 9 Jan 2007 12:47:29 +0000 (13:47 +0100)]
[ARM] 4089/1: AT91: GPIO wake IRQ cleanup
Cleanup of at91 platform level gpio wake and suspend/resume logic.
The GPIO core now delegates wakeups to the parent AIC by refcounting,
and delegates clock management to the clock API. This makes these
system modules more independent of each other, which is cleaner and will
also help with the AT91SAM9263 (where some GPIO controllers share the
same irq and clock).
Brian King [Wed, 17 Jan 2007 18:32:12 +0000 (12:32 -0600)]
libata: Fixup n_elem initialization
Fixup the inialization of qc->n_elem. It currently gets
initialized to 1 for commands that do not transfer any data.
Fix this by initializing n_elem to 0 and only setting to 1
in ata_scsi_qc_new when there is data to transfer. This fixes
some problems seen with SATA devices attached to ipr adapters.
Tejun Heo [Sat, 20 Jan 2007 17:10:11 +0000 (02:10 +0900)]
ahci: don't enter slumber on power down
Some ATA/ATAPI devices act weirdly after the link is put into slumber
mode. Some hang completely requiring physical power removal while
others fail to wake up till the link is hardreset a couple of times.
The addition of slumber on power down was never driven by real need.
It just followed what ahci spec said literally. The spec itself seems
faulty in that it doesn't consider devices (not controllers) which
don't support link powersaving mode.
Theory never matches reality when it comes to dark allys of cheap
ATA/ATAPI world. It's just unrealistic to expect vendors to test
rarely used link powersaving feature rigorously. This patch makes
ahci more friendly to the coldness of reality.
This shouldn't have any negative effect - when suspend operation
succeeds, we power off the whole machine; otherwise, we wake up
everything. I can't see any reason to be so elaborate with powering
down the link in the first place.
Robert Hancock [Wed, 24 Jan 2007 02:09:02 +0000 (20:09 -0600)]
sata_nv: don't rely on NV_INT_DEV indication with ADMA
Several people reported issues with certain drive commands timing out on
sata_nv controllers running in ADMA mode. The commands in question were
non-DMA-mapped commands, usually FLUSH CACHE or FLUSH CACHE EXT.
From experimentation it appears that the NV_INT_DEV indication isn't
always set when a legitimate command completion interrupt is received on
a legacy-mode command, at least not on these controllers in ADMA mode.
When a command is pending on the port, force the flag on always in the
irq_stat value before calling nv_host_intr so that the drive busy state
is always checked by ata_host_intr.
This also fixes some questionable code in nv_host_intr which called
ata_check_status when a command was pending and ata_host_intr returned
"unhandled". If the device interrupted at just the wrong time this could
cause interrupts to be lost.
Tejun Heo [Tue, 23 Jan 2007 06:13:39 +0000 (15:13 +0900)]
ahci: make ULi M5288 ignore interface fatal error bit
As with JMicron controllers, ULi M5288 sets interface fatal error bit
on device error including ATAPI CC. This makes libata hardreset the
port on ATAPI CC thus making it impossible to use. Ignore interface
fatal error bit on ULi M5288. This fixes bugzilla bug #7837.
[IP] TUNNEL: Fix to be built with user application.
include/linux/if_tunnel.h is broken for user application
because it was changed to use __be32 which is required
to include linux/types.h in advance but didn't.
(This issue is found when building MIPL2 daemon. We are not sure this
is the last header to be fixed about __be32.)
Jarek Poplawski [Wed, 24 Jan 2007 06:07:12 +0000 (22:07 -0800)]
[TCP]: rare bad TCP checksum with 2.6.19
The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE"
changed to unconditional copying of ip_summed field from collapsed
skb. This patch reverts this change.
The majority of substantial work including heavy testing
and diagnosing by: Michael Tokarev <[email protected]>
Possible reasons pointed by: Herbert Xu and Patrick McHardy.
Patrick McHardy [Wed, 24 Jan 2007 06:00:13 +0000 (22:00 -0800)]
[NETFILTER]: Fix iptables ABI breakage on (at least) CRIS
With the introduction of x_tables we accidentally broke compatibility
by defining IPT_TABLE_MAXNAMELEN to XT_FUNCTION_MAXNAMELEN instead of
XT_TABLE_MAXNAMELEN, which is two bytes larger.
On most architectures it doesn't really matter since we don't have
any tables with names that long in the kernel and the structure
layout didn't change because of alignment requirements of following
members. On CRIS however (and other architectures that don't align
data) this changed the structure layout and thus broke compatibility
with old iptables binaries.
Changing it back will break compatibility with binaries compiled
against recent kernels again, but since the breakage has only been
there for three releases this seems like the better choice.
I encountered a kernel panic with my test program, which is a very
simple IPv6 client-server program.
The server side sets IPV6_RECVPKTINFO on a listening socket, and the
client side just sends a message to the server. Then the kernel panic
occurs on the server. (If you need the test program, please let me
know. I can provide it.)
This problem happens because a skb is forcibly freed in
tcp_rcv_state_process().
When a socket in listening state(TCP_LISTEN) receives a syn packet,
then tcp_v6_conn_request() will be called from
tcp_rcv_state_process(). If the tcp_v6_conn_request() successfully
returns, the skb would be discarded by __kfree_skb().
However, in case of a listening socket which was already set
IPV6_RECVPKTINFO, an address of the skb will be stored in
treq->pktopts and a ref count of the skb will be incremented in
tcp_v6_conn_request(). But, even if the skb is still in use, the skb
will be freed. Then someone still using the freed skb will cause the
kernel panic.
I suggest to use kfree_skb() instead of __kfree_skb().
Herbert Xu [Wed, 17 Jan 2007 00:52:02 +0000 (16:52 -0800)]
[IPSEC]: Policy list disorder
The recent hashing introduced an off-by-one bug in policy list insertion.
Instead of adding after the last entry with a lesser or equal priority,
we're adding after the successor of that entry.
This patch fixes this and also adds a warning if we detect a duplicate
entry in the policy list. This should never happen due to this if clause.
Since we stop using dev_alloc_skb on the IrDA TX frame, we constantly run
into the case of the skb headroom being 0, and thus we call skb_cow for
every IrDA TX frame.
This patch uses a local buffer and memcpy the skb to it, saving us a
kmalloc for each of those IrDA TX frames.
Vlad Yasevich [Tue, 16 Jan 2007 03:20:21 +0000 (19:20 -0800)]
[SCTP]: Fix SACK sequence during shutdown
Currently, when association enters SHUTDOWN state,the
implementation will SACK any DATA first and then transmit
the SHUTDOWN chunk. This is against the order required by
2960bis spec. SHUTDOWN must always be first, followed by
SACK. This change forces this order and also enables bundling.
projects / linux.git / log