Davide Libenzi [Sat, 22 Nov 2003 00:39:48 +0000 (16:39 -0800)]
[PATCH] More SiS interrupt routing
It turns out that the SiS irq routing logic doesn't go by chipset
after all - it's just that some pirq entries are "legacy" numbers,
while others are raw offsets into PCI config space (and the legacy
numbers are more commonly used with the older chipsets, which
explains the correlations).
Adam Belay [Fri, 21 Nov 2003 11:36:07 +0000 (03:36 -0800)]
[PATCH] reserve resources specified by the PnPBIOS properly
A bug prevents the PnP layer from reserving some of the resources
specified by the PnPBIOS. As a result some systems will have
unpredicable (random crashes etc.) problems because of resource
conflicts, especially when PCMCIA support is enabled. This patch
fixes the problem by ensuring that the proper resource data is
reserved.
David Stevens [Fri, 21 Nov 2003 08:49:32 +0000 (00:49 -0800)]
[IPV6]: Fix header length calculation in multicast input.
It did not account for extension headers properly. If we get
this length wrong, we do not determine if a multicast packet
is MLDv1 vs. MLDv2 correctly.
David Mosberger [Fri, 21 Nov 2003 06:10:39 +0000 (22:10 -0800)]
ia64: Drop printk from ia64_ni_syscall(). This is a temporary fix
for 2.6.0. The proper fix is to replace ia64_ni_syscall with
sys_ni_syscall, but that would make the patch quite large, so
we defer that till 2.6.1.
David Mosberger [Fri, 21 Nov 2003 05:25:04 +0000 (21:25 -0800)]
ia64: Fix off-by-1 error in imm60 patching. The bug hasn't been observed
in practice, but it's clearly wrong and just waiting there to
get triggered...
David Stevens [Thu, 20 Nov 2003 08:34:18 +0000 (00:34 -0800)]
[IPV6]: In igmp6_group_queried, fix address check to comply with RFC2710.
RFC2710 says:
1) MLD messages are never sent for multicast addresses whose scope is 0
(reserved) or 1 (node-local).
2) MLD messages ARE sent for multicast addresses whose scope is 2
(link-local), including Solicited-Node multicast addersses [ADDR-ARCH],
except for the link-scope, all-nodes address (FF02::1).
The current MLDv1 code does not send reports for link-scope addresses
and doesn't restrict scope 0. This may break switches that snoop reports for
determining which ports should receive particular addresses. Patch below.
David S. Miller [Wed, 19 Nov 2003 12:50:27 +0000 (04:50 -0800)]
[SPARC64]: Get PCI floppies fully functional again.
EBUS DMA fixes:
- Add EBUS_DMA_FLAG_TCI_DISABLE that the client can set if it
wants only to hear device interrupts, not DMA complete ones.
- When initially resetting the EBUS DMA unit, put valid burst etc.
encodings in the CSR register. Not doing this appears to leave
the attached ISA device in a weird state.
PCI FLOPPY fixes:
- Do ebus_dma_enable() before ebus_dma_request()
- In sun_pci_fd_set_dma_mode() do not forget to set the direction.
- Set EBUS_DMA_FLAG_TCI_DISABLE in ebus_dma flags.
- Make sure that in error paths sun_fdc/FCD1 will be -1 (invalid).
Thanks to Soyoung Park for loaning her Ultra5 to me so I could fix this.
Andrew Morton [Tue, 18 Nov 2003 16:16:51 +0000 (08:16 -0800)]
[PATCH] mpparse printk fix
From: Herbert Xu <herbert@gondor.apana.org.au>
The recent patch produces a message with no terminating newline on the
machine in question. This is because one of the four bytes that you're
printing out is NUL. The following patch avoids that problem.
Andrew Morton [Tue, 18 Nov 2003 16:16:42 +0000 (08:16 -0800)]
[PATCH] resource.c bounds checking fix
From: Jeremy Higdon <jeremy@classic.engr.sgi.com>
I believe there is a bug in kernel/resource.c.
We (SGI sn2 I/O code) are using this for allocating dma map resources, and
we tracked failures we were seeing to find_resource().
The problem is that when testing bounds in the forever loop, the end bound
would be one higher than it should be if it gets set from another resource
(it's set to the proper value when it gets set from the root), causing
find_resource to return an invalid min/max when the requested size was one
greater than would fit between two existing resources.
Andrew Morton [Tue, 18 Nov 2003 16:16:33 +0000 (08:16 -0800)]
[PATCH] fs/ext[23]/xattr.c pointer arithmetic fix
From: Andreas Gruenbacher <agruen@suse.de>
64-bit pointer arithmetic bug in xattr code
The int offset is not enought to hold the difference between arbitraty
pointers on 64-bit machines. Compute the offset of here and last inside
HDR(bh) instead.
Andrew Morton [Tue, 18 Nov 2003 16:16:24 +0000 (08:16 -0800)]
[PATCH] cpu_sibling_map fix
From: James Cleverdon <jamesclv@us.ibm.com>
On summit-based machines the cpu_sibling_map data has been hosed for some
time. I found out why in Intel's IA-32 Software Deveveopers' Manual Vol 2
under CPUID. Looks like the value that cpuid returns is the one latched at
reset, and doesn't reflect any changes made by the BIOS later:
* Local APIC ID (high byte of EBX)--this number is the 8-bit ID that
is assigned to the local APIC on the processor during power up. This
field was introduced in the Pentium 4 processor.
Also, the code in init_intel was a bit overdesigned. Until Intel releases
a chip with a non-power-of-2 sibling count on it, there's no point in all
that bit bashing.
Andrew Morton [Tue, 18 Nov 2003 16:16:16 +0000 (08:16 -0800)]
[PATCH] init.h needs to include compiler.h
From: Jun Sun <jsun@mvista.com>
It is needed for all those "__attribute_used__" etc to be valid.
Also, it seems that when compiling a file ending in ".S", gcc-2.95.3 does not
expand __GNUC__ at all. This causes the compiler version check to fail when
building vsyscall.S. So add __ASSEMBLY__ wrappers in there.
Andrew Morton [Tue, 18 Nov 2003 16:16:07 +0000 (08:16 -0800)]
[PATCH] ext2 block allocator fixes
Fix a couple of problems which were introduced by a recent race fix in the
ext2 block allocator:
- if the allocation attempt raced, and lost the race then a new attempt is
made. But the earlier reservation must be put back first.
Add a call to group_release_blocks() to fix this.
- if the filesystem is genuinely corrupted then the code as-is can get
stuck in an infinite loop, thinking that a blockgroup has free blocks and
then discovering that its bitmap is full.
Fix this by baling out after having scanned all blockgroups twice.
(Thanks Muli Ben-Yehuda <mulix@mulix.org> for spotting this).
Andrew Morton [Tue, 18 Nov 2003 16:15:53 +0000 (08:15 -0800)]
[PATCH] ext3_new_inode fixlet
From: Alex Tomas <alex@clusterfs.com>
If the ext3 inode allocator tries to claim an inode and fails because
another CPU got in there first it will then advance onto the next
blockgroup and try again.
Change it to advance onto the next inode within the same blockgroup
instead.
Andrew Morton [Tue, 18 Nov 2003 16:15:35 +0000 (08:15 -0800)]
[PATCH] fix percpu_counter_mod linkage problem
If both ext2 and ext3 are built as modules there is nothing to pull
percpu_counter_mod() into the kernel build and the ext2 and ext3 modules do
not load.
Andrew Morton [Tue, 18 Nov 2003 16:15:17 +0000 (08:15 -0800)]
[PATCH] Fix bugs in ext2_new_inode()
From: Mingming Cao <cmm@us.ibm.com>
I found several bugs/issues in the ext2_new_inode() code:
1) The for loop variable "i" is used to save the inode offset. In the
case of failure, the loop variable could be crapped. So it is possible
to quit searching before looking at every block groups.
2) The number of free inodes in the selected group is possibly being
miscalculated. The counter is only decreased in the find_group_xx()
functions for the initial selected group. If the initial try failed,
and succeed in finding a free inode in other group, the counter for that
group will not to be decreased.
3) In case of the concurrent case, going back to find_group_xx()
functions are unnecessary, it will only get the same group as before.
The following patch fixed those issues. Ideas are stolen from
ext3_new_inode().
Andrew Morton [Tue, 18 Nov 2003 16:14:51 +0000 (08:14 -0800)]
[PATCH] sched_clock() fix
From: Thomas Schlicter
sched_clock() will try to use the TSC even if the system is not using the TSC
as a time source. It causes bad scheduling decisions and poor interactivity.
The problem was exhibited by the patch which uses ACPI PM as a time source,
but could also happen if the system is using the PIT.
Andrew Morton [Tue, 18 Nov 2003 16:14:43 +0000 (08:14 -0800)]
[PATCH] gettimeofday resolution fix
From: Stephen Hemminger <shemminger@osdl.org>
The original problem all this is solving is that when NTP is slowing the clock
there existed real cases where time appeared to go backwards. Assuming NTP was
slowing the clock, then it would update the xtime by 999us at the next timer interrupt.
If a program read time three times:
Paul Mackerras [Tue, 18 Nov 2003 08:12:15 +0000 (00:12 -0800)]
[PATCH] PPC64: Fix possible race in syscall restart
This is the PPC64 counterpart of the fix for the potential race in the
syscall restart code that has gone into other architectures. It resets
current_thread_info()->restart_block.fn to do_no_syscall_restart in
the sigreturn code.
Alan Stern [Mon, 17 Nov 2003 03:06:25 +0000 (21:06 -0600)]
[PATCH] Off-by-one bug in user page calculations for Direct I/O
On Sun, 16 Nov 2003, Kai Makisara wrote:
> On Sun, 16 Nov 2003, Alan Stern wrote:
>
> > The page count calculations in drivers/scsi/st.c (and copied in sg.c) are
> > wrong. The code says:
> >
> > nr_pages = ((uaddr & ~PAGE_MASK) + count - 1 + ~PAGE_MASK) >>
> > PAGE_SHIFT;
> >
> > That will compute an incorrect value if the user's buffer happens to end
> > on the first byte of a new page. Example: Suppose uaddr starts right on
>
> Your analysis is correct and this is a bug. Could you send the fix to
> James Bottomley for inclusion into the scsi-bugfixes-2.6 bk tree (at least
> the st part).
>
> Thanks for noticing the bug.
>
> Kai
>
> P.S. I usually write these ((base ~ mask) + count + PAGE_SIZE - 1) >>
> PAGE_SHIFT. I don't know why I did it like this here. One should never try
> to be clever and do something in a new way or copy something that does not
> match one's own standard ways of doing things ;-)
On Mon, 17 Nov 2003, Douglas Gilbert wrote:
> Alan,
> ... and the sg part as well ..
>
> > Thanks for noticing the bug.
>
> dito
>
> Doug Gilbert
Jesse Barnes [Mon, 17 Nov 2003 02:10:13 +0000 (18:10 -0800)]
[PATCH] Fix bootmem breakage on ARM
Russell King reports:
"With previous kernels, the nodes are added to the list in reverse order,
so architecture code knew we had to add the highest PFN first and the
lowest PFN node last.
Unfortunately, init_bootmem_core() now sorts the nodes according to
their start pfn. This active sorting broke ARM discontig memory support."
Andrew Morton chimes in:
"It looks to be bogus on ia64 as well, for which the patch was written"
Yep, I think it is bogus. There's only one caller on ia64 that would be
affected--swiotlb_init(), and afaik multi-node systems won't be using
that code (except maybe NEC?), so even if the pgdat list is out of order
we should be ok. If not I'll fix the ia64 discontig code.
Prasanna Meda [Sun, 16 Nov 2003 13:05:16 +0000 (08:05 -0500)]
[netdrvr tulip] fix hashed setup frame code
It is using local variable `i' in both the inner and outer loop.
Need to bring the for loop outside the loop. Otherwise we need to reset the
setup_frame to tp->setup_frame after every loop. You do not need to set the
setup_frm for every mc address, we can set once after the complete has_table
is ready.
- shost->my_devices is gone and replaced by ->__devices, which is not
exposed to drivers and locked by the host lock. Use the exported
helpers that do proper refcounting to access it.
- sdev->access_count is gone as a side-effect, the sg interfaces
to export it now return 1 for a present scsi_device.
- drivers/scsi/host.h is empty now.
Paul Mackerras [Fri, 14 Nov 2003 08:12:24 +0000 (00:12 -0800)]
[PATCH] PPC32: cancel syscall restart on signal delivery
This patch ensures that the PPC kernel cancels any pending restarted
system call when it delivers a signal. This is the PPC counterpart of
the change that has recently gone into i386 and other architectures.
Paul Mackerras [Fri, 14 Nov 2003 07:34:21 +0000 (23:34 -0800)]
[PATCH] PPC32: Don't oops on out-of-range system call
This patch fixes a bug on PPC where the kernel will oops if a process
does a system call and the system call number is out of range.
While fixing that, I noticed that if the process is being ptraced, an
out-of-range system call will not get traced on the way in but will on
the way out. This patch fixes that too, by making it get traced on
the way in as well as the way out. It turned out to be less change,
and fewer instructions overall, to do that than to make the
out-of-range system call not be traced at all.
Early ACPI table parse for HPET tables has a bug, where in it
does not do proper set_fixmap for ACPI-HPET table.
This bug was lost in oversight, and was not noticed during
my testing too, as the ACPI-HPET table on all my test
systems happened to be in 1st Gig of memory (where __va()
will do the job).
Jason Holmes [Thu, 13 Nov 2003 09:02:48 +0000 (01:02 -0800)]
[PATCH] make 2.6 megaraid recognize intel vendor id
The 2.4 megaraid driver recognizes the Intel PCI vendor id whereas the
2.6 driver does not. The attached patch against 2.6.0-test9 adds the
missing two lines from the 2.4 driver to enable this.
Arun Sharma [Thu, 13 Nov 2003 05:29:19 +0000 (21:29 -0800)]
[PATCH] ia64: invoke schedule_tail unconditionally on ia32 emulation
The #ifdef CONFIG_SMP around the call to schedule_tail was removed a
long time ago for native ia64, but ia32 emulation continues to have a
#ifdef. We saw a bunch of weird behavior with respect to getpid() on
multithreaded programs (they behave ok on SMP, but break on UP).