>
>
> Hey everybody,
>
> as many of you are aware, we were talking (not enough) about the release
> process at LKS this year.
> This ain't it.
>
> This is just the regular old release "process", with some LKS backlog 
> put in for good measure.
> But the good news is, that I'll try the new release process after 2.6.13
> is out, which is hopefully not too far away. Which means that we should
> try to let people know about the fact that if they want to merge stuff,
> they should do so in the first two weeks after the 2.6.13 release, and no
> later (also, no earlier either, by now).
>
> So if you have a favourite kernel developer, please wake him up with a
> friendly kick to the head and explain this concept to him in small
> easy-to-understand words, and tell him that we're in the freeze process
> for 2.6.13 now, and that he should be gathering up the patches, and make
> sure they get to me _after_ 2.6.13 is out, but at that point do it in a
> timely manner.
>
> Ok?
>
> In the meantime, here's the 2.6.13-rc4 update, with a diffstat so 
> horribly
> ugly that I won't even show it (the kernel list would eat it as too big
> anyway), and I'll have to go fix my code that generates it.
>
> Oh, and in case you wonder, it's ugly because a cris architecture update
> with long filenames that really causes git-apply to output som rather
> nasty-looking diffstats  ;)
> ALSA, IB, NTFS, SCSI (qla2xxx) and the cris architecture update.
>
>             Linus
>
>  
>
This is regarding *-rc4 and *-rc4-git1:  I slapped together my favorite 
config and gave it a test run. It had a bit of a problem and ground to a 
halt after spewing these into the log.

I'd say ; right after it did a "modprobe parport_pc". Actually I 
duplicated this today on rc4-git1 after yesterday's same experience with 
-rc4. With the .config file below, I did a grub boot (init 1). The dmesg 
from this was not so different, if at all, from my last working kernel. 
After this, I only did one test, which was a "$modprobe parport_pc" 
which produced the usual hundreds of trace msgs. I could modprobe some 
other modules without problem, i2c, snd_*, etc. The dmesg > 'file' is 
attached below. Config is attached below that.

The only update from trying this yesterday was that with *git1, I did 
the modprobe in a more controlled fashion, and the system didn't hang on 
the modprobe. If I let it continue by doing an init 3, it does 
eventually freeze and I don't get more information of use in dmesg or 
the /var/log/m* file.

I've been quite low on time lately, so perhaps I missed something 
obvious in the notes. When I did the "$make xconfig" , there were no 
warnings about changes or new config params.

The two mentioned files are on as attachments. Some other details:

mainboard: nf7 (abit nforce2 chipset)
last kernel before *rc4 that was running well with the identical config: 
2.6.13-rc3-git7
Using mem=4g and associated parms to get my full 1g.
Version rawhide: Up to date as of yesterday (27-Jul)

If I can find the time tomorrow morning, I'll leave parport_pc commented 
out of modprobe.conf and see if something else pops loose. I don't use 
the parallel port, but I try to keep a fairly robust config for noticing 
bugs.

Mick


--attached files--