Bug#1033732: [PATCH v2] x86/acpi/boot: Do not register processors that cannot be onlined for x2apic
On Sun, Apr 02, 2023 at 03:13:05PM +0200, Guy Durrieu wrote: > Yes it does. Thanks for testing. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Bug#1033732: [PATCH v2] x86/acpi/boot: Do not register processors that cannot be onlined for x2apic
On April 2, 2023 12:41:46 PM GMT+02:00, Guy Durrieu wrote: >My system worked fine with kernel 6.1.15, but stopped booting after >upgrading to 6.1.20 and resulted in a kernel panic: Does this fix it: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent Thx. -- Sent from a small device: formatting sucks and brevity is inevitable.
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
Hi Thomas, On Mon, Jun 16, 2014 at 09:13:20AM +0200, Thomas Schwinge wrote: The problem solved itself: the machine recently died of hardware failure. ;-| How convenient. :-P What happened? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616094324.ga8...@pd.tnic
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Mon, Jun 16, 2014 at 12:33:55PM +0200, Thomas Schwinge wrote: The power supply and/or mainboard didn't wake up after a recent power cycle. As both these aren't standard form factors (and the machine/architecture had some issues, as discussed, and see also http://news.gmane.org/find-root.php?message_id=%3C87r45fajun.fsf%40schwinge.name%3E Fun. for another issue), I didn't bother looking for spare parts. Want me to ship it to you? ;-) That's nice but I have enough broken hardware here as it is. :-) You could probably find a better use for it, say a flower pot? :-D Good luck. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616104638.gc8...@pd.tnic
Bug#717473: [PATCH] adm64_edac: Fix single-channel setups
It can happen that configurations are running in a single-channel mode even with a dual-channel memory controller, by, say, putting the DIMMs only on the one channel and leaving the other empty. This causes a problem in init_csrows which implicitly assumes that when the second channel is enabled, i.e. channel 1, the struct dimm hierarchy will be present. Which is not. So always allocate two channels unconditionally. This provides for the nice side effect that the data structures are initialized so some day, when memory hotplug is supported, it should just work out of the box when all of a sudden a second channel appears. Reported-and-tested-by: Roger Leigh rle...@debian.org Signed-off-by: Borislav Petkov b...@suse.de --- drivers/edac/amd64_edac.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index 8b6a0343c220..8b3d90143514 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -2470,8 +2470,15 @@ static int amd64_init_one_instance(struct pci_dev *F2) layers[0].size = pvt-csels[0].b_cnt; layers[0].is_virt_csrow = true; layers[1].type = EDAC_MC_LAYER_CHANNEL; - layers[1].size = pvt-channel_count; + + /* +* Always allocate two channels since we can have setups with DIMMs on +* only one channel. Also, this simplifies handling later for the price +* of a couple of KBs tops. +*/ + layers[1].size = 2; layers[1].is_virt_csrow = false; + mci = edac_mc_alloc(nid, ARRAY_SIZE(layers), layers, 0); if (!mci) goto err_siblings; -- 1.8.3 -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130729124501.ga6...@pd.tnic
Bug#717473: [PATCH] adm64_edac: Fix single-channel setups
On Mon, Jul 29, 2013 at 04:00:52PM +0100, Ben Hutchings wrote: There's a typo in the subject line. :-) Yep, looks like I've gradually gotten unnaccustomed to typing amd ... it's not in the fingers anymore. :-) Thanks, fixed. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130729151814.gf6...@pd.tnic
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Wed, Jul 24, 2013 at 12:04:49AM +0100, Ben Hutchings wrote: This is absolutely stable material. Most of the people affected are not going to work out that they plugged their memory in wrong. (And maybe some of them only have one module.) Hmm, not from my experience. This is the first report I've seen so far and most people running amd64_edac have DIMMs on both channels. But if you really insist, I'll tag it for stable and send it to Linus now. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130724071342.ga30...@pd.tnic
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Mon, Jul 22, 2013 at 08:19:26PM +0100, Roger Leigh wrote: Ben's patch does allow me to boot the system with the memory in this configuration on a 3.10 kernel. Ok, I actually think we can fix it the way below. It should be equivalent to Ben's patch in current functionality with the difference that it is a bit simpler and keeps the special handling for K8 which I want to have there as a future info. In addition, it still provides for the data structures to be initialized so some day, when memory hotplug is supported, it should work out of the box when all of a sudden a second channel appears. I think it should apply cleanly to 3.8 or 3.9 too as we haven't had a whole lot of movement in that area :-) Thanks. --- diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index 8b6a0343c220..52f2da1a89a9 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -2470,8 +2470,15 @@ static int amd64_init_one_instance(struct pci_dev *F2) layers[0].size = pvt-csels[0].b_cnt; layers[0].is_virt_csrow = true; layers[1].type = EDAC_MC_LAYER_CHANNEL; - layers[1].size = pvt-channel_count; + + /* +* Always allocate two channels since we can have setups with DIMMs on +* only one channel. Also, this simplifies handling later for the price +* of a couple of KBs tops. +*/ + layers[1].size = 2; layers[1].is_virt_csrow = false; + mci = edac_mc_alloc(nid, ARRAY_SIZE(layers), layers, 0); if (!mci) goto err_siblings; -- -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130723160557.gg8...@pd.tnic
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Tue, Jul 23, 2013 at 11:24:17PM +0100, Roger Leigh wrote: I've tested it against 3.10 and I can confirm that it works. I've booted the system with the DRAM on the same channel, and on separate channels, and it's working without problems in both cases. That's good news, thanks for testing and helping with this Roger. I'll add your Tested-by and queue it for 3.12 (i.e., I don't see it being urgent enough to rush it to -stable since your dual-channel layout takes care of the issue indirectly). -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130723223911.gj8...@pd.tnic
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Sun, Jul 21, 2013 at 06:41:52PM +0100, Ben Hutchings wrote:
On Sun, 2013-07-21 at 09:54 +0100, Roger Leigh wrote:
If the bug is in amd64_edac_mod, there are only two possible commits
which could cause the problem:
1eef12825 amd64_edac: Correct DIMM sizes
94c1acf2c amd64_edac: Add Family 16h support
Which are the only commits between 3.8 and 3.9 (and none made since)
The crash is at this line:
csrow-channels[1]-dimm-nr_pages = row_dct1_pages;
Hmm.
If I can read it correctly above, 3.8 works for you Roger, correct?
If so, can you please enable CONFIG_EDAC_DEBUG, rebuild 3.8 and boot
your machine with it and send me the full dmesg of the boot?
with csrow-channels[1]-dimm == NULL.
This code was introduced by the first commit above. Does the patch
below fix this?
Ben.
---
[PATCH] amd64_edac: Fix crash in init_csrows() for memory controller in
64-bit mode
init_csrows() assumes all processesors after K8 have 2 memory channels.
But these processors support a mode where only one channel is used.
It seems that csrow_enabled() may still return true for the second
channel (BIOS bug?).
Ok, I think I know what the problem is:
[5.815246] EDAC amd64: DRAM ECC enabled.
[5.816328] EDAC amd64: F15h detected (node 0).
[5.817397] EDAC amd64: MC: 0: 0MB 1: 0MB
[5.818379] EDAC amd64: MC: 2: 0MB 3: 0MB
[5.819332] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.820250] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.821176] EDAC amd64: MC: 0: 4096MB 1: 4096MB
[5.822131] EDAC amd64: MC: 2: 4096MB 3: 4096MB
[5.823048] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.823927] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.824818] EDAC amd64: using x4 syndromes.
[5.825680] EDAC amd64: MCT channel count: 1
Roger's DIMMs are only on the one channel and the second one is empty.
Btw, Roger, you might want to move one of the DIMMs to a another DIMM
socket on the board so that you can use both channels for performance
reasons.
I'm saying one of the DIMMs because I'm assuming those 4G above are
dual-ranked DIMMs and you have two 8G DIMMs on the board.
If they're single-ranked i.e. 4G each, then you shouldn't have any
choice because your board has only 4 DIMM slots anyway, AFAICT from the
manual:
http://www.asus.com/Motherboards/SABERTOOTH_990FX_R20/#support_Download_10
Which would be buggy because you're still using only one DCT.
Btw if you have two DIMMs on there, please put them according to the
recommended memory configurations, i.e. one in A2 and the other in B2.
Here's my layout, for example:
[5.890887] EDAC MC: DCT0 chip selects:
[5.890888] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[5.890889] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[5.890890] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.890891] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.890893] EDAC MC: DCT1 chip selects:
[5.890894] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[5.890894] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[5.890895] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.890896] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.890897] EDAC amd64: using x4 syndromes.
[5.890901] EDAC amd64: MCT channel count: 2
And I have 4 DIMM slots occupied.
Check pvt-channel_count before csrow_enabled(), and remove the family
number conditions.
Reported-by: Roger Leigh rle...@debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: 717...@bugs.debian.org
---
drivers/edac/amd64_edac.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8b6a034..be9c2fe 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2084,10 +2084,8 @@ static int init_csrows(struct mem_ctl_info *mci)
*/
for_each_chip_select(i, 0, pvt) {
bool row_dct0 = !!csrow_enabled(i, 0, pvt);
- bool row_dct1 = false;
-
- if (boot_cpu_data.x86 != 0xf)
- row_dct1 = !!csrow_enabled(i, 1, pvt);
Ok, this shouldn't be set if DCT1 doesn't have enabled csrows. So yes,
Roger, that debugging output would be of great help.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130721193601.ga31...@pd.tnic
Bug#700333: Stack trace
On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote: When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. so I'm guessing with Thomas' patch it suspends fine now? Yeah, now I'm using a patched kernel and it's OK. So, does it mean the problem is fixed by this patch or it's just confirmed and should be fixed by another one? Well, it makes sense to me, at least: we remove the handler on suspend so that the HPET interrupt doesn't fire. If, when the box comes up again, the pending interrupt is cleared, then all is fine - we can safely register the handler again and everyone goes about their merry way. But don't worry, if Thomas has an idea, it is almost guaranteed you'll get a proper fix soon. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130428190541.ga2...@pd.tnic
Bug#700333: Stack trace
On Sat, Apr 27, 2013 at 07:08:42PM +0400, vita...@yourcmc.ru wrote: Looks like we can't do anything about that in the HPET code itself. Vitaliy, could you try that patch ? Thanks, I've tried it several days ago (and still using a patched kernel :)) - the box survives. But at which moment should I check for Spurious interrupt in dmesg? When you do a suspend/resume cycle. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. so I'm guessing with Thomas' patch it suspends fine now? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130427154956.gc4...@pd.tnic
Bug#700333: Stack trace
+ tglx. On Sun, Apr 21, 2013 at 01:38:33AM +0400, vita...@yourcmc.ru wrote: Stack trace picture is here: http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg Vitaliy reported that his system crashes when suspending to disk. This was a regression from 3.2 to 3.7, and remains in 3.8. Some details of this system are in the bug log at http://bugs.debian.org/700333. The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. The HPET interrupt handler was called immediately after it was registered for CPU 2 (?), before the corresponding clock_event_device was registered. Seems like an obvious race condition, but then shouldn't the HPET have been stopped while the CPU was previously offlined? And it's strange that this system apparently hits the race quite reliably. Anyone? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420225516.gb4...@pd.tnic
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Thu, Sep 13, 2012 at 02:58:25PM +0200, Borislav Petkov wrote: Here's the script, let me know how it goes: Here's a more correct version. I'm not saying yours won't work based on the rdmsr and setpci output on your box, but here's a version which should pay attention to one other workaround and work on all K8s. HTH. -- #!/bin/bash # assuming a single CPU system nb_cfg=0xc001001f ht_tr_ctl=0x68 val=0x$(rdmsr $nb_cfg) # revert E131 workaround val=$(( $val ~(1 20) )) val=$(( $val | (1 32) )) val=$(printf 0x%08x $val) wrmsr $nb_cfg $val val=0x$(setpci -s 18.0 $ht_tr_ctl.l) # clear bits [22:21] val=$(( $val ~( 0x3 21) )) val=$(( $val | (1 21) )) val=$(printf 0x%08x $val) setpci -s 18.0 $ht_tr_ctl.l=$val echo Erratum 169 workaround applied. -- -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917172345.gh13...@aftab.osrc.amd.com
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Fri, Sep 07, 2012 at 11:14:33AM +0200, Thomas Schwinge wrote: I have now finally been able to check this, and yes, I'm already using the latest version of the BIOS, which is Phoenix cME FirstBIOS Desktop Pro version 5.00 R1.07.2264.A1 (a.k.a. 5.00.1.07, 25.04.2006) for Fujitsu Siemens Esprimo E5600, mainboard D2264-A1, CPU AMD Sempron 3000+. Ok. If there's no newer BIOS, we can try applying the workaround at boot in an init script to fix your issue. How'd that be done? Well, you need to run the following script when the machine boots. I.e., you'd probably have to add it to /etc/init.d/ and make it run at some runlevel, sometime early-ish, before a user can login. Here's the script, let me know how it goes: -- #!/bin/bash # assuming a single CPU system nb_cfg=0xc001001f ht_tr_ctl=0x68 val=0x$(rdmsr $nb_cfg) val=$(( $val | (1 32) )) val=$(printf 0x%08x $val) wrmsr $nb_cfg $val val=0x$(setpci -s 18.0 $ht_tr_ctl.l) val=$(( $val | (1 21) )) val=$(printf 0x%08x $val) setpci -s 18.0 $ht_tr_ctl.l=$val echo Erratum 169 workaround applied. --- HTH. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120913125825.gb19...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:42:17AM -0400, Steven Rostedt wrote: On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote: Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. This is where 'make localmodconfig' does help. It can remove a lot of modules for you. And I just recently fixed a bug in the tool that it now removes even more modules (The fix is in linux-next). Even more modules? When is enough, enough? :-) Also, if you are building on another box than what the kernel is for, you can go to that box and run 'lsmod /tmp/lsmod'. Copy that file to the build machine (into /tmp/lsmod), and then run 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules not used by the target box. Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Hopefully those cases are seldom enough so thanks for this, I'll try that the next time. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719164807.gd23...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote: This is why I created the make-min-config in ktest. It keeps on disabling configs to see what the machine needs to boot (and optionally run some test), and what configs it can disable. It does not touch the multi options though. It creates two configs. One that has the configs that it can't turn off (still enabled with a make allnoconfig, or selected by something that it must have), and a config that just has the configs that 'if I disable this, the box doesn't boot'. Here's an example: For my min-config files with the configs that couldn't be turned off: $ wc -l config-min* 117 config-min 139 config-min-net The config-min will get the box to boot (no network). The -net, adds enough to ssh to the box. $ wc -l config-skip* 11 config-skip 14 config-skip-net The above are the configs that ktest found if it disabled, would not boot (or ssh). $ cat config-skip-net CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SATA_AHCI=y CONFIG_E1000=y CONFIG_QUOTA=y CONFIG_ATA=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_DEVTMPFS=y CONFIG_EXT4_FS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_SERIAL_8250=y CONFIG_BLK_DEV_SD=y CONFIG_NET=y CONFIG_NETDEVICES=y I can pass the above to a allnoconfig, and the box will boot and allow ssh. Note, the reason for the serial config, is that this ktest run uses a serial port to see if the box booted. If the serial isn't there, then it thinks it failed. I agree with all this and you've explained this to me live already so you're preaching to the choir. But it would be a lot faster/easier if users can select, let's call'em profiles which are not mutually exclusive and can speed up the configuration process. They can either be distro-specific or generic, selecting certain features you need. So configuring your kernel would be like shopping without paying too much attention to details. Let's look into the head of a person doing a config like that and read some of her thoughts :): Hm, ok, this new configurator is cool, a lot faster I gotta say... So, what do I need, ah, yes, it is an AMD laptop so from vendors I select AMD, then I probably need ext4, then I'd like to do packet filtering so I should enable iptables.. Oh, I'd like to do tracing too so let's enable tracing and trust Steven with the options he's added by default, then I need ahci, I'd also like to do encrypted partitions so I'll enable device mapper with crypto... So all those things could be selectable from that profiles menu without having to go through the gazillion of little suboptions and having to read help (which is sometimes completely helpless) and figure out do I need it or not. And this would simplify configuration a lot. IMHO, anyway. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719173415.ge23...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote: On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov b...@amd64.org wrote: Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Sadly, not obscure at all. Most of the *drivers* are modules, but most of the distro config options are indeed booleans (or, if tristate, =y). Even driver-wise, there are some things that are often =y, even though you generally don't want them. Tell me about it. I'm always pissed off when someone thinks his stuff is very important and sets his sacred option to be =y/=m by default so the wider audience can at least compile-test it while the majority of the machines don't actually need it. A more coarse-grained config where most of the stuff is off by default could take care of that probably. PCMCIA? Not even *laptops* have that shit any more, but having built-in cardbus support almost certainly helps in a distro kernel for booting of certain odder cases. Yeah, distros need the one-size-fits-all thing so they have to enable *everything*. Xen support? Odd partition tables? All the different AGP versions? Many of us couldn't care less, but again, it makes sense in the actual distro kernel, even if it does *not* necessarily make sense in a personalized one. Yep. So doing make allmodconfig is certainly a workable thing (modulo the modules that you need for stuff you hadn't happened to use), but it's not wonderful. Oh and I always aim to build distro kernels on a big machine - allmodconfig build is no fun on a tiny laptop. So would it be better to have better profiled kernels, obviating the need for an almost full build? Hell yeah! I also hate having to enable support for modules. A non-modular build is quicker to build and avoids some security issues. Some drivers don't work well built-in (they load firmware etc too early), but imho it's worth doing if you can, and it's something we should make easy for people to do because of the security side (of course, per-build randomly generated keys and signed modules with the keys deleted after the build would be reasonably equivalent from a security standpoint, but we're not there yet). Agreed. So there are some not-so-obscure situations, judging by your examples above. Ho-humm. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719175310.gf23...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote: Yes, I know you know this already, as we discussed it in a pub over a beer (choir practice). But this is a public forum on LKML (the church), where I now have an audience of heathens. Convert! Convert! You are all sinners! Ah, gotcha. [ … ] But this still doesn't solve Linus's initial request. That would be a single option that makes your distro boot, and work well. Again, that option wont have the drivers needed, but it will enable all the core infrastructure that you need. Oh I'm being additive here. You'll have feature profiles for the stuff we talk above and distro profiles which solve Linus' issue. Basically one coarse-grained config option will either select a feature which has a lot of small subfeatures of which some are sane and want to be enabled by default when selecting the topfeature. Or a distro-specific feature which could itself select other topfeatures. I haven't tried this in reality to actually be able to say that a tree-like configure approach would actually make sense and work. It sounds like a nice idea though, especially having the hierarchical structure. :) -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719180914.gg23...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say profile, which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. I have a couple problems with the approach of modifying the existing kconfig files 1. how does it handle the case when a profile wants something one way and the admin wants it another way Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. the example is the fedora default wanting SELINUX and I want some other LSM Currently, if you run fedora and want something that's not enabled, you recompile your kernel too, right? 2. since it requires making changes in the upstream kernel source, the number of people who can make these changes is small. I think that's moot since you either select the profile or you don't. 3. since all these changes go into the upstream kernel source, changes to these profiles are going to be visible churn (think of the issues with the defconfigs for ARM a couple of years ago) AFAICT, those changes will be needed only for a new distro release and that happens twice a year, tops. 4. the complexity of tagging all possible profiles is very high. That's why we start simple. Even if you limit the profiles to Linux Distros, how many different distros are there? Do you really want to have to start arguing over which distros are large enough to get their profile added to the upstream kernel source? That's a valid question; its answer could be defined arbitrarily. joshing Let's say all distros which make money - more than a certain large amount - are allowed. :-) /joshing If instead we go with something along the lines of the miniconf approach, the picture looks very different 1. this approach only sets things one time, after that the person doing the compile is free to change anything. ... Sorry, I don't see the simplification: you need to rebuild your kernel anyway and before you rebuild it, you can do all the changes you want. So either you select a profile or you load a miniconfig, it doesn't really matter how you do it? -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716082418.gc24...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: We have make kvmconfig in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. I can imagine a user selecting this and other coarse-grained options in Kconfig and then adjusting single options like, for example, I wouldn't need the *9P* options on x86, etc, etc. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120715101434.ga18...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 01:17:16PM +0300, Pekka Enberg wrote: Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. It is a config option too - make kvmconfig simply enables it. Right, so how about something more concrete in this whole discussion: Maybe add the KVMTOOL_TEST_ENABLE (maybe rename it to a more fitting name like KVM_OPTS or similar) thing to a new toplevel Kconfig menu called Distro and other profiles or so: │ │ General setup --- │ │ Distros and other profiles --- --- │ │ [*] Enable loadable module support --- │ │ [*] Enable the block layer --- │ │ Processor type and features --- ... Btw, which Kconfig option is needed for -usbdevice tablet support so that the host mouse can be able to send scroll events to the guest qemu screen without the need for the qemu screen to capture it so that I need to escape it everytime I need to return to the host? And can we add it to the list of options KVMTOOL_TEST_ENABLE selects? Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120715211848.ga21...@aftab.osrc.amd.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond trond.mykleb...@netapp.com wrote: We could at least make selection of a minimal set of drivers for the more common virtualised platforms a lot easier. Right now, you need to hunt through 30+ different menus in order to find what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. +1. Same experience with building a kvm kernel so I couldn't agree more. Thanks. -- Regards/Gruss, Boris. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714103716.gd26...@liondog.tnic
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 04:43:32PM +0400, Cyrill Gorcunov wrote: For example to enable PCI driver for virtio devices I need to go to Device Drivers - Virtio drivers, while I think it would be great to have everything virt. related in Virtualization section. Actually, we need something more generic than that: everything X-related should be automatically selected when setting CONFIG_X. And X can be any subset of configuration options which belong to one feature, be it KVM, distro-specific stuff, or CPU-vendor specific stuff, or whatever. I can imagine, for example, that when a user wants to have an AMD-specific config, it automatically selects CPU_SUP_AMD, X86_MCE_AMD (for MCE), MICROCODE_AMD (microcode support), AGP_AMD64, EDAC_AMD64 and a bunch of other AMD-specific features. This would simplify not only the configuration process but also Kconfig-related build failures since for your configuration you'll make sure that required stuff is selected. What I'm saying is that not only distro-specific configs but also some sort of hierarchical config options could be defined to automatically preselect stuff for a specific aspect and save a lot of time when configuring a new system. Our config options have grown humongous right about now and we can use the simplification. Of course, you can always do fine-grained tuning afterwards but it'll save a lot of time, in general. Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714174827.ga13...@aftab.osrc.amd.com
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Mon, Jun 18, 2012 at 07:28:07AM +0200, Thomas Schwinge wrote: Let me guess: AMD K8? Correct. Also, can I get /proc/cpuinfo please? $ cat /proc/cpuinfo processor : 0 Ok, a single core. vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Sempron(tm) Processor 3000+ stepping: 2 cpu MHz : 1000.000 cache size : 128 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up rep_good nopl pni lahf_lm bogomips: 2000.16 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc Ok, can you do the following: $ setpci -s 18.0 0x68.l and $ rdmsr 0xc001001f and send me the output of both commands. Btw, rdmsr should be in a package called msr-tools, at least on Debian. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120618142900.ga9...@aftab.osrc.amd.com
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Mon, Jun 18, 2012 at 04:52:36PM +0200, Thomas Schwinge wrote: Hi Borislav! First, thanks for helping! Sure, np! :-) Ok, can you do the following: $ setpci -s 18.0 0x68.l $ sudo setpci -s 18.0 0x68.l 0f00cc0f $ rdmsr 0xc001001f $ sudo modprobe msr $ sudo rdmsr 0xc001001f 8 Ok, this is a BIOS bug - we have a recommendation about what the BIOS should do but yours doesn't do it. Are you sure you're using the latest BIOS for your motherboard? Can you check for updates and if you get a newer version, can you update your BIOS and do the two commands above? If there's no newer BIOS, we can try applying the workaround at boot in an init script to fix your issue. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120618155141.gf8...@aftab.osrc.amd.com
Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD
On Sat, Jun 16, 2012 at 12:14:14PM +0200, Thomas Schwinge wrote: Hi! After many others that played with no problems, I just tried playing Guano Apes' audio CD »Proud Like a God« (1997) in Rhythmbox, on my mostly up-to-date Debian GNU/Linux testing system. $ uname -a Linux boole 3.2.0-2-amd64 #1 SMP Mon May 21 17:45:41 UTC 2012 x86_64 GNU/Linux ... which specifically is »linux-image-3.2.0-2-amd64 3.2.18-1«. While loading the CD in Rhythmbox, after a few seconds the kernel crashed. I rebooted, tried again, and it crashed again. At http://schwinge.homeip.net/~thomas/tmp/linux-crash-audio-cd.jpeg you can find the panic message (low resolution, sorry), pointing to the SCSI/ATA code. Let me guess: AMD K8? Also, can I get /proc/cpuinfo please? Thanks. -- Regards/Gruss, Boris. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120616181008.gb20...@liondog.tnic
