--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: linux-image-2.6-sparc32: kernel panic when module sd_mod is loaded before esp
- From: "nobody" <nobody@crans.org>
- Date: Fri, 13 Apr 2007 14:11:22 +0200
- Message-id: <20070413121122.1935.11509.reportbug@vigile>
Package: linux-image-2.6-sparc32
Version: 2.6.18+6
Severity: critical
Justification: breaks the whole system
Loading module esp after sd_mod on a Sparc 4 causes a kernel panic.
The behaviour is the same when the modules are loaded at boot time,
and when the modules are manually loaded afterwards.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: sparc
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-sparc32
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Versions of packages linux-image-2.6-sparc32 depends on:
ii linux-image-2.6.18-4-sp 2.6.18.dfsg.1-12 Linux 2.6.18 image on uniprocessor
linux-image-2.6-sparc32 recommends no packages.
-- debconf information excluded
Loaded kernel version 2.6.18
Loading initial ramdisk (3146207 bytes at 0x1000000 phys, 0x60000000 virt)...
PROMLIB: obio_ranges 1
Booting Linux...
PROMLIB: Sun Boot Prom Version 3 Revision 2
Linux version 2.6.18-4-sparc32 (Debian 2.6.18.dfsg.1-12) (waldi@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Mon Mar 26 09:46:52 UTC 2007
ARCH: SUN4M
TYPE: SPARCstation 4
Ethernet address: 8:0:20:81:f5:45
Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz). Patching kernel for srmmu[Fujitsu Swift]/iommu
PROM: Built device tree with 19953 bytes of memory.
Power off control detected.
Built 1 zonelists. Total pages: 14938
Kernel command line: root=/dev/sda1 ro break=mount
PID hash table entries: 256 (order: 8, 1024 bytes)
start_kernel(): bug: interrupts were enabled early
Console: colour dummy device 80x25
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 56888k/65204k available (1636k kernel code, 8252k reserved, 400k data, 136k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs... it is
Freeing initrd memory: 3072k freed
NET: Registered protocol family 16
IOMMU: impl 0 vers 4 table 0xf3840000[262144 B] map [65536 b]
sbus0: Clock 22.0 MHz
dma0: Revision 2
dma1: Revision 2
NET: Registered protocol family 2
IP route cache hash table entries: 512 (order: -1, 2048 bytes)
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
ioremap: done with statics, switching to malloc
apc: power management initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 144x56
/iommu@0,10000000/sbus@0,10001000/SUNW,tcx@2,800000: TCX at 0:50800000, 8-bit only
ffd35080: ttyS0 at MMIO 0x71100000 (irq = 44) is a zs
Console: ttyS0 (SunZilog zs0)
ffd35080: ttyS1 at MMIO 0x71100004 (irq = 44) is a zs
ffd35134: Keyboard at MMIO 71000000 (irq = 44) is a zs
ffd35134: Mouse at MMIO 71000004 (irq = 44) is a zs
Floppy drive(s): fd0 is 1.44M
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
rtc_sun_init: Registered Mostek RTC driver.
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 136k freed
Loading, please wait...
Begin: Loading essential drivers... ...
SCSI subsystem initialized
esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast)
scsi0 : Sparc ESP100A-FAST
Vendor: QUANTUM Model: FB1080J SUN1.05 Rev: 630E
Type: Direct-Access ANSI SCSI revision: 02
esp0: target 3 [period 100ns offset 8 10.00MHz FAST SCSI-II]
SCSI device sda: 2134305 512-byte hdwr sectors (1093 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through
SCSI device sda: 2134305 512-byte hdwr sectors (1093 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3
sd 0:0:3:0: Attached scsi disk sda
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<a6400310> addr<f0010ac1>
esp0: SW [sreg<11> sstep<04> ireg<18>]
esp0: HW reread [sreg<01> sstep<c4> ireg<00>]
esp0: current command [tgt<03> lun<01> pphase<CLUELESS> cphase<DATAIN>]
esp0: disconnected
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<a6400310> addr<f0010ac1>
esp0: SW [sreg<11> sstep<04> ireg<18>]
esp0: HW reread [sreg<01> sstep<c4> ireg<00>]
esp0: current command [tgt<03> lun<01> pphase<UNISSUED> cphase<UNISSUED>]
esp0: disconnected
esp0: Resetting scsi bus
esp0: Gross error sreg=40
esp0: SCSI bus reset interrupt
esp0: DMA error a440030e
esp0: Resetting scsi bus
esp0: SCSI bus reset interrupt
kernel BUG at arch/sparc/mm/iommu.c:298!
\|/ ____ \|/
"@'/ ,. \`@"
/_| \__/ |_\
\__U_/
swapper(0): Kernel bad trap [#1]
PSR: 04401fc4 PC: f001f914 NPC: f001f918 Y: 00000000 Not tainted
PC: <iommu_release_one+0x30/0x74>
%G: f12e0000 044010e3 f01d15f8 04401fe2 f003046c f022c9d8 f000e000 00000000
%O: 0000002c f01a7e88 0000012a f000fc14 f12e0000 f0228d20 f000fa90 f001f90c
RPC: <iommu_release_one+0x28/0x74>
%L: 04401fc5 f0030df0 f0030e1c 00000080 00000001 00000001 f000e000 0000000a
%I: 21212000 00000001 00000001 000010d3 00000000 00000001 f000faf8 f001f984
Caller[f001f984]: iommu_release_scsi_sgl+0x2c/0x54
Caller[fe642388]: esp_finish_reset+0x24/0xbc [esp]
Caller[fe64488c]: esp_intr+0x2c4/0x310 [esp]
Caller[f0013160]: handler_irq+0x94/0xd4
Caller[f0010bd8]: patch_handler_irq+0x8/0x24
Caller[f0035af0]: __do_softirq+0x28/0xc0
Caller[f0035bc8]: do_softirq+0x40/0x50
Caller[f0010bd8]: patch_handler_irq+0x8/0x24
Caller[f0014a40]: cpu_idle+0xc0/0xfc
Caller[f0204f64]: _etext+0x68134/0x681c8
Caller[f0204790]: _etext+0x67960/0x681c8
Caller[00000000]: 0x8
Instruction DUMP: 9210212a 7fffcb79 90122288 <91d02005> 82260001 8a102000 b330600c 10800009 872e6002
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Press Stop-A (L1-A) to return to the boot prom
--- End Message ---
--- Begin Message ---
- To: 419034-done@bugs.debian.org
- Cc: nobody <nobody@crans.org>
- Subject: Re: linux-image-2.6-sparc32: kernel panic when module sd_mod is loaded before esp
- From: Moritz Muehlenhoff <jmm@inutil.org>
- Date: Sat, 25 Jul 2009 18:19:45 +0200
- Message-id: <20090725161945.GA17676@galadriel.inutil.org>
- In-reply-to: <20081113223427.GA5403@galadriel.inutil.org>
- References: <20070413121122.1935.11509.reportbug@vigile> <20081113223427.GA5403@galadriel.inutil.org>
On Thu, Nov 13, 2008 at 11:34:27PM +0100, Moritz Muehlenhoff wrote:
> On Fri, Apr 13, 2007 at 02:11:22PM +0200, nobody wrote:
> > Package: linux-image-2.6-sparc32
> > Version: 2.6.18+6
> > Severity: critical
> > Justification: breaks the whole system
> >
> > Loading module esp after sd_mod on a Sparc 4 causes a kernel panic.
> > The behaviour is the same when the modules are loaded at boot time,
> > and when the modules are manually loaded afterwards.
>
> Does this error still occur with more recent kernel versions?
>
> If you're running Etch, could you try to reproduce this bug
> with the 2.6.24 based kernel added in 4.0r4?
> http://packages.qa.debian.org/l/linux-2.6.24.html
No further feedback, closing the bug.
If anyone reencounters the problem, please reopen this bug.
Cheers,
Moritz
--- End Message ---