Re: ld(4) shutdown/flush patch to avoid tsleep at system shutdown time

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Mon, May 12, 2008 at 06:16:36PM +1000, Simon Burge wrote:

> With a recent -current on a machine with a twe(4) I get the following on
> a reboot:
> 
>   panic: cpu_switcho: switching above IPL_SCHED
>   Stopped in pid 6.1 (reboot) at  netbsd:breakpoint+0x4:  popl    %ebp
>   db{0}> bt
>   
> breakpoint(c0a5f40c,cc819af4,c0a89100,cc819acc,c0484c7c,c0a89148,cc7f3c80,cc819afc,c0543aea,c0a89100)
>  at netbsd:breakpoint+0x4
>   panic(c010038a,cc7f3c80,0,0,c0484e50,cc7f3c80,cb367be0,0,c0481901,cc7f3c80) 
> at netbsd:panic+0x1bd
>   
> cpu_switchto(cc7f3c80,1770,b4063c,c1eb2600,0,c1ed8400,cc819bac,c05978fb,1770,0)
>  at netbsd:cpu_switchto+0x17
>   sleepq_block(1770,0,c0a38198,1770,0,5,8,c1f99000,0,c0a84b20) at 
> netbsd:sleepq_block+0x92
>   
> ld_twe_flush(c1f99000,c0a84b20,cc819bdc,c04a28c6,c1f99000,c1f99000,cc819bdc,c0491051,c1f99000,0)
>  at netbsd:ld_twe_flush+0xcb
>   
> ld_shutdown(c1f99000,0,cc819bfc,c047543e,c1f99000,0,cc819c0c,c04df28d,0,cc819d00)
>  at netbsd:ld_shutdown+0x21
>   
> device_pmf_driver_shutdown(c1f99000,0,cc819c0c,c04df28d,0,cc819d00,cc819c0c,c0484112,0,0)
>  at netbsd:device_pmf_driver_shutdown+0x21
>   pmf_system_shutdown(0,0,cc819c2c,c0558afb,8,cc7f3c80,0,0,cc819d00,0) at 
> netbsd:pmf_system_shutdown+0x9e
>   doshutdownhooks(8,cc7f3c80,0,0,cc819d00,0,cc819cdc,c04903c4,0,0) at 
> netbsd:doshutdownhooks+0x42
>   cpu_reboot(0,0,0,0,0,0,cc819c9c,c0543343,23,cc819cc0) at 
> netbsd:cpu_reboot+0x1b
>   
> sys_reboot(cc7f3c80,cc819d00,cc819d28,cc819d40,c05432f7,cb37bf50,1,0,0,bfbfede8)
>  at netbsd:sys_reboot+0x74
>   syscall(cc819d48,b3,ab,1f,1f,1,d,bfbfede8,2,256) at netbsd:syscall+0xab
> 
> The following patch adds a poll flag to the ld(4) sc_flush() function,
> and ld_twe_flush() checks this and either polls or doesn't.  By
> inspection, twa(4) needs the same handling.  I'm not sure about icp(4)
> and iop(4).
> 
> This is vaguely based on what ata(4)/wdc(4) do - thanks to Joerg
> Sonnenberger for the pointer to that code.
> 
> Any problems with this?

Yes, there should be no reason that we have to poll there. Even though the
system is being rebooted it's still up and running. Why is the code being
executed at IPL_HIGH?

Andrew