Linux Sparc
[Prev Page][Next Page]
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: Tim Abbott <tabbott@xxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: Tim Abbott <tabbott@xxxxxxxxxxx>
- Re: [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH v2] Linker script cleanup for sparc
- From: Tim Abbott <tabbott@xxxxxxxxxxx>
- [PATCH v2] sparc: Clean up linker script using new linker script macros.
- From: Tim Abbott <tabbott@xxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: [PATCH 0/3] /proc/kmem cleanups and hwpoison bits
- From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
- Re: [PATCH 0/3] /proc/kmem cleanups and hwpoison bits
- From: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH 0/3] /proc/kmem cleanups and hwpoison bits
- From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [GIT]: Sparc
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: blackbird errata workaround
- From: David Miller <davem@xxxxxxxxxxxxx>
- blackbird errata workaround
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxx>
- Re: SunFire V240 hangs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SunFire V240 hangs
- From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
- RE: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: "Leif Sawyer" <lsawyer@xxxxxxx>
- Re: [PATCH v2] Fix multiple RTC detections on SUN4D
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SunFire V240 hangs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Cassini problem
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <seb@xxxxxxxxx>
- Re: SunFire V240 hangs
- From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: David Miller <davem@xxxxxxxxxxxxx>
- Problem with saturn since 2.6.29 (debian kernel).
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: SunFire V240 hangs
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: Sparc release requalification
- From: Sébastien Bernard <sbernard@xxxxxxxxx>
- Re: [PATCH v2] Fix multiple RTC detections on SUN4D
- From: Kjetil Oftedal <oftedal@xxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: convert /proc/io_map, /proc/dvma_map to seq_file
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] percpu: don't assume existence of cpu0
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH] sparc: convert /proc/io_map, /proc/dvma_map to seq_file
- From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
- [PATCH] percpu: don't assume existence of cpu0
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Meelis Roos <mroos@xxxxxxxx>
- [PATCH 1/1] sparc,leon: Sparc-Leon SMP support
- Sparc-leon smp support [Round 2]
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Meelis Roos <mroos@xxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: Meelis Roos <mroos@xxxxxxxx>
- Re: [PATCH 1/1] sparc,leon: Sparc-Leon SMP support
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 1/1] sparc,leon: Sparc-Leon SMP support
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 1/1] sparc,leon: Sparc-Leon SMP support
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: boot panic after oops from sysfs_new_dirent
- From: David Miller <davem@xxxxxxxxxxxxx>
- boot panic after oops from sysfs_new_dirent
- From: Meelis Roos <mroos@xxxxxxxx>
- [PATCH 1/1] sparc,leon: Sparc-Leon SMP support
- Sparc-leon smp support
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH]: sparc64: Validate linear D-TLB misses.
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH]: sparc64: Validate linear D-TLB misses.
- From: Jim Gifford <maillist@xxxxxxxxx>
- Re: [PATCH]: sparc64: Validate linear D-TLB misses.
- From: hyl <heyongli@xxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH]: sparc64: Validate linear D-TLB misses.
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH]: sparc64: Validate linear D-TLB misses.
- From: David Miller <davem@xxxxxxxxxxxxx>
- [BUGGY PATCH]: Validate D-tlb linear kernel faults
- From: David Miller <davem@xxxxxxxxxxxxx>
- Neta X1 Tulip Issue - Resend
- From: Jim Gifford <maillist@xxxxxxxxx>
- [PATCH 1/1] sparc,leon: Amba plug and play devices directory.
- Sparc-leon uart driver patch for review
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: sparc: sys32.S incorrect compat-layer splice() system call
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc: sys32.S incorrect compat-layer splice() system call
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
- Re: sparc: sys32.S incorrect compat-layer splice() system call
- From: David Miller <davem@xxxxxxxxxxxxx>
- sparc: sys32.S incorrect compat-layer splice() system call
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: bug: spinlock on UP system
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: bug: spinlock on UP system
- From: Dennis Gilmore <dennis@xxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 5/5] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- [PATCH 4/5] sparc,leon: Added support for AMBAPP bus.
- [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
- [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
- sparc-leon patches round 6 (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH] sparc64: build compressed image (zImage) by default
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc64: cheaper asm/uaccess.h inclusion
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [RFC][PATCH] SPARC: fix duplicate declaration
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc64: list zImage build target in 'make help' output
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH 2/2 2.6.31-rc5 UPDATED] percpu, sparc64: fix sparse possible cpu map handling
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: Sparc miss chance to fix recoverable fault in copy_from_user
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sparc miss chance to fix recoverable fault in copy_from_user
- From: hyl <heyongli@xxxxxxxxx>
- [PATCH] sparc64: cheaper asm/uaccess.h inclusion
- From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
- Re: Sparc miss chance to fix recoverable fault in copy_from_user
- From: David Miller <davem@xxxxxxxxxxxxx>
- [RFC][PATCH] SPARC: fix duplicate declaration
- From: Jaswinder Singh Rajput <jaswinder@xxxxxxxxxx>
- Re: [PATCH resend 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH resend 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: bug: spinlock on UP system
- From: Dennis Gilmore <dennis@xxxxxxxx>
- bug:
- From: Dennis Gilmore <dennis@xxxxxxxx>
- Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: Tejun Heo <tj@xxxxxxxxxx>
- [2.6.27.21] bbc_envctrl
- From: BERTRAND Joel <joel.bertrand@xxxxxxxxxxx>
- [PATCH 4/8] sparc: use asm-generic/dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/8] IA64: remove NULL flush_write_buffers
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 8/8] sparc: add CONFIG_DMA_API_DEBUG support
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH resend 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/8] remove flush_write_buffers() in dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 6/8] sparc: replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 7/8] sparc: use asm-generic/pci-dma-compat
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 5/8] sparc: remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 3/8] sparc: use dma_map_ops struct
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: Ingo Molnar <mingo@xxxxxxx>
- [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparse possible cpu map handling
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 1/2 2.6.31-rc5 REPOST] init: set nr_cpu_ids before setup_per_cpu_areas()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [stable] cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Greg KH <greg@xxxxxxxxx>
- Re: [PATCH 1/8] remove flush_write_buffers() in dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: Eldar Abusalimov <eldar.abusalimov@xxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: Eldar Abusalimov <eldar.abusalimov@xxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: Eldar Abusalimov <eldar.abusalimov@xxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Is it a bug in etrap.S srmmu stack check routine?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- Is it a bug in etrap.S srmmu stack check routine?
- From: Eldar Abusalimov <eldar.abusalimov@xxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: is there still value to references to EXPORT_SYMTAB_STROPS?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc-leon patches round 5 (to follow) (right numbering)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- [PATCH] sparc64: list zImage build target in 'make help' output
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH v2] Fix multiple RTC detections on SUN4D
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH v2] Fix multiple RTC detections on SUN4D
- From: Kjetil Oftedal <oftedal@xxxxxxxxx>
- SUN4D RTC patch...
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Joerg Roedel <joerg.roedel@xxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Ingo Molnar <mingo@xxxxxxx>
- [PATCH] Fix multiple RTC detections on SUN4D
- From: Kjetil Oftedal <oftedal@xxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 8/8] sparc: add CONFIG_DMA_API_DEBUG support
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 7/8] sparc: use asm-generic/pci-dma-compat
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 6/8] sparc: replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 5/8] sparc: remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 4/8] sparc: use asm-generic/dma-mapping-common.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 3/8] sparc: use dma_map_ops struct
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH,resend] sparc64: build compressed image (zImage) by default
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Joerg Roedel <joerg.roedel@xxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: sparc32 dma-debug found bug?
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 6/8] sparc: replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 7/8] sparc: use asm-generic/pci-dma-compat
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 4/8] sparc: use asm-generic/dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 8/8] sparc: add CONFIG_DMA_API_DEBUG support
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 5/8] sparc: remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 3/8] sparc: use dma_map_ops struct
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/8] IA64: remove NULL flush_write_buffers
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/8] remove flush_write_buffers() in dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH v2 0/8] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
- From: Arnd Bergmann <arnd@xxxxxxxx>
- Re: [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- sparc32 dma-debug found bug?
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [PATCH 0/5] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 0/5] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- is there still value to references to EXPORT_SYMTAB_STROPS?
- From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
- Re: [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
- From: Arnd Bergmann <arnd@xxxxxxxx>
- Re: [PATCH 5/5] sparc: use asm-generic/pci-dma-compat
- From: Arnd Bergmann <arnd@xxxxxxxx>
- [PATCH 5/5] sparc: use asm-generic/pci-dma-compat
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/5] sparc: use dma_map_ops struct
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 3/5] sparc: remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 0/5] sparc: use asm-generic/dma-mapping-common.h and pci-dma-compat.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 4/5] sparc: replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: Irrecoverable deferred error trap
- From: Ante Karamatić <ivoks@xxxxxxx>
- RE: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: "Leif Sawyer" <lsawyer@xxxxxxx>
- RE: 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: "Leif Sawyer" <lsawyer@xxxxxxx>
- 2.6.31-rc1: sparc T2: Fast Data Access MMU Miss
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Jan Engelhardt <jengelh@xxxxxxxxxx>
- [PATCH] sparc64: build compressed image (zImage) by default
- From: Frans Pop <elendil@xxxxxxxxx>
- [PATCH 09/62] arch/sparc/kernel/irq_64.c: Remove unnecessary semicolons
- From: Joe Perches <joe@xxxxxxxxxxx>
- [GIT]: Sparc fixes
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: David Miller <davem@xxxxxxxxxxxxx>
- merge window now closed
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc-leon patches round 4 (to follow)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- [PATCH 5/5] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
- [PATCH 4/5] sparc,leon: Added support for AMBAPP bus.
- [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
- [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- sparc-leon patches round 5 (to follow) (right numbering)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: sparc-leon patches round 4 (to follow)
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: sparc-leon patches round 4 (to follow)
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH] sparc,leon: Added support for AMBAPP bus.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: sparc-leon patches round 3 (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- From: Florian Fainelli <florian@xxxxxxxxxxx>
- Re: [PATCH] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: sparc-leon patches round 3 (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- [PATCH 1/1] sparc,leon: Added support for AMBAPP bus.
- [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
- [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
- [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- sparc-leon patches round 4 (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Borislav Petkov <petkovbb@xxxxxxxxxxxxxx>
- Re: [PATCH] ide-cd: Improve "weird block size" error message
- From: Borislav Petkov <petkovbb@xxxxxxxxxxxxxx>
- [PATCH] ide-cd: Improve "weird block size" error message
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc,leon: Added support for AMBAPP bus.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc,leon: Introduce the sparc-leon CPU type.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: sparc-leon patches round 3 (to follow)
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Arnd Bergmann <arnd@xxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Jeff Garzik <jeff@xxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- [PATCH 5/4] sparc32: Fix makefile not generating required files
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 2/4] sparc32: Apply Robert Reif's changes
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: [PATCH] sparc,leon: Introduce the sparc-leon CPU type.
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: round2 [PATCH 3/6] Introduce the sparc-leon CPU type. Add sparc_leon enum, M_LEON|M_LEON3_SOC machine. Add compilation of leon.c in mm and kernel if CONFIG_SPARC_LEON is defined. Add sparc_leon dependent initialization to switch statements + head.S.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: round2 [PATCH 1/6] CONFIG_SPARC_LEON option and leon specific files. This macro will shield, if undefined, the sun-sparc code from LEON specific code. In particular include/asm/leon.h will get empty through #ifdef arch/sparc/kernel/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON) arch/sparc/mm/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH] sparc,leon: Introduce the sparc-leon CPU type.
- [PATCH] sparc,leon: Added support for AMBAPP bus.
- [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
- [PATCH] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
- [PATCH] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
- Re: [PATCH 0/4] sparc: Minor tftpboot.img build fixes
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- sparc-leon patches round 3 (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: NMI watchdog + NOHZ question
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- NMI watchdog + NOHZ question
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- [PATCH 1/4] sparc64: Fix build warnings in piggyback_64.c
- From: Julian Calaby <jcalaby@xxxxxxxxxxxxxxxxxxxx>
- [PATCH 2/4] sparc32: Apply Robert Reif's changes
- From: Julian Calaby <jcalaby@xxxxxxxxxxxxxxxxxxxx>
- [PATCH 3/4] sparc: fix tftpboot.img build
- From: Julian Calaby <jcalaby@xxxxxxxxxxxxxxxxxxxx>
- [PATCH 1/4] sparc64: Fix build warnings in piggyback_64.c
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [PATCH 3/4] sparc: fix tftpboot.img build
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [PATCH 2/4] sparc32: Apply Robert Reif's changes
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [PATCH 4/4] sparc32: Fix tftpboot.img Makefile
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [PATCH 1/4] sparc64: Fix build warnings in piggyback_64.c
- From: Julian Calaby <jcalaby@xxxxxxxxxxxxxxxxxxxx>
- [PATCH 4/4] sparc32: Fix tftpboot.img Makefile
- From: Julian Calaby <jcalaby@xxxxxxxxxxxxxxxxxxxx>
- [PATCH 0/4] sparc: Minor tftpboot.img build fixes
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Matthew Wilcox <matthew@xxxxxx>
- Re: New IDE maintainer
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
- Re: New IDE maintainer
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Pete Zaitcev <zaitcev@xxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Kjetil Oftedal <oftedal@xxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: round2 [PATCH 5/6] Added support for AMBA bus. The device is a AMBA bus if it is a child of prom node "ambapp" (AMBA plug and play). Two functions leon_trans_init() and leon_node_init() (defined in sparc/kernel/leon.c) are called in the prom_build_tree() path if CONFIG_SPARC_LEON is defined. leon_node_init() will build up the device tree using AMBA plug and play.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: round2 [PATCH 6/6] sparc-leon specific SRMMU initialization and bootup fixes. The sparc-leon caches are virtually tagged so a flush is needed on ctx switch.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: round2 [PATCH 4/6] Undefine srmmu_hwprobe in the CONFIG_SPARC_LEON case. The sparc-leon SRMMU has no mmu probe logic implemented. Instead function srmmu_swprobe() is used that is defined in arch/sparc/mm/leon.c. arch/sparc/include/asm/leon.h on the other hand defines srmmu_hwprobe(addr) as a macro
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: round2 [PATCH 3/6] Introduce the sparc-leon CPU type. Add sparc_leon enum, M_LEON|M_LEON3_SOC machine. Add compilation of leon.c in mm and kernel if CONFIG_SPARC_LEON is defined. Add sparc_leon dependent initialization to switch statements + head.S.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: sparc-leon patches (to follow) round 2
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: round2 [PATCH 1/6] CONFIG_SPARC_LEON option and leon specific files. This macro will shield, if undefined, the sun-sparc code from LEON specific code. In particular include/asm/leon.h will get empty through #ifdef arch/sparc/kernel/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON) arch/sparc/mm/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON)
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: sparc-leon patches (to follow) round 2
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- cmd64x: irq 14: nobody cared - system is dreadfully slow
- From: Frans Pop <elendil@xxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc: fix tftpboot.img build
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: sparc cannot boot
- From: David Miller <davem@xxxxxxxxxxxxx>
- 2.6.31-rc1: sparc cannot boot
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx>
- Re: Sunfire V880 and 480R 2.6.27x-2.6.30 startup hangs
- From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: 2.6.31-rc1: memory initialization warnings on sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- 2.6.31-rc1: memory initialization warnings on sparc
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: Chris Newport <crn@xxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [PATCH] Bring sparc64 dynamic ftrace up to snuff...
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] Bring sparc64 dynamic ftrace up to snuff...
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH] Bring sparc64 dynamic ftrace up to snuff...
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH] Bring sparc64 dynamic ftrace up to snuff...
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
- [PATCH] Bring sparc64 dynamic ftrace up to snuff...
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] silo: move second to make room for larger kernel
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- [PATCH] silo: move second to make room for larger kernel
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: linux-next: rr-latest-cpumask/sparc tree build failure
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- round2 [PATCH 6/6] sparc-leon specific SRMMU initialization and bootup fixes. The sparc-leon caches are virtually tagged so a flush is needed on ctx switch.
- round2 [PATCH 5/6] Added support for AMBA bus. The device is a AMBA bus if it is a child of prom node "ambapp" (AMBA plug and play). Two functions leon_trans_init() and leon_node_init() (defined in sparc/kernel/leon.c) are called in the prom_build_tree() path if CONFIG_SPARC_LEON is defined. leon_node_init() will build up the device tree using AMBA plug and play.
- round2 [PATCH 4/6] Undefine srmmu_hwprobe in the CONFIG_SPARC_LEON case. The sparc-leon SRMMU has no mmu probe logic implemented. Instead function srmmu_swprobe() is used that is defined in arch/sparc/mm/leon.c. arch/sparc/include/asm/leon.h on the other hand defines srmmu_hwprobe(addr) as a macro
- round2 [PATCH 3/6] Introduce the sparc-leon CPU type. Add sparc_leon enum, M_LEON|M_LEON3_SOC machine. Add compilation of leon.c in mm and kernel if CONFIG_SPARC_LEON is defined. Add sparc_leon dependent initialization to switch statements + head.S.
- round2 [PATCH 2/6] Redefine MMU register access asi if CONFIG_LEON
- round2 [PATCH 1/6] CONFIG_SPARC_LEON option and leon specific files. This macro will shield, if undefined, the sun-sparc code from LEON specific code. In particular include/asm/leon.h will get empty through #ifdef arch/sparc/kernel/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON) arch/sparc/mm/leon.c not compiled through Makefile:obj-$(CONFIG_SPARC_LEON)
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 7/7] sparc-leon specific SRMMU initialization and
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 7/7] sparc-leon specific SRMMU initialization and
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [patch 1/4] sparc: move the duplication in dma-mapping_{32|64}.h to dma-mapping.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 7/7] sparc-leon specific SRMMU initialization and
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 3/7] Introduce the sparc-leon CPU type. Add sparc_leon enum,
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 5/7] Added support for AMBA bus. The device is a AMBA bus if
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 7/7] sparc-leon specific SRMMU initialization and
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 1/7] CONFIG_SPARC_LEON option
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 5/7] Added support for AMBA bus. The device is a AMBA bus if
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 3/7] Introduce the sparc-leon CPU type. Add sparc_leon enum,
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 1/7] CONFIG_SPARC_LEON option
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [patch 1/4] sparc: move the duplication in dma-mapping_{32|64}.h to dma-mapping.h
- From: akpm@xxxxxxxxxxxxxxxxxxxx
- [patch 2/4] sparc: add sync_single_for_device and sync_sg_for_device to struct dma_ops
- From: akpm@xxxxxxxxxxxxxxxxxxxx
- [patch 3/4] sparc: use dma_map_page instead of dma_map_single
- From: akpm@xxxxxxxxxxxxxxxxxxxx
- [patch 4/4] sparc: remove dma-mapping_{32|64}.h
- From: akpm@xxxxxxxxxxxxxxxxxxxx
- Re: [PATCH 1/7] CONFIG_SPARC_LEON option
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH 1/7] CONFIG_SPARC_LEON option
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [PATCH 1/7] CONFIG_SPARC_LEON option
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 2/7] Redefine MMU register access asi if CONFIG_LEON
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- [PATCH 7/7] sparc-leon specific SRMMU initialization and
- [PATCH 6/7] Handle sparc-leon SRMMU specific bug. Shielded by CONFIG_SPARC_LEON.
- [PATCH 5/7] Added support for AMBA bus. The device is a AMBA bus if
- [PATCH 4/7] Undefine srmmu_hwprobe in the CONFIG_SPARC_LEON case.
- [PATCH 3/7] Introduce the sparc-leon CPU type. Add sparc_leon enum,
- [PATCH 2/7] Redefine MMU register access asi if CONFIG_LEON
- [PATCH 1/7] CONFIG_SPARC_LEON option
- Re: [Patch 4/5] module: trim exception table in module_free()
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 2/7] Redefine MMU register access asi if CONFIG_LEON
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 4/7] Undefine srmmu_hwprobe in the CONFIG_LEON case.
- From: Julian Calaby <julian.calaby@xxxxxxxxx>
- Re: [PATCH 7/7] sparc-leon specific SRMMU initialization
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH 6/7] Handle sparc-leon SRMMU specific bug
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH 5/7] Added support for AMBA bus
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH 3/7] Introduce the sparc-leon CPU type.
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH 1/7] CONFIG_LEON option
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13489] New: us2e_cpufreq does not work on Netra t1 200
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13489] New: us2e_cpufreq does not work on Netra t1 200
- From: Jos van der Ende <seraph@xxxxxxxxx>
- [PATCH 7/7] sparc-leon specific SRMMU initialization
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 6/7] Handle sparc-leon SRMMU specific bug
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 5/7] Added support for AMBA bus
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 4/7] Undefine srmmu_hwprobe in the CONFIG_LEON case.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 3/7] Introduce the sparc-leon CPU type.
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 2/7] Redefine MMU register access asi if CONFIG_LEON
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- [PATCH 1/7] CONFIG_LEON option
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- sparc-leon patches (to follow)
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13489] New: us2e_cpufreq does not work on Netra t1 200
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- [PATCH] sparc: fix tftpboot.img build
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [Patch 4/5] module: trim exception table in module_free()
- From: Amerigo Wang <amwang@xxxxxxxxxx>
- Re: SILO & Ext4
- From: Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Patch 4/5] module: trim exception table in module_free()
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: SILO & Ext4
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Konrad Eisele <konrad@xxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: LEON SPARC git repository
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- LEON SPARC git repository
- From: Kristoffer Glembo <kristoffer@xxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13444] New: SparcServer 1000E SMP can cause kernel-nullpointer with some hw configurations
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: sparc generic read_mostly patches
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] SPARC: Simplify code using is_power_of_2() routine.
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] move of_device common code to of_device_common
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13444] New: SparcServer 1000E SMP can cause kernel-nullpointer with some hw configurations
- From: oftedal <oftedal@xxxxxxxxx>
- sparc generic read_mostly patches
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 0/4] sparc: unify dma-mapping_32.h and dma-mapping_64.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] sparc64: fix and optimize irq distribution
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v3 0/1] sparc64: fix and optimize irq distribution
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13444] New: SparcServer 1000E SMP can cause kernel-nullpointer with some hw configurations
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13444] New: SparcServer 1000E SMP can cause kernel-nullpointer with some hw configurations
- From: oftedal <oftedal@xxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Bugme-new] [Bug 13444] New: SparcServer 1000E SMP can cause kernel-nullpointer with some hw configurations
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- [PATCH] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- [PATCH v3 0/1] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: Alex Buell <alex.buell@xxxxxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: Alex Buell <alex.buell@xxxxxxxxxxxxx>
- Re: SILO & Ext4
- From: David Miller <davem@xxxxxxxxxxxxx>
- SILO & Ext4
- From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
- [GIT]: Sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- LEON SPARC
- From: Kristoffer Glembo <kristoffer@xxxxxxxxxxx>
- Re: [PATCH 0/4] sparc: unify dma-mapping_32.h and dma-mapping_64.h
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 0/4] sparc: unify dma-mapping_32.h and dma-mapping_64.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Amerigo Wang <amwang@xxxxxxxxxx>
- Re: [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [PATCH 0/4] sparc: unify dma-mapping_32.h and dma-mapping_64.h
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: silo on qemu-system-sparc64
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: silo on qemu-system-sparc64
- From: Igor Kovalenko <igor.v.kovalenko@xxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: silo on qemu-system-sparc64
- From: David Miller <davem@xxxxxxxxxxxxx>
- silo on qemu-system-sparc64
- From: Igor Kovalenko <igor.v.kovalenko@xxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Amerigo Wang <amwang@xxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Amerigo Wang <amwang@xxxxxxxxxx>
- Re: [PATCH 5/12]: sparc64: Refactor OBP cpu scanning code using an iterator.
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Amerigo Wang <amwang@xxxxxxxxxx>
- Re: [Patch 4/4] module: trim exception table in module_free()
- From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
- [2.6.29.4] Blade 2000
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [bbc_i2c] howto read CPU temp ?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [bbc_i2c] howto read CPU temp ?
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: [bbc_i2c] howto read CPU temp ?
- From: David Miller <davem@xxxxxxxxxxxxx>
- [bbc_i2c] howto read CPU temp ?
- From: BERTRAND Joël <joel.bertrand@xxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc64: fix and optimize irq distribution
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- Re: sparc32 boot problem (SCSI?)
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- sparc32 boot problem (SCSI?)
- From: Robert Reif <reif@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc64: fix and optimize irq distribution
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH v2] sparc64: fix and optimize irq distribution
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sunfire V880 and 480R 2.6.27x-2.6.29.3 startup hangs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Sunfire V880 and 480R 2.6.27x-2.6.29.3 startup hangs
- From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
- [PATCH 4/4] sparc: remove dma-mapping_{32|64}.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 3/4] sparc: use dma_map_page instead of dma_map_single
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/4] sparc: move the duplication in dma-mapping_{32|64}.h to dma-mapping.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/4] sparc: add sync_single_for_device and sync_sg_for_device to struct dma_ops
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 0/4] sparc: unify dma-mapping_32.h and dma-mapping_64.h
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: Sun fire T2000,BUG: NMI Watchdog detected LOCKUP on CPU12
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Sun fire T2000,BUG: NMI Watchdog detected LOCKUP on CPU12
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH v2] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- Re: [PATCH] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- Re: Sun fire T2000,BUG: NMI Watchdog detected LOCKUP on CPU12
- From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
- Re: Sun fire T2000,BUG: NMI Watchdog detected LOCKUP on CPU12
- From: David Miller <davem@xxxxxxxxxxxxx>
- Sun fire T2000,BUG: NMI Watchdog detected LOCKUP on CPU12
- From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
- Re: [PATCH] sparc64: fix and optimize irq distribution
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: [PATCH] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- [PATCH] sparc64: fix and optimize irq distribution
- From: "Hong H. Pham" <hong.pham@xxxxxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Pavel Machek <pavel@xxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: Strange network promiscuous mode...
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] cg3: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Markus Gutschke (顧孟勤) <markus@xxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Roland McGrath <roland@xxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Nicholas Miell <nmiell@xxxxxxxxxxx>
- Re: sparc/debian/linux procedures
- From: Martin <inkubus@xxxxxxxxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Markus Gutschke (顧孟勤) <markus@xxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Markus Gutschke (顧孟勤) <markus@xxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Markus Gutschke (顧孟勤) <markus@xxxxxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Ingo Molnar <mingo@xxxxxxx>
- Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
- From: Markus Gutschke (顧孟勤) <markus@xxxxxxxxxx>
- Re: [PATCH] cg3: use standard fields for framebuffer physical address and length
- From: krzysztof.h1@xxxxxxxxx
- Re: [PATCH] p9100: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] leo: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] cg14: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: bw2: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] tcx: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] cg6: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] cg3: use standard fields for framebuffer physical address and length
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH] p9100: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- [PATCH] leo: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- [PATCH] cg14: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- bw2: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- [PATCH] tcx: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- ffb: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- [PATCH] cg6: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- [PATCH] cg3: use standard fields for framebuffer physical address and length
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- sparc/debian/linux procedures
- From: Brian Thompson <brian@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] igafb: use framebuffer_alloc() to allocate fb_info struct
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- [PATCH] igafb: use framebuffer_alloc() to allocate fb_info struct
- From: Krzysztof Helt <krzysztof.h1@xxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Florian Fainelli <florian@xxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Julien Cristau <jcristau@xxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Julien Cristau <jcristau@xxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Sam Ravnborg <sam@xxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Josip Rodin <joy@xxxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: Another set of debian niagara bugs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Another set of debian niagara bugs
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: X4422A dual-gigabit + dual-UW2 SCSI?
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: X4422A dual-gigabit + dual-UW2 SCSI?
- From: Marc Zyngier <maz@xxxxxxxxxxxxxxx>
- X4422A dual-gigabit + dual-UW2 SCSI?
- [PATCH 2/4] sparc: use new macros for .data.init_task.
- From: Tim Abbott <tabbott@xxxxxxx>
- [PATCH 0/4] section name cleanup for sparc
- From: Tim Abbott <tabbott@xxxxxxx>
- [PATCH 4/4] sparc: convert to new generic read_mostly support.
- From: Tim Abbott <tabbott@xxxxxxx>
- [PATCH 3/4] sparc: use new macro for .data.read_mostly section.
- From: Tim Abbott <tabbott@xxxxxxx>
- [PATCH 1/4] sparc: use new macro for .data.cacheline_aligned section.
- From: Tim Abbott <tabbott@xxxxxxx>
- Another set of debian niagara bugs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: interrupt problem with multiple vnet devices
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: interrupt problem with multiple vnet devices
- From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
- Re: interrupt problem with multiple vnet devices
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: interrupt problem with multiple vnet devices
- From: David Miller <davem@xxxxxxxxxxxxx>
- interrupt problem with multiple vnet devices
- From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
- Re: [PATCH] of: make of_(un)register_platform_driver common code.
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- [PATCH] of: make of_(un)register_platform_driver common code.
- From: Grant Likely <grant.likely@xxxxxxxxxxxx>
- Re: SunFire V240 hangs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: SunFire V240 hangs
- From: Sébastien Bernard <seb@xxxxxxxxx>
- Re: SunFire V240 hangs
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: "leds: Add openfirmware platform device support" breaks sparc
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
- Re: "leds: Add openfirmware platform device support" breaks sparc
- From: Grant Likely <grant.likely@xxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: debian unusable on niagara
- From: Jurij Smakov <jurij@xxxxxxxxx>
Mail converted by MHonArc
[Index of Archives]
[Kernel Announce]
[IETF Annouce]
[Security]
[Netfilter]
[GCC Help]
[Bugtraq]