* HP Jornada 600-series bisected
@ 2008-11-19 23:15 Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-19 23:15 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 15178 bytes --]
Greetings,
I've started bisecting it after finding v2.6.26(-hpc)
working nicely. However after bisecting awhile I ran
into a problem where the serial would startup then
panic and finally reboot (cold reboot).
It's not the exact problem I have in v2.6.27(-hpc)
but most likely related.
I cannot paste the entire log since it's 109 pages (!)
but here's the start of it:
Linux version 2.6.27-rc3-hpc (kristoffer@BoTux) (gcc version 3.4.5) #4 PREEMPT Thu Nov 20 00:58:23 CET 2008
Boot params:
... MOUNT_ROOT_RDONLY - 00000000
... RAMDISK_FLAGS - ffffffff
... ORIG_ROOT_DEV - ffffffff
... LOADER_TYPE - 00000001
... INITRD_START - ffffffff
... INITRD_SIZE - ffffffff
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem=16M console=ttySC1,115200
PID hash table entries: 64 (order: 6, 256 bytes)
Using tmu for system timer
Using 5.528 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13316k/16384k available (2177k kernel code, 541k data, 92k init)
Calibrating delay loop... 64.25 BogoMIPS (lpj=128512)
Mount-cache hash table entries: 512
CPU: SH7729
net_namespace: 288 bytes
NET: Registered protocol family 16
SCSI subsystem initialized
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
HD64461: enabling PCMCIA devices
msgmni has been set to 26
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 80x30
fb0: Hitachi HD64461 frame buffer device
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xfffffe80 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 59) is a scif
console [ttySC1] enabled
sh-sci: ttySC2 at MMIO 0xa4000140 (irq = 55) is a irda
loop: module loaded
Driver 'sd' needs updating - please use bus_type methods
scsi0 : pata_platform
ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pc = 00000000
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:
Pid : 0, Comm: swapper
PC is at 0x0
PC : 00000000 SP : 8d291f54 SR : 400001f1 TEA : 00000000 Not tainted
R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
R4 : 0000004d R5 : 8d29970c R6 : 00000019 R7 : ffffffff
R8 : 8d2cec0c R9 : 00000000 R10 : 00000034 R11 : 8d2c009c
R12 : 8d21bb80 R13 : 8d2c005c R14 : 8d013cc0
MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
Call trace:
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d066130>] quicklist_trim+0x0/0x120
[<8d003690>] do_IRQ+0x0/0x60
[<8d003730>] default_idle+0x0/0xd0
[<8d066130>] quicklist_trim+0x0/0x120
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d013cc0>] printk+0x0/0x20
[<8d003782>] default_idle+0x52/0xd0
[<8d003854>] cpu_idle+0x54/0xb0
[<8d2a994e>] start_kernel+0x4ee/0x560
[<8d2ae4f0>] __alloc_bootmem+0x0/0x10
[<8d0e7810>] strlen+0x0/0x60
[<8d002024>] _stext+0x24/0x30
Process: swapper (pid: 0, stack limit = 8d290001)
Stack: (0x8d291f54 to 0x8d292000)
1f40: 8d0070e8 8d066130 8d003690
1f60: ffffffff 00000000 00000000 10000000 50000100 8d2c9fa8 00000000 00000019
1f80: ffffffff 8d003730 ffffffff 8d066130 8d2c009c 8d21bb80 8d2c005c 8d013cc0
1fa0: 8d291fc4 8d003782 8d003854 50000101 8c009800 000071c6 00000000 ffffffff
1fc0: ffffffff 8d2a994e 8d2c006c 8d2ae4f0 8d0e7810 8d2b93d4 8d293dd3 8d2b9598
1fe0: 8d002024 00000000 eeed8cbe 00000000 56125511 64123128 6103d30e 2019e1e0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pc = 00000000
*pde = 00000000
Oops: 0000 [#2]
Modules linked in:
Pid : 0, Comm: swapper
PC is at 0x0
PC : 00000000 SP : 8d291dc0 SR : 400001f1 TEA : 00000000 Tainted: G D
R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
R4 : 0000004d R5 : 8d29970c R6 : ffffffff R7 : 00000020
R8 : 8d2cec0c R9 : 8d291f64 R10 : 00000034 R11 : 8d255cec
R12 : 8d0efca0 R13 : 8d291f34 R14 : 8d013cc0
MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
Call trace:
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d003690>] do_IRQ+0x0/0x60
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d005cd6>] die+0xa6/0x180
[<8d005cca>] die+0x9a/0x180
[<8d00b08c>] do_page_fault+0x1ac/0x390
[<8d013cc0>] printk+0x0/0x20
[<8d00c3f2>] place_entity+0x82/0xf0
[<8d00c690>] enqueue_task_fair+0xa0/0xf0
[<8d00cff2>] enqueue_task+0x12/0x20
[<8d00cff2>] enqueue_task+0x12/0x20
[<8d00d100>] activate_task+0x20/0x40
[<8d00d646>] try_to_wake_up+0xc6/0x100
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d013cc0>] printk+0x0/0x20
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d013cc0>] printk+0x0/0x20
[<8d0036c4>] do_IRQ+0x34/0x60
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d066130>] quicklist_trim+0x0/0x120
[<8d003690>] do_IRQ+0x0/0x60
[<8d003730>] default_idle+0x0/0xd0
[<8d066130>] quicklist_trim+0x0/0x120
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d013cc0>] printk+0x0/0x20
[<8d003782>] default_idle+0x52/0xd0
[<8d003854>] cpu_idle+0x54/0xb0
[<8d2a994e>] start_kernel+0x4ee/0x560
[<8d2ae4f0>] __alloc_bootmem+0x0/0x10
[<8d0e7810>] strlen+0x0/0x60
[<8d002024>] _stext+0x24/0x30
Process: swapper (pid: 0, stack limit = 8d290001)
Stack: (0x8d291dc0 to 0x8d292000)
1dc0: 8d0070e8 00000000 8d003690 ffffffff 00000000 00000000 40000100 000000f0
1de0: 00000080 00001140 ffffffff 00000020 8d013cc0 8d291ef4 00000000 8d255cec
1e00: 8d0efca0 8d291f34 8d013cc0 8d291e30 8d005cd6 8d005cca 40000100 8c009800
1e20: 000071c6 00000000 ffffffff ffffffff 8d00b08c 8d291ef4 8d293000 00000000
1e40: 8d013cc0 00000000 00000000 00000000 00000000 8d291e54 8d00c3f2 8d291e70
1e60: 8d315a7c 8d2c1fb4 00000000 8d00c690 8d291e8c 8d2c1f84 8d2c1fb4 8d315a50
1e80: 00000000 8d315a7c 8d2c1fe0 00000001 8d00cff2 8d291eb0 00000003 8d00cff2
1ea0: 8d291eb0 8d2c1f84 8d315a50 8d315a90 8d00d100 8d291ebc 8d00d646 8d291ec8
1ec0: 8d315a50 8d2c2340 00000000 00030001 8d291ee4 8d0070e0 8d013cc0 8d2c005c
1ee0: 8d21bb80 8d2c009c 8d0070e0 00000000 00000000 0000004d 00000000 8d2c1a98
1f00: 0000000f 0000004d 8d29970c 00000019 ffffffff 8d2cec0c 00000000 00000034
1f20: 8d2c009c 8d21bb80 8d2c005c 8d013cc0 8d291f54 00000000 8d0036c4 400001f1
1f40: 8c009800 000071c6 000010d8 ffffffff 00000040 8d0070e8 8d066130 8d003690
1f60: ffffffff 00000000 00000000 10000000 50000100 8d2c9fa8 00000000 00000019
1f80: ffffffff 8d003730 ffffffff 8d066130 8d2c009c 8d21bb80 8d2c005c 8d013cc0
1fa0: 8d291fc4 8d003782 8d003854 50000101 8c009800 000071c6 00000000 ffffffff
1fc0: ffffffff 8d2a994e 8d2c006c 8d2ae4f0 8d0e7810 8d2b93d4 8d293dd3 8d2b9598
1fe0: 8d002024 00000000 eeed8cbe 00000000 56125511 64123128 6103d30e 2019e1e0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pc = 00000000
*pde = 00000000
Oops: 0000 [#3]
Modules linked in:
Pid : 0, Comm: swapper
PC is at 0x0
PC : 00000000 SP : 8d291c2c SR : 400001f1 TEA : 00000000 Tainted: G D
R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
R4 : 0000004d R5 : 8d29970c R6 : ffffffff R7 : 00000020
R8 : 8d2cec0c R9 : 8d291dd0 R10 : 00000034 R11 : 8d255cec
R12 : 8d0efca0 R13 : 8d291da0 R14 : 8d013cc0
MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
Call trace:
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d003690>] do_IRQ+0x0/0x60
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d005cd6>] die+0xa6/0x180
[<8d005cca>] die+0x9a/0x180
[<8d00b08c>] do_page_fault+0x1ac/0x390
[<8d013cc0>] printk+0x0/0x20
[<8d013cd0>] printk+0x10/0x20
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d03a2b8>] __print_symbol+0x18/0x30
[<8d0132c4>] __call_console_drivers+0x54/0x70
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d0036c4>] do_IRQ+0x34/0x60
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d003690>] do_IRQ+0x0/0x60
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d005cd6>] die+0xa6/0x180
[<8d005cca>] die+0x9a/0x180
[<8d00b08c>] do_page_fault+0x1ac/0x390
[<8d013cc0>] printk+0x0/0x20
[<8d00c3f2>] place_entity+0x82/0xf0
[<8d00c690>] enqueue_task_fair+0xa0/0xf0
[<8d00cff2>] enqueue_task+0x12/0x20
[<8d00cff2>] enqueue_task+0x12/0x20
[<8d00d100>] activate_task+0x20/0x40
[<8d00d646>] try_to_wake_up+0xc6/0x100
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d013cc0>] printk+0x0/0x20
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d013cc0>] printk+0x0/0x20
[<8d0036c4>] do_IRQ+0x34/0x60
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d066130>] quicklist_trim+0x0/0x120
[<8d003690>] do_IRQ+0x0/0x60
[<8d003730>] default_idle+0x0/0xd0
[<8d066130>] quicklist_trim+0x0/0x120
[<8d21bb80>] __sched_text_start+0x0/0x4b0
[<8d013cc0>] printk+0x0/0x20
[<8d003782>] default_idle+0x52/0xd0
[<8d003854>] cpu_idle+0x54/0xb0
[<8d2a994e>] start_kernel+0x4ee/0x560
[<8d2ae4f0>] __alloc_bootmem+0x0/0x10
[<8d0e7810>] strlen+0x0/0x60
[<8d002024>] _stext+0x24/0x30
Process: swapper (pid: 0, stack limit = 8d290001)
Stack: (0x8d291c2c to 0x8d292000)
1c20: 8d0070e8 00000000 8d003690 ffffffff 00000000
1c40: 00000000 40000100 000000f0 00000080 00001ef2 ffffffff 00000020 8d013cc0
1c60: 8d291d60 00000000 8d255cec 8d0efca0 8d291da0 8d013cc0 8d291c9c 8d005cd6
1c80: 8d005cca 40000100 8c009800 000071c6 00000000 ffffffff ffffffff 8d00b08c
1ca0: 8d291d60 8d293000 00000000 8d013cc0 00000000 00000000 00000000 00000000
1cc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000010
1d00: 00000004 000000f0 8d013cd0 8d013cc0 8d291f34 8d0efca0 8d255cec 8d291f34
1d20: 8d013cc0 8d255254 8d03a2b8 8d291d38 00000000 00000000 00030001 8d0132c4
1d40: 8d0070e0 8d013cc0 8d291f34 8d0efca0 8d255cec 8d0070e0 00000000 00000000
1d60: 0000004d 00000000 8d2c1a98 0000000f 0000004d 8d29970c ffffffff 00000020
1d80: 8d2cec0c 8d291f64 00000034 8d255cec 8d0efca0 8d291f34 8d013cc0 8d291dc0
1da0: 00000000 8d0036c4 400001f1 8c009800 000071c6 000010d8 ffffffff 00000040
1dc0: 8d0070e8 00000000 8d003690 ffffffff 00000000 00000000 40000100 000000f0
1de0: 00000080 00001140 ffffffff 00000020 8d013cc0 8d291ef4 00000000 8d255cec
1e00: 8d0efca0 8d291f34 8d013cc0 8d291e30 8d005cd6 8d005cca 40000100 8c009800
1e20: 000071c6 00000000 ffffffff ffffffff 8d00b08c 8d291ef4 8d293000 00000000
1e40: 8d013cc0 00000000 00000000 00000000 00000000 8d291e54 8d00c3f2 8d291e70
1e60: 8d315a7c 8d2c1fb4 00000000 8d00c690 8d291e8c 8d2c1f84 8d2c1fb4 8d315a50
1e80: 00000000 8d315a7c 8d2c1fe0 00000001 8d00cff2 8d291eb0 00000003 8d00cff2
1ea0: 8d291eb0 8d2c1f84 8d315a50 8d315a90 8d00d100 8d291ebc 8d00d646 8d291ec8
1ec0: 8d315a50 8d2c2340 00000000 00030001 8d291ee4 8d0070e0 8d013cc0 8d2c005c
1ee0: 8d21bb80 8d2c009c 8d0070e0 00000000 00000000 0000004d 00000000 8d2c1a98
1f00: 0000000f 0000004d 8d29970c 00000019 ffffffff 8d2cec0c 00000000 00000034
1f20: 8d2c009c 8d21bb80 8d2c005c 8d013cc0 8d291f54 00000000 8d0036c4 400001f1
1f40: 8c009800 000071c6 000010d8 ffffffff 00000040 8d0070e8 8d066130 8d003690
1f60: ffffffff 00000000 00000000 10000000 50000100 8d2c9fa8 00000000 00000019
1f80: ffffffff 8d003730 ffffffff 8d066130 8d2c009c 8d21bb80 8d2c005c 8d013cc0
1fa0: 8d291fc4 8d003782 8d003854 50000101 8c009800 000071c6 00000000 ffffffff
1fc0: ffffffff 8d2a994e 8d2c006c 8d2ae4f0 8d0e7810 8d2b93d4 8d293dd3 8d2b9598
1fe0: 8d002024 00000000 eeed8cbe 00000000 56125511 64123128 6103d30e 2019e1e0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pc = 00000000
*pde = 00000000
Oops: 0000 [#4]
Modules linked in:
Pid : 0, Comm: swapper
PC is at 0x0
PC : 00000000 SP : 8d291a98 SR : 400001f1 TEA : 00000000 Tainted: G D
R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
R4 : 0000004d R5 : 8d29970c R6 : ffffffff R7 : 00000020
R8 : 8d2cec0c R9 : 8d291c3c R10 : 00000034 R11 : 8d255cec
R12 : 8d0efca0 R13 : 8d291c0c R14 : 8d013cc0
MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
Call trace:
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d003690>] do_IRQ+0x0/0x60
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d005cd6>] die+0xa6/0x180
[<8d005cca>] die+0x9a/0x180
[<8d00b08c>] do_page_fault+0x1ac/0x390
[<8d013cc0>] printk+0x0/0x20
[<8d0ee1d2>] vsnprintf+0x3e2/0x640
[<8d013cd0>] printk+0x10/0x20
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d03a2b8>] __print_symbol+0x18/0x30
[<8d0132c4>] __call_console_drivers+0x54/0x70
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d0036c4>] do_IRQ+0x34/0x60
[<8d0070e8>] ret_from_irq+0x0/0x10
[<8d003690>] do_IRQ+0x0/0x60
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d005cd6>] die+0xa6/0x180
[<8d005cca>] die+0x9a/0x180
[<8d00b08c>] do_page_fault+0x1ac/0x390
[<8d013cc0>] printk+0x0/0x20
[<8d013cd0>] printk+0x10/0x20
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d03a2b8>] __print_symbol+0x18/0x30
[<8d0132c4>] __call_console_drivers+0x54/0x70
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d013cc0>] printk+0x0/0x20
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d0070e0>] ret_from_exception+0x0/0x8
[<8d0efca0>] bust_spinlocks+0x0/0x50
[<8d013cc0>] printk+0x0/0x20
[<8d0036c4>] do_IRQ+0x34/0x60
[<8d0070e8>] ret_from_irq+0x0/0x10
...........................
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
@ 2008-11-21 7:34 ` Paul Mundt
2008-11-21 10:08 ` Kristoffer Ericson
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-21 7:34 UTC (permalink / raw)
To: linux-sh
On Thu, Nov 20, 2008 at 01:16:00AM +0100, Kristoffer Ericson wrote:
> HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
> HD64461: enabling PCMCIA devices
[snip]
> scsi0 : pata_platform
> ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pc = 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in:
>
> Pid : 0, Comm: swapper
> PC is at 0x0
> PC : 00000000 SP : 8d291f54 SR : 400001f1 TEA : 00000000 Not tainted
> R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
> R4 : 0000004d R5 : 8d29970c R6 : 00000019 R7 : ffffffff
> R8 : 8d2cec0c R9 : 00000000 R10 : 00000034 R11 : 8d2c009c
> R12 : 8d21bb80 R13 : 8d2c005c R14 : 8d013cc0
> MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
>
> Call trace:
> [<8d0070e8>] ret_from_irq+0x0/0x10
> [<8d066130>] quicklist_trim+0x0/0x120
> [<8d003690>] do_IRQ+0x0/0x60
> [<8d003730>] default_idle+0x0/0xd0
> [<8d066130>] quicklist_trim+0x0/0x120
> [<8d21bb80>] __sched_text_start+0x0/0x4b0
> [<8d013cc0>] printk+0x0/0x20
> [<8d003782>] default_idle+0x52/0xd0
> [<8d003854>] cpu_idle+0x54/0xb0
> [<8d2a994e>] start_kernel+0x4ee/0x560
> [<8d2ae4f0>] __alloc_bootmem+0x0/0x10
> [<8d0e7810>] strlen+0x0/0x60
> [<8d002024>] _stext+0x24/0x30
On Thu, Nov 20, 2008 at 06:04:48PM +0100, Kristoffer Ericson wrote:
> 5093c9a4e41518425d42c0bb5bb92f514ec77b1d is first bad commit
> commit 5093c9a4e41518425d42c0bb5bb92f514ec77b1d
> Author: Paul Mundt <lethal@linux-sh.org>
> Date: Mon Aug 4 14:17:13 2008 +0900
>
> sh: define GENERIC_HARDIRQS_NO__DO_IRQ.
>
> We haven't called in to __do_IRQ() in a long time, so it seems like a
> reasonable time to switch this on by default.
>
> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>
> :040000 040000 cf3a9f428a81b93dcdc7d8da101ef722b6e0159e 563fcba3d9482fd80e8f4f9b02178eb17567bbb7 M arch
>
> Paul, thoughts about this?
>
The only relevant change here is the dispatch in include/linux/irq.h.
With this patch reverted, the call goes through __do_IRQ() if there is no
desc->handle_irq(). Given that the hd64461 code maps the vector that
blows up, the implication is that the hd64461 interrupt code is broken.
Indeed, looking at the code, I suspect it is the demux that is where the
problem comes from, given that the hd64461 irq code does its own special
thing and completely bypasses the generic hardirq layer for chained
handlers.
So, pending a rewrite of hd64461, we should probably just leave the
__do_IRQ() dispatch as an option there, until someone gets around to
rewriting that mess. I will conditionalize it on !HD64461 for now.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
@ 2008-11-21 10:08 ` Kristoffer Ericson
2008-11-22 16:49 ` Matt Fleming
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-21 10:08 UTC (permalink / raw)
To: linux-sh
Appreciate it.
As I said the other bug (the complete cold reboot) was my hd64461-mfd
driver's fault. I've fixed it now, seemed to be caused by
hd64461 io functions being used without the base adress being
initialized (doh!).
So far the hd64461-mfd handles the IRQ's and io functions, I'm working
on integrating the framebuffer. So the driver is progressing
although alot slower than I expect (mfd's are alot more complex than
I first realized).
Best wishes
Kristoffer
2008/11/21, Paul Mundt <lethal@linux-sh.org>:
> On Thu, Nov 20, 2008 at 01:16:00AM +0100, Kristoffer Ericson wrote:
>> HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
>> HD64461: enabling PCMCIA devices
> [snip]
>> scsi0 : pata_platform
>> ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 00000000
>> pc = 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> Modules linked in:
>>
>> Pid : 0, Comm: swapper
>> PC is at 0x0
>> PC : 00000000 SP : 8d291f54 SR : 400001f1 TEA : 00000000 Not tainted
>> R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
>> R4 : 0000004d R5 : 8d29970c R6 : 00000019 R7 : ffffffff
>> R8 : 8d2cec0c R9 : 00000000 R10 : 00000034 R11 : 8d2c009c
>> R12 : 8d21bb80 R13 : 8d2c005c R14 : 8d013cc0
>> MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
>>
>> Call trace:
>> [<8d0070e8>] ret_from_irq+0x0/0x10
>> [<8d066130>] quicklist_trim+0x0/0x120
>> [<8d003690>] do_IRQ+0x0/0x60
>> [<8d003730>] default_idle+0x0/0xd0
>> [<8d066130>] quicklist_trim+0x0/0x120
>> [<8d21bb80>] __sched_text_start+0x0/0x4b0
>> [<8d013cc0>] printk+0x0/0x20
>> [<8d003782>] default_idle+0x52/0xd0
>> [<8d003854>] cpu_idle+0x54/0xb0
>> [<8d2a994e>] start_kernel+0x4ee/0x560
>> [<8d2ae4f0>] __alloc_bootmem+0x0/0x10
>> [<8d0e7810>] strlen+0x0/0x60
>> [<8d002024>] _stext+0x24/0x30
>
> On Thu, Nov 20, 2008 at 06:04:48PM +0100, Kristoffer Ericson wrote:
>> 5093c9a4e41518425d42c0bb5bb92f514ec77b1d is first bad commit
>> commit 5093c9a4e41518425d42c0bb5bb92f514ec77b1d
>> Author: Paul Mundt <lethal@linux-sh.org>
>> Date: Mon Aug 4 14:17:13 2008 +0900
>>
>> sh: define GENERIC_HARDIRQS_NO__DO_IRQ.
>>
>> We haven't called in to __do_IRQ() in a long time, so it seems like a
>> reasonable time to switch this on by default.
>>
>> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>>
>> :040000 040000 cf3a9f428a81b93dcdc7d8da101ef722b6e0159e
>> 563fcba3d9482fd80e8f4f9b02178eb17567bbb7 M arch
>>
>> Paul, thoughts about this?
>>
> The only relevant change here is the dispatch in include/linux/irq.h.
> With this patch reverted, the call goes through __do_IRQ() if there is no
> desc->handle_irq(). Given that the hd64461 code maps the vector that
> blows up, the implication is that the hd64461 interrupt code is broken.
> Indeed, looking at the code, I suspect it is the demux that is where the
> problem comes from, given that the hd64461 irq code does its own special
> thing and completely bypasses the generic hardirq layer for chained
> handlers.
>
> So, pending a rewrite of hd64461, we should probably just leave the
> __do_IRQ() dispatch as an option there, until someone gets around to
> rewriting that mess. I will conditionalize it on !HD64461 for now.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
2008-11-21 10:08 ` Kristoffer Ericson
@ 2008-11-22 16:49 ` Matt Fleming
2008-11-25 17:40 ` Kristoffer Ericson
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Matt Fleming @ 2008-11-22 16:49 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
>
> So, pending a rewrite of hd64461, we should probably just leave the
> __do_IRQ() dispatch as an option there, until someone gets around to
> rewriting that mess. I will conditionalize it on !HD64461 for now.
Kristoffer can you try the attached patch, please? It compiles OK but I
haven't had chance to test it on actual hardware.
[-- Attachment #2: 0001-sh-Switch-HD64461-from-hw_interrupt_type-to-irq_chi.patch --]
[-- Type: text/plain, Size: 5075 bytes --]
From 7258c0f9c1a2cf01a87d67d6221daf6dd79fa3e8 Mon Sep 17 00:00:00 2001
From: Matt Fleming <mjf@gentoo.org>
Date: Sat, 22 Nov 2008 16:24:35 +0000
Subject: [PATCH] sh: Switch HD64461 from hw_interrupt_type to irq_chip
Use struct irq_chip for the interrupt handler for the HD64461. Also
convert some in{b,w} and out{b,w} calls to the equivalent __raw_* calls.
This is the first step to allow machines with HD64461 to define
GENERIC_HARDIRQS_NO__DO_IRQ.
Signed-off-by: Matt Fleming <mjf@gentoo.org>
---
arch/sh/cchips/hd6446x/hd64461.c | 111 ++++++++-----------------------------
1 files changed, 24 insertions(+), 87 deletions(-)
diff --git a/arch/sh/cchips/hd6446x/hd64461.c b/arch/sh/cchips/hd6446x/hd64461.c
index f1a4a07..a550833 100644
--- a/arch/sh/cchips/hd6446x/hd64461.c
+++ b/arch/sh/cchips/hd6446x/hd64461.c
@@ -17,90 +17,42 @@
/* This belongs in cpu specific */
#define INTC_ICR1 0xA4140010UL
-static void disable_hd64461_irq(unsigned int irq)
+static void hd64461_mask_irq(unsigned int irq)
{
unsigned short nimr;
unsigned short mask = 1 << (irq - HD64461_IRQBASE);
- nimr = inw(HD64461_NIMR);
+ nimr = __raw_readw(HD64461_NIMR);
nimr |= mask;
- outw(nimr, HD64461_NIMR);
+ __raw_writew(nimr, HD64461_NIMR);
}
-static void enable_hd64461_irq(unsigned int irq)
+static void hd64461_unmask_irq(unsigned int irq)
{
unsigned short nimr;
unsigned short mask = 1 << (irq - HD64461_IRQBASE);
- nimr = inw(HD64461_NIMR);
+ nimr = __raw_readw(HD64461_NIMR);
nimr &= ~mask;
- outw(nimr, HD64461_NIMR);
+ __raw_writew(nimr, HD64461_NIMR);
}
-static void mask_and_ack_hd64461(unsigned int irq)
+static void hd64461_mask_and_ack_irq(unsigned int irq)
{
- disable_hd64461_irq(irq);
+ hd64461_mask_irq(irq);
#ifdef CONFIG_HD64461_ENABLER
if (irq == HD64461_IRQBASE + 13)
- outb(0x00, HD64461_PCC1CSCR);
+ __raw_writeb(0x00, HD64461_PCC1CSCR);
#endif
}
-static void end_hd64461_irq(unsigned int irq)
-{
- if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
- enable_hd64461_irq(irq);
-}
-
-static unsigned int startup_hd64461_irq(unsigned int irq)
-{
- enable_hd64461_irq(irq);
- return 0;
-}
-
-static void shutdown_hd64461_irq(unsigned int irq)
-{
- disable_hd64461_irq(irq);
-}
-
-static struct hw_interrupt_type hd64461_irq_type = {
- .typename = "HD64461-IRQ",
- .startup = startup_hd64461_irq,
- .shutdown = shutdown_hd64461_irq,
- .enable = enable_hd64461_irq,
- .disable = disable_hd64461_irq,
- .ack = mask_and_ack_hd64461,
- .end = end_hd64461_irq,
+static struct irq_chip hd64461_irq_chip = {
+ .name = "HD64461-IRQ",
+ .mask = hd64461_mask_irq,
+ .mask_ack = hd64461_mask_and_ack_irq,
+ .unmask = hd64461_unmask_irq,
};
-static irqreturn_t hd64461_interrupt(int irq, void *dev_id)
-{
- printk(KERN_INFO
- "HD64461: spurious interrupt, nirr: 0x%x nimr: 0x%x\n",
- inw(HD64461_NIRR), inw(HD64461_NIMR));
-
- return IRQ_NONE;
-}
-
-static struct {
- int (*func) (int, void *);
- void *dev;
-} hd64461_demux[HD64461_IRQ_NUM];
-
-void hd64461_register_irq_demux(int irq,
- int (*demux) (int irq, void *dev), void *dev)
-{
- hd64461_demux[irq - HD64461_IRQBASE].func = demux;
- hd64461_demux[irq - HD64461_IRQBASE].dev = dev;
-}
-
-EXPORT_SYMBOL(hd64461_register_irq_demux);
-
-void hd64461_unregister_irq_demux(int irq)
-{
- hd64461_demux[irq - HD64461_IRQBASE].func = 0;
-}
-
EXPORT_SYMBOL(hd64461_unregister_irq_demux);
int hd64461_irq_demux(int irq)
@@ -115,25 +67,11 @@ int hd64461_irq_demux(int irq)
for (bit = 1, i = 0; i < 16; bit <<= 1, i++)
if (nirr & bit)
break;
- if (i == 16)
- irq = CONFIG_HD64461_IRQ;
- else {
- irq = HD64461_IRQBASE + i;
- if (hd64461_demux[i].func != 0) {
- irq = hd64461_demux[i].func(irq, hd64461_demux[i].dev);
- }
- }
+ irq = HD64461_IRQBASE + i;
}
return irq;
}
-static struct irqaction irq0 = {
- .handler = hd64461_interrupt,
- .flags = IRQF_DISABLED,
- .mask = CPU_MASK_NONE,
- .name = "HD64461",
-};
-
int __init setup_hd64461(void)
{
int i;
@@ -146,22 +84,21 @@ int __init setup_hd64461(void)
CONFIG_HD64461_IOBASE, CONFIG_HD64461_IRQ, HD64461_IRQBASE,
HD64461_IRQBASE + 15);
-#if defined(CONFIG_CPU_SUBTYPE_SH7709) /* Should be at processor specific part.. */
- outw(0x2240, INTC_ICR1);
+/* Should be at processor specific part.. */
+#if defined(CONFIG_CPU_SUBTYPE_SH7709)
+ __raw_writew(0x2240, INTC_ICR1);
#endif
- outw(0xffff, HD64461_NIMR);
+ __raw_writew(0xffff, HD64461_NIMR);
/* IRQ 80 -> 95 belongs to HD64461 */
- for (i = HD64461_IRQBASE; i < HD64461_IRQBASE + 16; i++) {
- irq_desc[i].chip = &hd64461_irq_type;
- }
-
- setup_irq(CONFIG_HD64461_IRQ, &irq0);
+ for (i = HD64461_IRQBASE; i < HD64461_IRQBASE + 16; i++)
+ set_irq_chip_and_handler(i, &hd64461_irq_chip,
+ handle_level_irq);
#ifdef CONFIG_HD64461_ENABLER
printk(KERN_INFO "HD64461: enabling PCMCIA devices\n");
- outb(0x4c, HD64461_PCC1CSCIER);
- outb(0x00, HD64461_PCC1CSCR);
+ __raw_writeb(0x4c, HD64461_PCC1CSCIER);
+ __raw_writeb(0x00, HD64461_PCC1CSCR);
#endif
return 0;
--
1.5.6.4
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (2 preceding siblings ...)
2008-11-22 16:49 ` Matt Fleming
@ 2008-11-25 17:40 ` Kristoffer Ericson
2008-11-25 17:54 ` Paul Mundt
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 17:40 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Sat, 22 Nov 2008 16:49:52 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> >
> > So, pending a rewrite of hd64461, we should probably just leave the
> > __do_IRQ() dispatch as an option there, until someone gets around to
> > rewriting that mess. I will conditionalize it on !HD64461 for now.
>
> Kristoffer can you try the attached patch, please? It compiles OK but I
> haven't had chance to test it on actual hardware.
Sorry for the late reply, been having issues with my internet
connection. Anyhow, not sure if this solves anything since
I've already rewritten the IRQ part to be alot more
sensible. Basicly only wanting to get FB going
before I push it upstreams.
What you think Paul?
>
>
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (3 preceding siblings ...)
2008-11-25 17:40 ` Kristoffer Ericson
@ 2008-11-25 17:54 ` Paul Mundt
2008-11-25 18:47 ` Kristoffer Ericson
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-25 17:54 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 07:40:39PM +0100, Kristoffer Ericson wrote:
> On Sat, 22 Nov 2008 16:49:52 +0000
> Matt Fleming <mjf@gentoo.org> wrote:
>
> > On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> > >
> > > So, pending a rewrite of hd64461, we should probably just leave the
> > > __do_IRQ() dispatch as an option there, until someone gets around to
> > > rewriting that mess. I will conditionalize it on !HD64461 for now.
> >
> > Kristoffer can you try the attached patch, please? It compiles OK but I
> > haven't had chance to test it on actual hardware.
>
> Sorry for the late reply, been having issues with my internet
> connection. Anyhow, not sure if this solves anything since
> I've already rewritten the IRQ part to be alot more
> sensible. Basicly only wanting to get FB going
> before I push it upstreams.
>
> What you think Paul?
>
Matt's patch should allow us to fix the __do_IRQ() problem, if you want
to build on top of that, that is fine, but it is still helpful to know
whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
The only problematic thing I see is the lack of the base IRQ factoring,
only the chained handlers for the multiplexed sources are defined. This
is the way it should be, but it is possible that there will have to be
another handler set up to at least get the hd64461 IRQ firing. This is
the basis for that silly i = 16 thing in the old demux code. Any user
that depends on that behaviour deserves to be broken, though.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (4 preceding siblings ...)
2008-11-25 17:54 ` Paul Mundt
@ 2008-11-25 18:47 ` Kristoffer Ericson
2008-11-25 19:50 ` Paul Mundt
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 18:47 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 8081 bytes --]
On Wed, 26 Nov 2008 02:54:26 +0900
Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Nov 25, 2008 at 07:40:39PM +0100, Kristoffer Ericson wrote:
> > On Sat, 22 Nov 2008 16:49:52 +0000
> > Matt Fleming <mjf@gentoo.org> wrote:
> >
> > > On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> > > >
> > > > So, pending a rewrite of hd64461, we should probably just leave the
> > > > __do_IRQ() dispatch as an option there, until someone gets around to
> > > > rewriting that mess. I will conditionalize it on !HD64461 for now.
> > >
> > > Kristoffer can you try the attached patch, please? It compiles OK but I
> > > haven't had chance to test it on actual hardware.
> >
> > Sorry for the late reply, been having issues with my internet
> > connection. Anyhow, not sure if this solves anything since
> > I've already rewritten the IRQ part to be alot more
> > sensible. Basicly only wanting to get FB going
> > before I push it upstreams.
> >
> > What you think Paul?
> >
> Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> to build on top of that, that is fine, but it is still helpful to know
> whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
>
> The only problematic thing I see is the lack of the base IRQ factoring,
> only the chained handlers for the multiplexed sources are defined. This
> is the way it should be, but it is possible that there will have to be
> another handler set up to at least get the hd64461 IRQ firing. This is
> the basis for that silly i == 16 thing in the old demux code. Any user
> that depends on that behaviour deserves to be broken, though.
I've attached the code I got so far. You can atleast see my
approach to the issue.
/*
*
* MFD driver for the Hitachi HD64461 companion chip
*
* HD64461 chip contains 8 interrupts handled by an demuxer
* It controls pcmcia x 2, UART, IRDA, FB.
*
*
* (C) 2008 Kristoffer Ericson <Kristoffer.Ericson@gmail.com>
*
*
*/
#include <linux/sched.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/param.h>
#include <linux/interrupt.h>
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/errno.h>
#include <linux/spinlock.h>
#include <linux/platform_device.h>
#include <linux/hd64461.h>
#include <asm/io.h>
#include <asm/irq.h>
struct hd64461_irq_list *irq_master;
struct hd64461_devdata *hd_master;
void hd64461_io_write16(u16 value, unsigned int reg)
{
iowrite16(value, (hd_master->io_start + reg));
}
void hd64461_io_write8(u8 value, unsigned int reg)
{
iowrite8(value, (hd_master->io_start + reg));
}
u16 hd64461_io_read16(unsigned int reg)
{
return(ioread16(hd_master->io_start + reg));
}
u8 hd64461_io_read8(unsigned int reg)
{
return(ioread8(hd_master->io_start + reg));
}
EXPORT_SYMBOL(hd64461_io_write16);
EXPORT_SYMBOL(hd64461_io_write8);
EXPORT_SYMBOL(hd64461_io_read16);
EXPORT_SYMBOL(hd64461_io_read8);
/*
* hd64461_irq_demask - find out what number our irq_mask equals
*
*
*
* returns number between 1-16
*/
unsigned int hd64461_irq_demask(u16 mask)
{
unsigned int i;
for (i = 1; i < 16; i++)
if ((1 << i) & mask)
break;
return i;
}
/*
* hd64461_irq_set_hand - set handler for hd64461 source
*
*
*
*/
unsigned int hd64461_irq_set_hand(u16 mask, void (*fn)(int, void *))
{
u16 number;
number = hd64461_irq_demask(mask);
if (irq_master->irq[number].fn == NULL)
irq_master->irq[number].fn = fn;
return 0;
}
/*
* hd64461_irq_enable - make the hd64461 source active
*
* !note, handler should be installed before this!
*/
unsigned int hd64461_irq_enable(u16 mask)
{
u16 nimr;
u16 number;
nimr = hd64461_io_read16(HD64461_NIMR);
nimr |= mask;
hd64461_io_write16(nimr, HD64461_NIMR);
number = hd64461_irq_demask(mask);
irq_master->irq[number].irq_enabled = 1;
irq_master->irq[number].irq_mask = mask;
return 0;
}
/*
*
* hd64461_irq_disable - make the hd64461 source inactive
*/
unsigned int hd64461_irq_disable(u16 mask)
{
u16 nimr;
u16 number;
nimr = hd64461_io_read16(HD64461_NIMR);
nimr &= ~mask;
hd64461_io_write16(nimr, HD64461_NIMR);
number = hd64461_irq_demask(mask);
irq_master->irq[number].irq_enabled = 0;
irq_master->irq[number].irq_mask = 0;
/* TODO HANDLER */
return 0;
}
/*
* hd64461_irq_trigger - set irq trigger for hd64461 source
*/
unsigned int hd64461_irq_trigger(u16 mask, u16 trigger_mask)
{
if (!(mask & HD64461_PCC0_MASK) || !(mask & HD64461_PCC1_MASK)) {
printk(KERN_INFO "this interrupt doesn't support trigger settings\n");
return 0;
}
/* TODO */
return 0;
}
void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
{
hd64461_irq_set_hand(mask, fn);
hd64461_irq_trigger(mask, trigger_mask);
hd64461_irq_enable(mask);
}
static irqreturn_t hd64461_irq_handler(int irq, void *devid)
{
unsigned short bit;
int i;
u16 value;
u16 nimr;
value = 0xffff;
printk(KERN_INFO "Entering interrupt!\n");
/* read -> inactivate */
nimr = hd64461_io_read16(HD64461_NIMR);
hd64461_io_write16(value, HD64461_NIMR);
/* run through the source/s and check
* which one is causing the interrupt.
* only run handler if we are sure
* one exists and is enabled (by us).
*/
for (i = 0, bit = 1; i < 16; bit <<= 1, i++)
if (nimr & irq_master->irq[i].irq_mask) {
if (irq_master->irq[i].irq_enabled)
irq_master->irq[i].fn(i, devid);
else
printk(KERN_INFO "spurious interrupt detected from interrupt mask %x\n", irq_master->irq[i].irq_mask);
}
return IRQ_HANDLED;
}
static struct irqaction irq0 = {
.handler = hd64461_irq_handler,
.flags = IRQF_DISABLED,
.mask = CPU_MASK_NONE,
.name = "hd64461-mfd",
};
static int __init hd64461_probe(struct platform_device *pdev)
{
struct resource *res;
unsigned int ret;
ret = -ENOMEM;
printk(KERN_INFO "hd64461-mfd: driver starting\n");
/* Allocate the memory for devdata */
hd_master = kzalloc(sizeof(struct hd64461_devdata), GFP_KERNEL);
if (!hd_master) {
goto fault_0;
}
irq_master = kzalloc(sizeof(struct hd64461_irq_list), GFP_KERNEL);
if (!irq_master) {
goto fault_1;
}
/* We get our IRQ from the driver resource */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res)
goto fault_1;
hd_master->master_irq = res->start;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
goto fault_1;
hd_master->io_start = 0xb0000000;
// hd_master->io_end = res->end;
// ioremap(res->start, (res->end - res->start) - 1);
// platform_set_drvdata(pdev, hd_master);
setup_irq(36, &irq0);
// ret = request_irq(hd_master->master_irq, hd64461_irq_handler, IRQF_DISABLED, "hd64461-mfd", hd_master);
return 0;
fault_0:
return ret;
fault_1:
kfree(hd_master);
return ret;
}
static int __exit hd64461_remove(struct platform_device *pdev)
{
return 0;
}
static struct platform_driver hd64461_mfd_driver = {
.driver = {
.name = "hd64461-mfd",
.owner = THIS_MODULE,
},
.probe = hd64461_probe,
.remove = __exit_p(hd64461_remove),
};
static int __init hd64461_init(void)
{
return platform_driver_probe(&hd64461_mfd_driver, hd64461_probe);
}
static void __exit hd64461_exit(void)
{
platform_driver_unregister(&hd64461_mfd_driver);
}
module_init(hd64461_init)
module_exit(hd64461_exit)
MODULE_AUTHOR("Kristoffer Ericson <kristoffer.ericson@gmail.com>");
MODULE_DESCRIPTION("Core Driver for HD64461");
MODULE_LICENSE("GPL v2");
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (5 preceding siblings ...)
2008-11-25 18:47 ` Kristoffer Ericson
@ 2008-11-25 19:50 ` Paul Mundt
2008-11-25 20:11 ` Matt Fleming
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-25 19:50 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> On Wed, 26 Nov 2008 02:54:26 +0900
> Paul Mundt <lethal@linux-sh.org> wrote:
> > Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> > to build on top of that, that is fine, but it is still helpful to know
> > whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
> >
> > The only problematic thing I see is the lack of the base IRQ factoring,
> > only the chained handlers for the multiplexed sources are defined. This
> > is the way it should be, but it is possible that there will have to be
> > another handler set up to at least get the hd64461 IRQ firing. This is
> > the basis for that silly i = 16 thing in the old demux code. Any user
> > that depends on that behaviour deserves to be broken, though.
>
> I've attached the code I got so far. You can atleast see my
> approach to the issue.
>
The approach you use has all of the same problems as the old code in
terms of how the demux is handled and how it completely sidesteps the
generic hardirq code. Additionally, this is new code, rather than
refactoring existing code. If Matt's patch doesn't work for you, then we
just leave CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ disabled for hd64461. If it
does work however, then you are much better off adopting that code and
including it in your MFD driver. The main thing is to fix what we have
in-tree first.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (6 preceding siblings ...)
2008-11-25 19:50 ` Paul Mundt
@ 2008-11-25 20:11 ` Matt Fleming
2008-11-25 20:19 ` Kristoffer Ericson
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Matt Fleming @ 2008-11-25 20:11 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
>
> unsigned int hd64461_irq_demask(u16 mask)
> {
> unsigned int i;
>
> for (i = 1; i < 16; i++)
> if ((1 << i) & mask)
> break;
>
Is there a reason that this starts from i = 1 and not i = 0?
>
> void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
> {
> hd64461_irq_set_hand(mask, fn);
> hd64461_irq_trigger(mask, trigger_mask);
> hd64461_irq_enable(mask);
> }
I can't find any code in the kernel that registers with the current demux
code. Is this interface still necessary?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (7 preceding siblings ...)
2008-11-25 20:11 ` Matt Fleming
@ 2008-11-25 20:19 ` Kristoffer Ericson
2008-11-25 20:26 ` Kristoffer Ericson
2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 20:19 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]
On Wed, 26 Nov 2008 04:50:11 +0900
Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> > On Wed, 26 Nov 2008 02:54:26 +0900
> > Paul Mundt <lethal@linux-sh.org> wrote:
> > > Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> > > to build on top of that, that is fine, but it is still helpful to know
> > > whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
> > >
> > > The only problematic thing I see is the lack of the base IRQ factoring,
> > > only the chained handlers for the multiplexed sources are defined. This
> > > is the way it should be, but it is possible that there will have to be
> > > another handler set up to at least get the hd64461 IRQ firing. This is
> > > the basis for that silly i == 16 thing in the old demux code. Any user
> > > that depends on that behaviour deserves to be broken, though.
> >
> > I've attached the code I got so far. You can atleast see my
> > approach to the issue.
> >
> The approach you use has all of the same problems as the old code in
> terms of how the demux is handled and how it completely sidesteps the
> generic hardirq code.
I must be missing something. Last time you said that there wasn't
much point in adding a virtual IRQ range, and thats what
I've been avoiding to do. Everything goes into the HD64461_IRQ
which simply sends "notifier"/runs interrupt of the
mask requesting it. Perhaps I misunderstod in what
way you wanted the mfd to notify the driver.
> Additionally, this is new code, rather than
> refactoring existing code.
I can understand that changing existing code is better
than removing->adding new code. But I'm doing this
to get the pcmcia driver inside, which you said wouldn't
happen until the hd64461 was transformed into an MFD driver.
So on one side the hd64461 should be transformed into
an mfd driver and on the other existing approach should
be preserved.
> If Matt's patch doesn't work for you, then we
> just leave CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ disabled for hd64461. If it
> does work however, then you are much better off adopting that code and
> including it in your MFD driver. The main thing is to fix what we have
> in-tree first.
I will test Matt's patch later today and see if it solves it,
It probably will. I mean no disrespect with my comments,
just that its frustrating missing your points all the time.
I don't do this for a living and medical studies doesn't
provide much of a + in these areas.
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (8 preceding siblings ...)
2008-11-25 20:19 ` Kristoffer Ericson
@ 2008-11-25 20:26 ` Kristoffer Ericson
2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 20:26 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
On Tue, 25 Nov 2008 20:11:06 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> >
> > unsigned int hd64461_irq_demask(u16 mask)
> > {
> > unsigned int i;
> >
> > for (i = 1; i < 16; i++)
> > if ((1 << i) & mask)
> > break;
> >
>
> Is there a reason that this starts from i = 1 and not i = 0?
Only 14,12,13,11,10,9,6,5 are actually reporting anything so
it could simply run from 5->14. But this 1->16 has been
used previously, most likely to just point out that
the register is 16bit. The reason I haven't changed it
is the fact that hd64465 got more sources, so locking it
down isn't a good idea.
>
> >
> > void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
> > {
> > hd64461_irq_set_hand(mask, fn);
> > hd64461_irq_trigger(mask, trigger_mask);
> > hd64461_irq_enable(mask);
> > }
>
> I can't find any code in the kernel that registers with the current demux
> code. Is this interface still necessary?
>
The idea is to use it in the coming hd64461 relevant code (pcmcia/fb/...) so
currently nothing is using it. The above code hasn't been applied anywhere.
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (9 preceding siblings ...)
2008-11-25 20:26 ` Kristoffer Ericson
@ 2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-27 19:02 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
On Sat, 22 Nov 2008 16:49:52 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> >
> > So, pending a rewrite of hd64461, we should probably just leave the
> > __do_IRQ() dispatch as an option there, until someone gets around to
> > rewriting that mess. I will conditionalize it on !HD64461 for now.
>
> Kristoffer can you try the attached patch, please? It compiles OK but I
> haven't had chance to test it on actual hardware.
>
>
Seems to have solved the kernel panics errors, however
get some ATA errors now, weird but alot better than before.
Considering the state before this patch, I'm inclined to
ack it.
/Kristoffer
Linux version 2.6.28-rc6-00007-ged31348-dirty (kristoffer@BoTux) (gcc version 3.4.5) #4 Thu No8
Boot params:
... MOUNT_ROOT_RDONLY - 00000000
... RAMDISK_FLAGS - ffffffff
... ORIG_ROOT_DEV - ffffffff
... LOADER_TYPE - 00000001
... INITRD_START - ffffffff
... INITRD_SIZE - ffffffff
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem=16M console=ttySC1,115200
PID hash table entries: 64 (order: 6, 256 bytes)
Using tmu for system timer
Using 5.528 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13896k/16384k available (1286k kernel code, 380k data, 76k init)
Calibrating delay loop (skipped)... 132.66 BogoMIPS PRESET (lpj=265320)
Mount-cache hash table entries: 512
CPU: SH7729
SCSI subsystem initialized
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
HD64461: enabling PCMCIA devices
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 80x30
fb0: Hitachi HD64461 frame buffer device
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xfffffe80 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 59) is a scif
console [ttySC1] enabled
sh-sci: ttySC2 at MMIO 0xa4000140 (irq = 55) is a irda
Driver 'sd' needs updating - please use bus_type methods
scsi0 : pata_platform
ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
ata1.00: CFA: SanDisk SDCFH-256, HDX 2.15, max PIO4
ata1.00: 501760 sectors, multi 0: LBA
ata1.00: configured for PIO
scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFH-25 HDX PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 501760 512-byte hardware sectors: (256 MB/245 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 501760 512-byte hardware sectors: (256 MB/245 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
................
................
................
ata1.00: cmd 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for PIO
ata1: EH complete
ata1.00: limiting speed to UDMA7:PIO5
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: cmd 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
......................
......................
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
ata1: EH complete
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI removable disk
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-11-27 19:02 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
2008-11-21 10:08 ` Kristoffer Ericson
2008-11-22 16:49 ` Matt Fleming
2008-11-25 17:40 ` Kristoffer Ericson
2008-11-25 17:54 ` Paul Mundt
2008-11-25 18:47 ` Kristoffer Ericson
2008-11-25 19:50 ` Paul Mundt
2008-11-25 20:11 ` Matt Fleming
2008-11-25 20:19 ` Kristoffer Ericson
2008-11-25 20:26 ` Kristoffer Ericson
2008-11-27 19:02 ` Kristoffer Ericson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox