ChangeSet@1.1520, 2004-12-03 20:43:03-08:00, davem@nuts.davemloft.net
[SPARC64]: Fix SMP cpu bringup bug when bigkernel.
We have to load the bigkernel second TLB entry on
secondary processors before we move over the use
the kernel trap table. Otherwise we can take a
TLB miss somewhere in the post-4MB area and the
TLB handler is not prepared to service that.
The case that usually occurs is the prom_set_trap_table
call made by trampoline.S, since p1275buf usually sits
very near the end of the kernel image. It worked by
luck most of the time as long as p1275buf sits within
a single page since earlier code running in trampoline.S
forced that TLB entry to be loaded by the OBP TLB miss
handler.
This was not fun to figure out.
Signed-off-by: David S. Miller <davem@davemloft.net>
ChangeSet@1.1519, 2004-12-03 16:17:53-08:00, davem@nuts.davemloft.net
[SPARC64]: Update defconfig.
ChangeSet@1.1516.1.44, 2004-12-03 22:12:07-02:00, mingo@elte.hu
[PATCH] floppy boot-time detection fix
found the bug that causes the fd detection failure. It's a generic race
in the upstream floppy driver, which happens to work by chance in the
vanilla kernel but breaks when IRQ and softirq threading is enabled:
when the FDC hardware is initialized, it sometimes generates a floppy
interrupt right away - without being told to. This interrupt can hit the
detection code that executes right after the initialization code, in
particular it can get intermixed with user_reset_fdc() that the
detection code uses. The fd driver is fundamentally single-threaded when
it comes to handling events: an unexpected irq that arrives in the wrong
moment can confuse the reset_fdc() code, which, with softirq and hardirq
threading on, executes in keventd.
in the stock kernel this stale irq doesnt seem to hit the detection code
in the wrong moment, but i think under certain circumstances it may
still happen. One of the typical incarnations of the race was the
following message:
reset set in interrupt, calling c0258400
and googling for "reset set in interrupt, calling" does turn up a fair
number of bootlogs (most of them 2.4 ones) that show such a detection
failure, so i think upstream wants to have the fix too.
the fix is simple: delay a bit after initialization, to make sure the
stale irq does not interfere with the detection code. It will be safely
ignored, since do_floppy is still NULL. It might look sloppy that i went
for a delay, but delay i think it is better than waiting for the irq to
occur, because i dont think there's a guarantee that fdc initialization
triggers an interrupt, so waiting for it could hang the boot process. A
delay OTOH is totally harmless.
The attached patch implements this fix, which resolves the detection
problem on my testbox.
here's again how a failure looks like:
Floppy drive(s): fd0 is 1.44M
reset set in interrupt, calling c0258400
floppy0: no floppy controllers found
and this is how it works with the fix:
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
i've tested this on vanilla 2.6.10-rc2-mm3 too (to make sure this doesnt
break the floppy driver), and it should work fine in -BK too.
(this does not solve the irq threading related SMP lockup though, i'm
attacking that problem next - now that my fd0 gets detected fine ;-) )
Ingo
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ChangeSet@1.1516.1.43, 2004-12-03 21:23:44-02:00, rddunlap@osdl.org
[PATCH] Fix unresolved symbol on x86-64: export swiotlb
> When modprobing any of the modules I get:
> unresolved symbol swiotlb
Looks like it just needs 'swiotlb' exported (as in 2.6.x).
ChangeSet@1.1516.1.42, 2004-12-03 21:08:19-02:00, marcelo@dmt.cyclades
backport v2.6 fork/thread file descriptor race fix
ChangeSet@1.1458.1.9, 2004-12-02 21:08:56-05:00, len.brown@intel.com
[ACPI] acpi=off must disable acpi_early_init()
Signed-off-by: Philippe Troin <phil@fifi.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ChangeSet@1.1516.1.41, 2004-12-02 17:16:08-02:00, kronos@people.it
[PATCH] Add new PCI id to radeonfb
Hi Marcelo,
this is a trivial patch for 2.4.29-pre1.
Add support for the following radeon board (thanks to Jurriaan):
lspci:
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AQ [Radeon 9600]
0000:01:00.1 Display controller: ATI Technologies Inc RV350 AQ [Radeon 9600] (Secondary)
lspci -n:
0000:01:00.0 Class 0300: 1002:4151
0000:01:00.1 Class 0380: 1002:4171
Signed-off-by: Luca Tettamanti <kronos@people.it>
ChangeSet@1.1516.1.40, 2004-12-02 10:42:28-02:00, kronos@people.it
[PATCH] radeonfb: don't try to ioreamp the entire VRAM
Make fb layer aware of the difference between the ioremap()'ed VRAM and
total available VRAM.
smem_len in struct fb_fix_screeninfo contains the amount of physical
VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new
field mapped_vram in struct fb_info contains the amount of VRAM actually
ioremap()'ed by drivers (used in read/write/mmap operations).
If mapped_vram is not set it's assumed that the entire framebuffer is
mapped, thus other drivers are unaffected by this patch.
Signed-off-by: Luca Tettamanti <kronos@people.it>
ChangeSet@1.1516.1.39, 2004-12-01 08:59:24-02:00, marcelo@dmt.cyclades
Cset exclude: vince@arm.linux.org.uk|ChangeSet|20041125151649|65331
ChangeSet@1.1516.1.38, 2004-11-30 15:04:16-02:00, chrisw@osdl.org
[PATCH] proc_tty.c warning fix
> The /proc/tty/driver/serial vulnerability fix in 2.4.29-pre1
> calls a function without a prototype in scope, resulting in:
>
> proc_tty.c: In function `proc_tty_init':
> proc_tty.c:183: warning: implicit declaration of function `proc_mkdir_mode'
> proc_tty.c:183: warning: assignment makes pointer from integer without a cast
Yes, oversight, please apply. Well, here's an insignificant variation
which comes straight from 2.6 to minimize divergence.
===== include/linux/proc_fs.h 1.10 vs edited =====
ChangeSet@1.1516.1.37, 2004-11-30 15:01:31-02:00, bunk@stusta.de
[PATCH] add missing SCSI_SATA_AHCI Configure.help entry
Could you introduce a penalty for people forgetting the Configure.help
entry when adding a new option? ;-)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
ChangeSet@1.1516.1.36, 2004-11-30 14:48:35-02:00, cp@absolutedigital.net
[PATCH] remove obsolete PIIX config help
Hi Marcelo,
The patch below removes some obsolete config help for the Intel PIIX
chipsets.
Signed-off-by: Cal Peake <cp@absolutedigital.net>
ChangeSet@1.1516.1.35, 2004-11-30 12:39:13-02:00, bunk@stusta.de
[PATCH] remove bouncing email address of Deanna Bonds
On Mon, Nov 29, 2004 at 08:27:39AM -0500, Salyzyn, Mark wrote:
> That address should instead become aacraid@adaptec.com to capture
> engineers at Adaptec.
Sounds reasonable.
Updated patch below.
> Sincerely -- Mark Salyzyn
diffstat output:
drivers/scsi/aacraid/README | 2 +-
drivers/scsi/dpt/dpti_ioctl.h | 2 +-
drivers/scsi/dpt_i2o.c | 2 +-
drivers/scsi/dpti.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
ChangeSet@1.1516.1.34, 2004-11-30 12:33:21-02:00, tv@lio96.de
[PATCH] VM documentation fix: vm_anon_lru default is 0
> o Marc-Christian Petersen: VM documentation update
Here is a typo.
/proc/sys/vm/vm_anon_lru is default 0
ChangeSet@1.1516.1.33, 2004-11-25 17:46:49-02:00, marcelo@logos.cnet
fix get_user_pages() change typo
TAG: v2.4.29-pre1