On 07/06/11 17:04, Chris Cappuccio wrote:
Jeff Ross [[email protected]] wrote:
This hang happens with the 4 different SuperMicro based motherboards
I have that have the lm chipset.
In the second message referenced above I noted that a snapshot dated
May 25 booted normally and I first ran into the problem on June 6 so
the window is fairly small.
Yet, a kernel compiled again Jun 6th sources does not display this behvaior
Therefore, it is caused by a change that was in the snapshots--but not
committed until later
I was out of town for a week, but will now narrow down when the offending code
was committed since it affects my X7SBL, PDSML, and probably other supermicro
boards that I use in qty...
Hi,
This might be a different fault to the previous one reported.
I tried a kernel built from CVS using the follwoing dates
6th June Ok.
15th June Ok.
22nd June Hangs.
19th June Ok.
20th June Ok.
21st June Hangs.
The changed between the two dates are :-
cvs -R -q diff -uNp -D 2011/06/20 -D 2011/06/21 | grep Index:
Index: arch/amd64/conf/GENERIC
Index: arch/i386/conf/GENERIC
Index: dev/softraid.c
Index: dev/vnd.c
Index: dev/ata/wd.c
Index: dev/isa/if_lc_isa.c
Index: dev/isa/if_we.c
Index: dev/isa/mcd.c
Index: dev/isa/radiotrack2.c
Index: dev/isa/sf16fmr2.c
Index: dev/isa/wdc_isa.c
Index: dev/microcode/Makefile
Index: dev/pci/if_myx.c
Index: dev/pci/if_myxreg.h
Index: kern/subr_autoconf.c
Index: net/if_pflog.c
Index: net/pf.c
Index: net/pf_norm.c
Index: net/pfvar.h
I think I narrowed this down to kern/subr_autoconf.c, build a kernel
extract from CVS with a date of 21st June, with kern/subr_autoconf.c
kept at version 1.64. This booted without hanging.
1.65 log
serialize attach and detach of device sub-trees -- only one device
sub-tree may attach or detach at a time. attach and detach will sleep
against each other.
this is fixing (working around?) some bizzare corner cases that have
been seen (but not fully diagnosed) where the device trees, disk
registration
subsystem, and other things could get messed up. one could argue though
that this serialization is a very good thing; it is easier than adding piles
of locks in various other places.
ok matthew jsing
In the case of lm from dmesg we have,
lm1 at iic0 addr 0x2d: W83781D
lm0 at isa0 port 0x290/8: W83781D
lm1 detached
Regards
Nigel Taylor
