parisc: Changes to ref refs/heads/parisc
Rebased ref, commits from common ancestor:
commit 7da1272547ebe96982a42292dfc833457708f4da
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400
parisc: kill __do_IRQ
commit 8ed5c00d7c166f505eb2e8ff47748bfa73824130
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 01:00:51 2010 -0400
parisc: convert eisa interrupts to flow handlers
commit 7998b3bd156478c35de685f90d4d0dda57916c60
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 00:58:53 2010 -0400
parisc: convert gsc and dino pci interrupts to flow handlers
commit 14ff626a64f1c6848b303254be00b1b2ff33a655
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 00:53:17 2010 -0400
parisc: convert suckyio interrupts to flow handlers
No big deal, just need to convert the suckyio interrupts to be a nested handler instead of request_irq the suckyio device in the future.
commit f3d4605977f9f30993c670a85f75d8f3853144c5
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 00:38:27 2010 -0400
parisc: convert iosapic interrupts to proper flow handlers
Shift the ->end call (cpu eoi) from __do_IRQ into our unmask handler. Also nuke some redundant code.
commit 4d4f681dc43a06167763ec698f5de4f2b3119ad6
Author: Kyle McMartin <[email protected]> Date: Thu Oct 14 00:12:23 2010 -0400
parisc: convert cpu interrupts to proper flow handlers
Only major change is renaming functions to match the conventions expected by the generic irq code.
commit ba20085c20f1c9e8af546dea6ad0efa421bdef32
Author: Kyle McMartin <[email protected]> Date: Wed Oct 13 21:00:55 2010 -0400
parisc: lay groundwork for killing __do_IRQ
Use proper accessors and handlers for generic irq cleanups. We just call back into __do_IRQ through desc->handler now, and remove the explicit calls.
[RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 8 lines · Kyle McMartin
commit
7da1272547ebe96982a42292dfc833457708f4daAuthor: Kyle McMartin <[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400parisc: kill
__do_IRQSigned-off-by Kyle McMartin <[email protected]>
So, I've killed our __do_IRQ calls... Could people please test this branch on a variety of machines? I've split up the changes so there's logical separation between converting the CPU interrupts, and the sub-interrupt sources (Superio, dino, etc.) so if your device fails to interrupt, you can just git revert that bit and test the CPU conversion while I fix it up.
I *think* everything should be ok though, I've tested it on a500/rp3440 class machines with iosapic, but not on anything older.
--Kyle
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 16 lines · Kyle McMartin
Quoted 8 lines · Kyle McMartin
commit
7da1272547ebe96982a42292dfc833457708f4daAuthor: Kyle McMartin<[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400parisc: kill
__do_IRQSigned-off-by Kyle McMartin<[email protected]>So, I've killed our
__do_IRQcalls... Could people please test this branch on a variety of machines? I've split up the changes so there's logical separation between converting the CPU interrupts, and the sub-interrupt sources (Superio, dino, etc.) so if your device fails to interrupt, you can just git revert that bit and test the CPU conversion while I fix it up.
Quoted 2 lines
I *think* everything should be ok though, I've tested it on a500/rp3440 class machines with iosapic, but not on anything older.
c3000 is ok too. But I think it has iosapic as well.
I will try if I can connect the 715/64 and b160L, but I'm not sure if I find time to do it this weekend...
BTW, fanotify* isn't wired up yet:
<stdin>:1526:2: warning: #warning syscall fanotify_init not implemented <stdin>:1530:2: warning: #warning syscall fanotify_mark not implemented
Helge
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 17 lines · Helge Deller
Quoted 16 lines · Kyle McMartin
Quoted 8 lines · Kyle McMartin
commit
7da1272547ebe96982a42292dfc833457708f4daAuthor: Kyle McMartin<[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400parisc: kill
__do_IRQSigned-off-by Kyle McMartin<[email protected]>So, I've killed our
__do_IRQcalls... Could people please test this branch on a variety of machines? I've split up the changes so there's logical separation between converting the CPU interrupts, and the sub-interrupt sources (Superio, dino, etc.) so if your device fails to interrupt, you can just git revert that bit and test the CPU conversion while I fix it up.
Quoted 7 lines
Quoted 2 lines
I *think* everything should be ok though, I've tested it on a500/rp3440 class machines with iosapic, but not on anything older.
c3000 is ok too. But I think it has iosapic as well.
I will try if I can connect the 715/64 and b160L, but I'm not sure if I find time to do it this weekend...
C3000 is a good one since it has SuperIO, I don't remember what devices are behind it (IDE, USB, iirc...) though.
Quoted 4 lines
BTW, fanotify* isn't wired up yet:
<stdin>:1526:2: warning: #warning syscallfanotify_initnot implemented <stdin>:1530:2: warning: #warning syscallfanotify_marknot implemented
It's not enabled in 2.6.36 because of bugs:
commit 7c5347733dcc4ba0bac0baf86d99fae0561f33b7
Author: Eric Paris <[email protected]> Date: Mon Oct 11 18:13:31 2010 -0400
fanotify: disable fanotify syscalls
Thanks for testing, Helge!
--Kyle
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 18 lines · Kyle McMartin
Quoted 17 lines · Helge Deller
Quoted 16 lines · Kyle McMartin
Quoted 8 lines · Kyle McMartin
commit
7da1272547ebe96982a42292dfc833457708f4daAuthor: Kyle McMartin<[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400parisc: kill
__do_IRQSigned-off-by Kyle McMartin<[email protected]>So, I've killed our
__do_IRQcalls... Could people please test this branch on a variety of machines? I've split up the changes so there's logical separation between converting the CPU interrupts, and the sub-interrupt sources (Superio, dino, etc.) so if your device fails to interrupt, you can just git revert that bit and test the CPU conversion while I fix it up.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
I *think* everything should be ok though, I've tested it on a500/rp3440 class machines with iosapic, but not on anything older.
c3000 is ok too. But I think it has iosapic as well.
I will try if I can connect the 715/64 and b160L, but I'm not sure if I find time to do it this weekend...C3000 is a good one since it has SuperIO, I don't remember what devices are behind it (IDE, USB, iirc...) though.
SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 67)
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
And serial works, since I'm running on serial console.... :-)
Helge
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
In reply to Kyle McMartinQuoted 16 lines · Kyle McMartin
Quoted 8 lines · Kyle McMartin
commit
7da1272547ebe96982a42292dfc833457708f4daAuthor: Kyle McMartin<[email protected]> Date: Thu Oct 14 01:02:23 2010 -0400parisc: kill
__do_IRQSigned-off-by Kyle McMartin<[email protected]>So, I've killed our
__do_IRQcalls... Could people please test this branch on a variety of machines? I've split up the changes so there's logical separation between converting the CPU interrupts, and the sub-interrupt sources (Superio, dino, etc.) so if your device fails to interrupt, you can just git revert that bit and test the CPU conversion while I fix it up.
Quoted 2 lines
I *think* everything should be ok though, I've tested it on a500/rp3440 class machines with iosapic, but not on anything older.
Hi Kyle,
I just got again a chance to boot up my b160L and 715/64 machines.
Both broke due to the IRQ changes. I did reverted all of your IRQ patches (based on current Linus head branch) and now they boot again. Basically they just hang during the SCSI initialization (timeouts while detectings discs).
So, there is something wrong for Lasi/GSC and Dino busses....
Any idea?
Helge
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 9 lines · Helge Deller
I just got again a chance to boot up my b160L and 715/64 machines.
Both broke due to the IRQ changes. I did reverted all of your IRQ patches (based on current Linus head branch) and now they boot again.
Basically they just hang during the SCSI initialization (timeouts while detectings discs).
Quoted 4 lines
So, there is something wrong for Lasi/GSC and Dino busses....
Any idea?
No, but I'll take a look, it's probably something simple and stupid that I missed. :/
--Kyle
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 9 lines · Kyle McMartin
Quoted 8 lines · Helge Deller
I just got again a chance to boot up my b160L and 715/64 machines.
Both broke due to the IRQ changes. I did reverted all of your IRQ patches (based on current Linus head branch) and now they boot again.
Basically they just hang during the SCSI initialization (timeouts while detectings discs).
Quoted 6 lines
Quoted 4 lines
So, there is something wrong for Lasi/GSC and Dino busses....
Any idea?
No, but I'll take a look, it's probably something simple and stupid that I missed. :/
I tried to look into it, but I'm somewhat lost.
This is what I get on my B160L.
Same result btw on the 715/64.
Booting...
Network Station Address 080009-ef34f5
System IP Address 192.168.178.65
Server IP Address 192.168.178.50
Boot IO Dependent Code (IODC) revision 2
HARD Booted.
palo ipl 1.13 root@c3000 Mon Apr 3 23:30:38 CEST 2006
Boot image contains:
0/vmlinux32 7688520 bytes @ 0x9800
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'HOME=/ root=/dev/sda3 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=' Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kernelELF32 executable Entry 00100000 first 00100000 n 2
Segment 0 load 00100000 size 6172672 mediaptr 0x1000
Segment 1 load 0072c000 size 311016 mediaptr 0x5e4000
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.6.37-rc2-32bit+ ([email protected]) (gcc version 4.4.1 (GCC) ) #282 Sat Nov 20 22:32:27 CET 2010unwind_init: start = 0x10640000, end = 0x1067f610, entries = 16225
FP[0] enabled: Rev 1 Model 15
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005020 00000481 00000000 02020202 7794d7fe 100000f0 00000004 000000ba 000000ba
vers 00000008
CPUID vers 15 rev 8 (0x000001e8)
capabilities 0x2
model 9000/778/B160L
Total Memory: 128 MB
LED display at f0190001 registered
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlx PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 123100k/131072k available (4152k kernel code, 7972k reserved, 1851k data, 304k init)
virtual kernel memory layout:
vmalloc : 0x00810000 - 0x0f000000 ( 231 MB)
memory : 0x10000000 - 0x18000000 ( 128 MB)
.init : 0x1072c000 - 0x10778000 ( 304 kB)
.data : 0x1050e3a0 - 0x106dd170 (1851 kB)
.text : 0x10100000 - 0x1050e3a0 (4152 kB)NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 106.08 BogoMIPS (lpj=530432)pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
xor: measuring software checksum speed
8regs : 131.200 MB/sec
8regs_prefetch: 130.800 MB/sec
32regs : 198.800 MB/sec
32regs_prefetch: 198.400 MB/sec
xor: using function: 32regs (198.800 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Phantom PseudoBC GSC+ Port at 0xffc00000 [8] { 7, 0x0, 0x504, 0x00000 }
2. Dino PCI Bridge at 0xfff80000 [8/0] { 13, 0x3, 0x680, 0x0000a }
3. Merlin+ 132 Dino RS-232 at 0xfff83000 [8/0/63] { 10, 0x0, 0x022, 0x0008c }
4. Merlin 160 Core FW-SCSI at 0xfff8c000 [8/12] { 4, 0x0, 0x03d, 0x00089 }
5. Merlin 160 Core BA at 0xffd00000 [8/16] { 11, 0x0, 0x03d, 0x00081 }, additional addresses: 0xffd0c000 0xffc00000
6. Merlin 160 Core RS-232 at 0xffd05000 [8/16/4] { 10, 0x0, 0x03d, 0x0008c }
7. Merlin 160 Core SCSI at 0xffd06000 [8/16/5] { 10, 0x0, 0x03d, 0x00082 }
8. Merlin 160 Core LAN (802.3) at 0xffd07000 [8/16/6] { 10, 0x0, 0x03d, 0x0008a }
9. Merlin 160 Core Centronics at 0xffd02000 [8/16/0] { 10, 0x0, 0x03d, 0x00074 }, additional addresses: 0xffd01000 0xffd03000
10. Merlin 160 Core Audio at 0xffd04000 [8/16/1] { 10, 0x4, 0x03d, 0x0007b }
11. Merlin 160 Core PS/2 Port at 0xffd08000 [8/16/7] { 10, 0x0, 0x03d, 0x00084 }
12. Merlin 160 Core PS/2 Port at 0xffd08100 [8/16/8] { 10, 0x0, 0x03d, 0x00084 }
13. Coral SGC Graphics at 0xfa000000 [8/4] { 10, 0x0, 0x004, 0x00077 }
14. Coral SGC Graphics at 0xf4000000 [8/8] { 10, 0x0, 0x004, 0x00077 }
15. Gecko GSC Core Graphics at 0xf8000000 [8/24] { 10, 0x0, 0x016, 0x00085 }, additional addresses: 0xf0011000
16. Merlin L2 160 (9000/778/B160L) at 0xfffbe000 [62] { 0, 0x0, 0x502, 0x00004 }
17. Memory at 0xfffbf000 [63] { 1, 0x0, 0x067, 0x00009 }
18. Merlin+ 132 Dino PS/2 Port at 0xfff81000 [1] { 10, 0x0, 0x022, 0x00096 }
CPU(s): 1 x PA7300LC (PCX-L2) at 160.000000 MHz
Setting cache flush threshold to ac0 (1 CPUs online)
Lasi version 0 at 0xffd00000 found.
Dino version 3.1 found at 0xfff80000
Dino: No PCI devices enabled.
powersw: Soft power switch at 0xf0140000 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1 59 MB/s
raid6: int32x2 76 MB/s
raid6: int32x4 86 MB/s
raid6: int32x8 58 MB/s
raid6: using algorithm int32x4 (86 MB/s)
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 128 (order: 0, 6144 bytes)
UDP-Lite hash table entries: 128 (order: 0, 6144 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace: [<10118558>] show_stack+0x18/0x28 [<10111544>] dump_stack+0x1c/0x2c [<101732c8>] backtrace_regression_test+0x50/0x128 [<10116454>] do_one_initcall+0x6c/0x2b8 [<1072d850>] kernel_init+0xe0/0x184 [<10102c5c>] ret_from_kernel_thread+0x1c/0x24
Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace: [<10118558>] show_stack+0x18/0x28 [<10111544>] dump_stack+0x1c/0x2c [<10173258>] backtrace_test_irq_callback+0x18/0x38 [<101403b4>] tasklet_action+0xbc/0xdc [<10140cfc>] __do_softirq+0xd8/0x1a4 [<1011527c>] do_softirq+0x3c/0x60 [<10140e54>] run_ksoftirqd+0x8c/0x138 [<10157238>] kthread+0xa4/0xac [<10102c5c>] ret_from_kernel_thread+0x1c/0x24
Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
[<10121eb4>] save_stack_trace+0x28/0x60 [<10173368>] backtrace_regression_test+0xf0/0x128 [<10116454>] do_one_initcall+0x6c/0x2b8 [<1072d850>] kernel_init+0xe0/0x184 [<10102c5c>] ret_from_kernel_thread+0x1c/0x24 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Installing knfsd (copyright (C) 1996 [email protected]). msgmni has been set to 240
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
id 2bcb015a-9a02587, conforms to spec rev. 8.04
graphics card name: HPA4071B
id 2d08c0a7-9a02587, conforms to spec rev. 8.07
graphics card name: HPA4450AX1024
id 2d08c0a7-9a02587, conforms to spec rev. 8.07
graphics card name: INTERNAL_EG_X1024sticon: Initializing STI text console.
Console: switching to colour STI console 160x64
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-32 frame buffer device, HPA4071B, id: 2bcb015a, mmio: 0xfa100000
fb1: stifb 1024x768-8 frame buffer device, HPA4450AX1024, id: 2d08c0a7, mmio: 0xf4100000
fb2: stifb 1024x768-8 frame buffer device, INTERNAL_EG_X1024, id: 2d08c0a7, mmio: 0xf8100000 Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
8:16:4: ttyS0 at MMIO 0xffd05800 (irq = 16) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
8:0:63: ttyS1 at MMIO 0xfff83800 (irq = 22) is a 16550Aparport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 19 [PCSPP,TRISTATE]
parport0: fix this legacy no-device port driver!
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00zalon_probe: Zalon version 1, IRQ 67
ncr53c720-0: rev 0xf irq 67
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3g
------------ HERE it starts "hanging" (output is very slow) -------------- -
It seems the zalon/720 driver is not getting any interrupts. zalon seems to use the GSC chip.
- --------------------------------------------------------------------------
scsi 0:0:1:0: Device offlined - not ready after error recovery scsi 0:0:2:0: Device offlined - not ready after error recovery scsi 0:0:3:0: Device offlined - not ready after error recovery scsi 0:0:4:0: Device offlined - not ready after error recovery scsi 0:0:5:0: Device offlined - not ready after error recovery scsi 0:0:6:0: Device offlined - not ready after error recovery scsi 0:0:8:0: Device offlined - not ready after error recovery scsi 0:0:9:0: Device offlined - not ready after error recovery scsi 0:0:10:0: Device offlined - not ready after error recovery scsi 0:0:11:0: Device offlined - not ready after error recovery scsi 0:0:12:0: Device offlined - not ready after error recovery scsi 0:0:13:0: Device offlined - not ready after error recovery scsi 0:0:14:0: Device offlined - not ready after error recovery scsi 0:0:15:0: Device offlined - not ready after error recovery 53c700: Version 2.8 By [email protected]
scsi1: 53c710 rev 2
scsi1 : LASI SCSI 53c700
scsi 1:0:1:0: New error handler wants to abort command
scsi 1:0:1:0: CDB: cdb[0]=0x12: 12 00 00 00 24 00 scsi 1:0:1:0: New error handler wants BUS reset, cmd 17e35ee0
scsi 1:0:1:0: CDB: cdb[0]=0x12: 12 00 00 00 24 00
INFO: task scsi_eh_1:544 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. scsi_eh_1 D 10102d30 0 544 2 0x00000000 Backtrace: [<10111ffc>] schedule+0x288/0x510 [<101125f4>] schedule_timeout+0x1a0/0x1fc [<10111bac>] wait_for_common+0xdc/0x188 [<10111d64>] wait_for_completion+0x1c/0x2c [<1039e128>] NCR_700_bus_reset+0x104/0x180 [<1037ad70>] scsi_try_bus_reset+0x38/0x138 [<1037c44c>] scsi_eh_ready_devs+0x498/0x6b8 [<1037cbfc>] scsi_error_handler+0x43c/0x44c [<10157238>] kthread+0xa4/0xac [<10102c5c>] ret_from_kernel_thread+0x1c/0x24
and so on...
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 14 lines · Helge Deller
Quoted 13 lines · Kyle McMartin
Quoted 12 lines · Helge Deller
I just got again a chance to boot up my b160L and 715/64 machines.
Both broke due to the IRQ changes. I did reverted all of your IRQ patches (based on current Linus head branch) and now they boot again.
Basically they just hang during the SCSI initialization (timeouts while detectings discs).So, there is something wrong for Lasi/GSC and Dino busses....
Any idea?
Quoted 7 lines
Quoted 2 lines
No, but I'll take a look, it's probably something simple and stupid that I missed. :/
I tried to look into it, but I'm somewhat lost.
This is what I get on my B160L.
Same result btw on the 715/64.
The boot is just showing irq lost (so all the devices hang).
I've got it bisected to this commit on my C360:
commit ba20085c20f1c9e8af546dea6ad0efa421bdef32
Author: Kyle McMartin <[email protected]> Date: Wed Oct 13 21:00:55 2010 -0400
parisc: lay groundwork for killing __do_IRQ
But I haven't found the fix yet ... the commit looks to be an equivalent transformation.
James
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 9 lines · James Bottomley
commit
ba20085c20f1c9e8af546dea6ad0efa421bdef32Author: Kyle McMartin <[email protected]> Date: Wed Oct 13 21:00:55 2010 -0400parisc: lay groundwork for killing
__do_IRQBut I haven't found the fix yet ... the commit looks to be an equivalent transformation.
The only obvious thing that jumps out is that... no, set_irq_chip doesn't look to be doing anything awry.
But it must be something between what a 'raw' irq_desc looks like, and what the helpers initialize them to.
--Kyle
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 11 lines · Kyle McMartin
Quoted 9 lines · James Bottomley
commit
ba20085c20f1c9e8af546dea6ad0efa421bdef32Author: Kyle McMartin <[email protected]> Date: Wed Oct 13 21:00:55 2010 -0400parisc: lay groundwork for killing
__do_IRQBut I haven't found the fix yet ... the commit looks to be an equivalent transformation.
Quoted 5 lines
The only obvious thing that jumps out is that... no,
set_irq_chipdoesn't look to be doing anything awry.But it must be something between what a 'raw'
irq_desclooks like, and what the helpers initialize them to.
Actually, that all seems to be working. I've traced the sym interrupt through with a bunch of printks. The CPU dino interrupt correctly triggers. It calls dino_isr which gets the right dino device and correctly translates the pending interrupt to the right irq number (23) in my case. It looks like generic_handle_irq() (in dino_isr()) doesn't call the handler, or the handler is somehow ineffective (it takes ages to loop around and retry with the mask still pending). That looks nuts to me because it should be simply calling parisc_do_IRQ which is a wrapper for the original do_IRQ ... so this should be equivalent. Unfortunately getting on a 'plane soon and I have no access to a remotely controllable dino system, so that's probably it for me on the debugging front.
James
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
In reply to Helge DellerQuoted 2 lines · Helge Deller
I just got again a chance to boot up my b160L and 715/64 machines.
I got my 712 hooked up (sadly my B180 has lost its hard disk and RTC, but I can netboot it if I need to...) and I'll poke at this this afternoon.
Re: [RFT] irq changes (was Re: [git] parisc: Changes to ref refs/heads/parisc)
Quoted 8 lines · Kyle McMartin
Quoted 2 lines · Helge Deller
I just got again a chance to boot up my b160L and 715/64 machines.
I got my 712 hooked up (sadly my B180 has lost its hard disk and RTC, but I can netboot it if I need to...) and I'll poke at this this afternoon.
Haven't had a chance to debug this entirely yet, well, I wrote a patch to do proper chained handlers and got my B180 reinstalled... Will let you know tonight.
--Kyle