Linux Sparc

• Thread Index

• 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>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• [PATCH 1/2] sparc: use NO_IRQ if irq_of_parse_and_map() fails
  • From: Roel Kluin <roel.kluin@xxxxxxxxx>
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: Sébastien Bernard <seb@xxxxxxxxxxxxxx>
• Re: Fire V880 hangs at Testing NMI with 2.6.29.1
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Fire V880 hangs at Testing NMI with 2.6.29.1
  • From: adi@xxxxxxxxxxxxxxxxxxxxx (Adrian Knoth)
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: Frans van Berckel <fberckel@xxxxxxxxx>
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Fire V880 hangs at Testing NMI with 2.6.29.1
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch] Niagara1 Perfcounter Accesses
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch] Niagara1 Perfcounter Accesses
  • From: Vince Weaver <vince@xxxxxxxxxx>
• [PATCH] SPARC: Simplify code using is_power_of_2() routine.
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: [patch] Niagara1 Perfcounter Accesses
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: debian unusable on niagara
  • From: Andrew Robert Nicols <andrew.nicols@xxxxxxxxxxx>
• Re: debian unusable on niagara
  • From: David Markey <dmarkey@xxxxxxxxxxx>
• Re: debian unusable on niagara
  • From: David Miller <davem@xxxxxxxxxxxxx>
• debian unusable on niagara
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch] Niagara1 Perfcounter Accesses
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: inconsistent lock state in 2.6.29-rc6
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [patch] Niagara1 Perfcounter Accesses
  • From: Vince Weaver <vince@xxxxxxxxxx>
• Re: inconsistent lock state in 2.6.29-rc6
  • From: Meelis Roos <mroos@xxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Fire V880 hangs at Testing NMI with 2.6.29.1
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Fire V880 hangs at Testing NMI with 2.6.29.1
  • From: adi@xxxxxxxxxxxxxxxxxxxxx (Adrian Knoth)
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: remove some pointless conditionals before kfree()
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: fix possible build error in arch/sparc/include/asm/parport.h
  • From: Josip Rodin <joy@xxxxxxxxxxxxxxx>
• alloc_io_res: cannot occupy / paging request fails
  • From: ipif <ipif@xxxxxxxxx>
• Re: [PATCH] sparc: fix possible build error in arch/sparc/include/asm/parport.h
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc: fix possible build error in arch/sparc/include/asm/parport.h
  • From: Wei Yongjun <yjwei@xxxxxxxxxxxxxx>
• Re: getting the program counter from sparc64 under gcc/glibc linux
  • From: Mark Farnell <mark.farnell@xxxxxxxxx>
• Re: getting the program counter from sparc64 under gcc/glibc linux
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: getting the program counter from sparc64 under gcc/glibc linux
  • From: Mark Farnell <mark.farnell@xxxxxxxxx>
• Open Wildcat FB driver
  • From: Frans van Berckel <fberckel@xxxxxxxxx>
• Re: sparc32 fails to boot
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: getting the program counter from sparc64 under gcc/glibc linux
  • From: David Miller <davem@xxxxxxxxxxxxx>
• getting the program counter from sparc64 under gcc/glibc linux
  • From: Mark Farnell <mark.farnell@xxxxxxxxx>
• sparc32 fails to boot
  • From: Robert Reif <reif@xxxxxxxxxxxxx>
• Re: [PATCH 12/12]: sparc64: Use new dynamic per-cpu allocator.
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 12/12]: sparc64: Use new dynamic per-cpu allocator.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 12/12]: sparc64: Use new dynamic per-cpu allocator.
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 12/12]: sparc64: Use new dynamic per-cpu allocator.
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 5/12]: sparc64: Refactor OBP cpu scanning code using an iterator.
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 12/12]: sparc64: Use new dynamic per-cpu allocator.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 10/12]: sparc64: Get rid of real_setup_per_cpu_areas().
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 11/12]: sparc64: Only allocate per-cpu areas for possible cpus.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 9/12]: sparc64: Defer cpu_data() setup until end of per-cpu data initialization.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 8/12]: sparc64: Make mdesc_fill_in_cpu_data take a cpumask_t pointer.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 7/12]: sparc: Call OF and MD cpu scanning explicitly from paging_init()
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 6/12]: sparc64: Refactor MDESC cpu scanning code using an iterator.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 5/12]: sparc64: Refactor OBP cpu scanning code using an iterator.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 4/12]: sparc64: Use BUILD_BUG_ON() in trap_init().
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 3/12]: sparc64: Store per-cpu offset in trap_block[]
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 2/12]: sparc64: Move trap_block[] definitions into a new header file.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 1/12]: sparc64: Reclaim trap_block[]->hdesc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 0/12]: Sparc64 dynamic per-cpu support.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: inconsistent lock state in 2.6.29-rc6
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: SunFire V240 hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: SunFire V240 hangs
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: SunFire V240 hangs
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• SunFire V240 hangs
  • From: seb@xxxxxxxxxxxxxx
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: Dennis Gilmore <dennis@xxxxxxxx>
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: Dennis Gilmore <dennis@xxxxxxxx>
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: Dennis Gilmore <dennis@xxxxxxxx>
• kernel bug with CONFIG_KEYBOARD_ATKBD=y
  • From: Dennis Gilmore <dennis@xxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
