Summary: | latest gentoo-sources freeze my machine | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | felix schmid <felix> |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED CANTFIX | ||
Severity: | critical | CC: | steel300 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | my kernel config |
Description
felix schmid
2004-01-05 15:59:26 UTC
Created attachment 23230 [details]
my kernel config
What did you upgrade from? I upgraded from 2.6.0-test11-gentoo and 2.4.20-gentoo-r? (sorry, can'T remember the version number, the last before 2.4.22 probably). As I pointed out, the bug applies to both upgrades (before upgrading: no problem; after upgrading: both kernel version freeze). 'cpu stree test' ... why not just use cpuburn ? ;) Next time I will...I used seti; but there's always something new to learn. If you can try removing the patches from gentoo-dev-sources one at a time to see exactly which one it is, that would help a lot. how do I do that? remove them one by one from /usr/portage/distfiles? can you try gentoo-sources-2.4.22-r5 and let us know if that clears up your problem? I will try gentoo-sources-2.4.22-r5 and report about it. Meanwhile be informed that 2.6.1-mm re-intorduced the problem (I got rid of it by using 2.6.0-mm, as I already mentioned). I know that is beyond the scope of your responsibility, but maybe it helps... The last comment is apparently bullshit. I was refering 2.6.1-gentoo, not 2.6.1-mm. Sorry if that caused any confusion... scp on gentoo-sources-2.4.22-r5 freezes (as gentoo-sources-2.4.22-r2 did)... As a matter of fact kernel-2.6.1-mm DOES freeze (see my yesterday's comment)... kernel-2.6.0-mm works... Can you see if enabling CONFIG_PREEMPT helps? CONFIG_PREEMPT seems not to be the cause. I suspected this one too because I remebered the issue with 2.6-test10, but the kernels I've tried so far that showed the behaviour froze regardless of CONFIG_PREEMPT absent or present. The thing that confuses me is that the problem now also occurs with the mm-series kernels (at least with 2.6.1-mm, I haven't tried the latest one) - such as there is a patch that was introduced to the 2.6-gentoo series before it came into 2.6-mm (at version 2.6.1-mm1) and that was at the same time introduced into 2.4-gentoo series as it came into the 2.6-gentoo kernel. Someone asked me before to remove the patches one by one. I have not tried this so far because I don't know how to do that... if it happens with all those kernels, I'd be tempted to suspect acpi, to test, unpack the tarball of patches (gentoo-dev-sources) and look at the patch names. Set UNIPATCH_EXCLUDE to the name of the acpi patch on the command line when you remerge gentoo-dev-sources. UNIPATCH_EXCLUDE="999-acpi-blah" emerge gentoo-dev-sources and see if that fixes it I tried it today, but emerge doesn't react to UNIPATCH_EXCLUDE: hydra root 526 (~): UNIPATCH_EXCLUDE="408_acpi-20031203-2.6.0" emerge gentoo-dev-sources Calculating dependencies ...done! >>> emerge (1 of 1) sys-kernel/gentoo-dev-sources-2.6.1 to / >>> md5 src_uri ;-) linux-2.6.1.tar.bz2 >>> md5 src_uri ;-) genpatches-2.6-1.15.tar.bz2 kernel >>> Unpacking source... >>> Unpacking genpatches-2.6-1.15.tar.bz2 to /var/tmp/portage/gentoo-dev-sources-2.6.1/work >>> Unpacking linux-2.6.1.tar.bz2 to /var/tmp/portage/gentoo-dev-sources-2.6.1/work * Applying 125_x86_64_org_patches_2.6.1_rc3-brad.patch... [ ok ] * Applying 151_libata_siliconimage_3112_4_fixes.patch... [ ok ] * Applying 200_r8169-8110S-12172003.patch... [ ok ] * Applying 201_prism54_wlan_01032004.patch... [ ok ] * Applying 202_bcm5700_broadcom_gigabit_drvr_11272003.patch... [ ok ] * Applying 226_ieee1394_updates_01042004.patch... [ ok ] * Applying 227_alsa-1.0.0rc2-2.6.1rc1.patch... [ ok ] * Applying 300_NVIDIA_forcedeth_v20.patch... [ ok ] * Applying 400_bootsplash-3.1.3-2.6.0-test9.patch... [ ok ] * Applying 401_supermount-2.0.3.patch... [ ok ] * Applying 402_i2cisa_remove_dep.patch... [ ok ] * Applying 403_speakup_accessibility.patch... [ ok ] * Applying 405_lirc_infrared-2.6.1-rc1-20040106.patch... [ ok ] * Applying 408_acpi-20031203-2.6.0.patch... [ ok ] * Applying 410_libata_enable_sil.patch... I tried all kind of filenames - with the '.patch' suffix, without it, with version number, without,... try UNIPATCH_EXCLUDE="408" :) sorry, doesn't work either..:( hydra root 502 (/home/felix): UNIPATCH_EXCLUDE="408" emerge gentoo-dev-sources Calculating dependencies ...done! >>> emerge (1 of 1) sys-kernel/gentoo-dev-sources-2.6.1 to / >>> md5 src_uri ;-) linux-2.6.1.tar.bz2 >>> md5 src_uri ;-) genpatches-2.6-1.15.tar.bz2 kernel >>> Unpacking source... >>> Unpacking genpatches-2.6-1.15.tar.bz2 to /var/tmp/portage/gentoo-dev-sources-2.6.1/work >>> Unpacking linux-2.6.1.tar.bz2 to /var/tmp/portage/gentoo-dev-sources-2.6.1/work * Applying 125_x86_64_org_patches_2.6.1_rc3-brad.patch... [ ok ] * Applying 151_libata_siliconimage_3112_4_fixes.patch... [ ok ] * Applying 200_r8169-8110S-12172003.patch... [ ok ] * Applying 201_prism54_wlan_01032004.patch... [ ok ] * Applying 202_bcm5700_broadcom_gigabit_drvr_11272003.patch... [ ok ] * Applying 226_ieee1394_updates_01042004.patch... [ ok ] * Applying 227_alsa-1.0.0rc2-2.6.1rc1.patch... [ ok ] * Applying 300_NVIDIA_forcedeth_v20.patch... [ ok ] * Applying 400_bootsplash-3.1.3-2.6.0-test9.patch... [ ok ] * Applying 401_supermount-2.0.3.patch... [ ok ] * Applying 402_i2cisa_remove_dep.patch... [ ok ] * Applying 403_speakup_accessibility.patch... [ ok ] * Applying 405_lirc_infrared-2.6.1-rc1-20040106.patch... [ ok ] * Applying 408_acpi-20031203-2.6.0.patch... [ ok ] * Applying 410_libata_enable_sil.patch... [ ok ] >>> Source unpacked. wait, what am I saying :) speaking without thinking again. edit the ebuild and within UNIPATCH_LIST="yadda" add 408 gentoo-dev-sources-2.6.1.ebuild doesn't contain something like that. gentoo-dev-sources-2.6.1-r1.ebuild (but I think it's not used because my emerge reports that it uses 1.15 of the patchset, not 1.16) contains this line: UNIPATCH_LIST="${DISTDIR}/genpatches-2.6-${GPV}.tar.bz2" would adding '408' at the end really make sense (if i understood correctly that's what I should do)? Shouldn't I rather remove 408 from UNIPATCH_LIST? Removing the patch from the tar.bz doesn't work (of course) because of the checksum :( Why isn't there something like UNIPATCH_EXCLUDE for ppl like me? It seems really complicated to me to exclude a patch from the patchset...and tireing. no adding it to the end is the correct way. if it isnt a patch or a tarball it counts as an exclusion. it is the correct way to do it. sorry, I actually wrote the code but didnt even think about how to use it when i last commented! I have just commited a quick addition to the ebuild so it can not only handle exclusions from UNIPATCH_LIST but also by passing UNIPATCH_EXCLUDE ok, I did ACCEPT_KEYWORDS="~x86" emerge gentoo-dev-sources (after modifying gentoo-dev-sources-2.6.1-r1.ebuild). The acpi patch was not applied (as expected :)) Unfortunately, it didn't help...still freezing on scp :( If I have time (monday night propably) I will try what happens if I also remove the other patches. some recent changes to netfilter and other goodies in rc3 might have fixed this for you. we will try and roll out a release asap. please re-open if rc3 (or 2.6.2 final, whichever comes first) doesnt fix it. I have lately tested the behaviour of 2.6.3-gentoo and 2.6.3-mm1. Both still show the behaviour :( I have made one observation which might help or not: Once I tested with 2.6.3-gentoo (the scp experiment) and another task was running in the background accessing the haddrive (a cronjob doing emerge sync). It seemed to work fine for quite a while (I believe usually the machine would have crashed already in that amount of time). When I discovered which other was task running, I stopped the scp task to prevent corruption of the portage repository. After the cronjob finished I resumed the scp task and guess what... I can't believe I am the only one suffering from this phenomenon - will I ever be able to move on to a newer kernel? btw. I also suspected hdparm parameters to be the cause, but I tried without -X66 option and -u1; didn't help. These are my current settings: disc1_args="-d1 -m16 -c3 -A1" I know this is old, but does it still happen with a 2.6.4 or 2.6.5 kernel? How about an unpatched vanilla 2.6 kernel? Two months without word. This bug has rotted away. |