Linux Sparc

• Thread Index

• 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
  • From: konrad@xxxxxxxxxxx
• 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
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• [PATCH 4/5] sparc,leon: Added support for AMBAPP bus.
  • From: konrad@xxxxxxxxxxx
• [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
  • From: konrad@xxxxxxxxxxx
• [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
  • From: konrad@xxxxxxxxxxx
• [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• 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)
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• [PATCH 5/5] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
  • From: konrad@xxxxxxxxxxx
• [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
  • From: konrad@xxxxxxxxxxx
• [PATCH 4/5] sparc,leon: Added support for AMBAPP bus.
  • From: konrad@xxxxxxxxxxx
• [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• [PATCH 1/1] sparc,leon: Added support for AMBAPP bus.
  • From: konrad@xxxxxxxxxxx
• [PATCH 3/5] sparc,leon: Introduce the sparc-leon CPU type.
  • From: konrad@xxxxxxxxxxx
• [PATCH 2/5] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• [PATCH 1/5] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• [PATCH] sparc,leon: Added support for AMBAPP bus.
  • From: konrad@xxxxxxxxxxx
• [PATCH] sparc,leon: sparc-leon specific SRMMU initialization and bootup fixes.
  • From: konrad@xxxxxxxxxxx
• [PATCH] sparc,leon: Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• [PATCH] sparc,leon: CONFIG_SPARC_LEON option and leon specific files.
  • From: konrad@xxxxxxxxxxx
• 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.
  • From: konrad@xxxxxxxxxxx
• 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: konrad@xxxxxxxxxxx
• 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: konrad@xxxxxxxxxxx
• 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@xxxxxxxxxxx
• round2 [PATCH 2/6] Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• 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@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: [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
  • From: konrad@xxxxxxxxxxx
• [PATCH 6/7] Handle sparc-leon SRMMU specific bug. Shielded by CONFIG_SPARC_LEON.
  • From: konrad@xxxxxxxxxxx
• [PATCH 5/7] Added support for AMBA bus. The device is a AMBA bus if
  • From: konrad@xxxxxxxxxxx
• [PATCH 4/7] Undefine srmmu_hwprobe in the CONFIG_SPARC_LEON case.
  • From: konrad@xxxxxxxxxxx
• [PATCH 3/7] Introduce the sparc-leon CPU type. Add sparc_leon enum,
  • From: konrad@xxxxxxxxxxx
• [PATCH 2/7] Redefine MMU register access asi if CONFIG_LEON
  • From: konrad@xxxxxxxxxxx
• [PATCH 1/7] CONFIG_SPARC_LEON option
  • From: konrad@xxxxxxxxxxx
• 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?
  • From: coyote@xxxxxxxxxx
• [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>