• [2.6.29.1] Panic on boot
  • From: BERTRAND Joel <joel.bertrand@xxxxxxxxxxx>
• [2.6.28.9] bbc driver
  • From: BERTRAND Joel <joel.bertrand@xxxxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• [PATCH] sparc: remove some pointless conditionals before kfree()
  • From: Wei Yongjun <yjwei@xxxxxxxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PULL] cpumask updates for sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: configs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: configs
  • From: Paul Thomas <pthomas8589@xxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jiri Gaisler <jiri@xxxxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• Re: configs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Alexander Beregalov <a.beregalov@xxxxxxxxx>
• Re: next-20090310: ext4 hangs
  • From: Jan Kara <jack@xxxxxxx>
• configs
  • From: Paul Thomas <pthomas8589@xxxxxxxxx>
• Strange network promiscuous mode...
  • From: BERTRAND Joel <joel.bertrand@xxxxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: "Benoit-Pierre Guay" <bpguay@xxxxxxxxxxxxxxxx>
• RE: esp scsi problem on shutdown - sunhme related?
  • From: "Benoit-Pierre Guay" <bpguay@xxxxxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: "Benoit-Pierre Guay" <bpguay@xxxxxxxxxxxxxxxx>
• Re: [PATCH] crash with /proc/iomem on sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] crash with /proc/iomem on sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Irrecoverable deferred error trap
  • From: Josip Rodin <joy@xxxxxxxxxxxxxx>
• Re: [PATCH] crash with /proc/iomem on sparc64
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] crash with /proc/iomem on sparc64
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] crash with /proc/iomem on sparc64
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
• [PULL] cpumask updates for sparc
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Friedrich Oslage <bluebird@xxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: question on sparc64 switch_to macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• question on sparc64 switch_to macro
  • From: Chris Torek <chris.torek@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Friedrich Oslage <bluebird@xxxxxxxxxx>
• Re: dmfe/tulip kernel module poll
  • From: Brian Thompson <brian@xxxxxxxxxxxxx>
• Re: dmfe/tulip kernel module poll
  • From: Brian Thompson <brian@xxxxxxxxxxxxx>
• Re: dmfe/tulip kernel module poll
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: dmfe/tulip kernel module poll
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Ultra1 ESP detection problem
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Ultra1 ESP detection problem
  • From: Meelis Roos <mroos@xxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sunhme: SBUS QFE not detected anymore
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sunhme: SBUS QFE not detected anymore
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Signal handler arguments
  • From: Elad Lahav <e2lahav@xxxxxxxxx>
• Re: Signal handler arguments
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 08/25] [sparc] BUG to BUG_ON changes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 08/25] [sparc] BUG to BUG_ON changes
  • From: Stoyan Gaydarov <stoyboyker@xxxxxxxxx>
• Re: Signal handler arguments
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Signal handler arguments
  • From: Elad Lahav <elad_lahav@xxxxxxxxxxxxxxxxxxxxx>
• Re: Signal handler arguments
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: inconsistent lock state in 2.6.29-rc6
  • From: Meelis Roos <mroos@xxxxxxxx>
• Signal handler arguments
  • From: Elad Lahav <elad_lahav@xxxxxxxxxxxxxxxxxxxxx>
• Re: sunhme: SBUS QFE not detected anymore
  • From: David Miller <davem@xxxxxxxxxxxxx>
• sunhme: SBUS QFE not detected anymore
  • From: Friedrich Oslage <bluebird@xxxxxxxxxx>
• Re: Sunfire V880 and 480R 2.6.27.x startup hangs
  • From: Hermann Lauer <Hermann.Lauer@xxxxxxxxxxxxxxxxxxxxx>
• Re: Sunfire V880 and 480R 2.6.27.x startup hangs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: esp scsi problem on shutdown - sunhme related?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• esp scsi problem on shutdown - sunhme related?
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH] sparc64: wait_event_interruptible_timeout may return -ERESTARTSYS
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] jsflash: stop defining MAJOR_NR
  • From: David Miller <davem@xxxxxxxxxxxxx>
• inconsistent lock state in 2.6.29-rc6
  • From: Meelis Roos <mroos@xxxxxxxx>
• esp scsi problem on shutdown
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: Sean MacLennan <smaclennan@xxxxxxxxxxxx>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PULL] cpumask updates for sparc
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: "leds: Add openfirmware platform device support" breaks sparc
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• "leds: Add openfirmware platform device support" breaks sparc
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH] sparc64: wait_event_interruptible_timeout may return -ERESTARTSYS
  • From: Roel Kluin <roel.kluin@xxxxxxxxx>
• Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Roland McGrath <roland@xxxxxxxxxx>
• [PATCH] jsflash: stop defining MAJOR_NR
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
• Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• 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: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
  • From: Roland McGrath <roland@xxxxxxxxxx>
• [GIT]: Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>