Re: HEADS UP [Re: thread+preemption stability improvement]

Maxim Maximov wrote:
> Scott Long wrote:
> 
>> All,
>>
>> Initial testing of this patch looks very promising.  For those that
>> aren't comfortable with patching their sources by hand, note that it
>> was committed to CVS a few hours ago and should be showing up on CVSup
>> very shortly (rev 1.8 of sys/i386/i386/intr_machdep.c is what you want
>> if you are running i386).  Please go out and test this as much as 
>> possible so that we can determine if futher action is needed.
> 
> 
>     I think it is needed :( Things actually get _much_ better, now I've 
> been able to use my big IMAP folders, but still after applying the patch 
> and working about an hour mozilla freezes with the same sympthoms (cpu 
> fan gets spinning faster and faster as if cpu temperature is raising). 
> Are there any ways I can help track this down further?
>     Preemption is enabled, of course. My kernel's config is latest 
> GENERIC with these additions:
> 
> ######
> device        pf
> device        pflog
> options         ALTQ
> options         ALTQ_CBQ        # Class Bases Queueing
> options         ALTQ_RED        # Random Early Drop
> options         ALTQ_RIO        # RED In/Out
> options         ALTQ_HFSC       # Hierarchical Packet Scheduler
> options         ALTQ_CDNR       # Traffic conditioner
> options         ALTQ_PRIQ       # Priority Queueing
> options         ALTQ_NOPCC      # Required for SMP build
> options         ALTQ_DEBUG
> device        radeondrm
> device          acpi_asus
> device        sound
> device        snd_ich
> options        ALT_BREAK_TO_DEBUGGER
> options        MSGBUF_SIZE=245760
> 
>     My system is the notebook ASUS L5Ga. At boot I'm getting many 
> witness messages like these and I turned on debug.mpsafenet=1. Can this 
> be a problem?

The problem here is that the sk driver is holding a mutex across a call
to mii_phy_probe() which then winds up in bus_probe_and_attach().  The
current architecure of the miibus code makes it very hard to lock
drivers correctly and efficiently, but this paraticlar case shouldn't
affect runtime stability.  If you get others messages like this while
doing network I/O then I would worry.

Scott