On Thu, Dec 27, 2012 at 07:51:26PM +0100, Borislav Petkov wrote:
> > commit bb3cda32f9586e13c5d3dde6c83a914bb2d7f87f
> > Author: Yinghai Lu
> > Date: Mon Dec 24 18:00:21 2012 -0800
> >
> > x86, mm: add generic kernel/ident mapping helper
> >
On Fri, Dec 28, 2012 at 12:13:06AM -0800, Yinghai Lu wrote:
> so will stay with alloc.
"alloc" is too generic. So call it 'get_one_pgt_page' or
'alloc_pgt_page' or something descriptive to say what it does than
simply 'alloc'. 'alloc' can be anything - it could mean allocation hints
or flags or wh
On Thu, Dec 27, 2012 at 04:34:03PM -0800, Yinghai Lu wrote:
> do you like to name it with kernel_ident_mapping_info ?
We have already kernel_ident_mapping_init so the first three words are
already the same. Besides, you're differentiating between kernel mapping
or ident mapping so ident_mapping_in
picking it up directly since the fb maintainer is absent, reportedly.
Tested-by: Borislav Petkov
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
>
> Is this available somewhere? May I have a look at it?
http://marc.info/?l=linux-kernel&m=135581534620383
The for-x86-boot-v7 and -v8 branches.
HTH.
--
R
On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote:
> git-ls-files | xargs fgrep 'struct f2fs_inode'
>
> That returns instantly and tells me where to look. If you can do an
> instant brute force search what is the point of an index?
Not if you're using a lame-ass laptop with a rot
On Fri, Dec 28, 2012 at 11:03:40PM +0100, Geert Uytterhoeven wrote:
> That's the first run. Now everything is in the buffer cache (assumed
> you have enough RAM), and try again...
Right, until you do something else on the box requiring just the right
amount of memory to overflow the buffer cache w
+ Tony.
On Sun, Dec 30, 2012 at 01:45:40AM +0800, Du Jiulun wrote:
> [1.] One line summary of the problem:
>
> Random kernel panic and system freeze when watching video on my linux laptop
>
> [2.] Full description of the problem/report:
>
> I'm experiencing random (but frequent) kernel panics a
06bab0...@niklaas-baudet.net
> T420s - 20120608080824.gs25...@hexapodia.org
> W520 - 20121008181050.gf2...@ericlaptop.home.christensenplace.us
>
> Signed-off-by: Richard Hartmann
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send
On Mon, Dec 31, 2012 at 02:42:07AM +0800, Du Jiulun wrote:
> CPU 2: Machine Check Exception: 4 Bank 2: b205
> TSC 6568f53a1cee
> HARDWARE ERROR. This is *NOT* a software problem!
> Please contact your hardware vendor
> CPU 2 BANK 2 TSC 6568f53a1cee
> TIME 1356717945 Sat Dec 29 02:05:45
On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
> I ended up also that same commit after bisecting from current 3.8
> master.
>
> 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon
> 3000] It is ASUS M5A78L-M/USB3 with integrated GPU.
>
> I cannot even boot unless
On Tue, Jan 01, 2013 at 09:34:16AM -0800, H. Peter Anvin wrote:
> Yes, but stylistically: we don't use uintptr_t in Linux, but rather
> "unsigned long".
Hmmkay,
Stefan, care to redo your patch and sum up this discussion to the commit
message for further reference?
Btw, there is some funny usage
ts it, then add an:
> Acked-by: Tony Luck
> to all three parts.
Ditto.
Acked-by: Borislav Petkov
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Thu, Jan 03, 2013 at 04:48:20PM -0800, Yinghai Lu wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-boot
>
> and it is on top of linus's tree 2013-01-03
> plus tip:x86/mm, tip:x86/mm2
This is causing a merge conflict when merging tip:x86/mm
On Thu, Jan 03, 2013 at 04:48:21PM -0800, Yinghai Lu wrote:
> During debugging loading kernel above 4G, found one page if is not used
> in BRK with early page allocation.
>
> pgt_buf_top is address that can not be used, so should check if that new
> end is above that top, otherwise last page will
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
> From: Alex Deucher
> Date: Wed, 2 Jan 2013 18:30:21 -0500
> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>
> count must be a multiple of 2.
>
> Cc: Borislav Petkov
> Cc: Markus Tr
On Thu, Jan 03, 2013 at 04:48:23PM -0800, Yinghai Lu wrote:
> Trampoline code is executed by APs with kernel low mapping.
> We need to set trampoline code to EXEC early before we do smp
> AP bootings.
"... before we boot the APs."
>
> Found the problem after switching to #PF handler set page tab
On Fri, Jan 04, 2013 at 09:25:14AM -0500, Steven A. DuChene wrote:
> I have a few systems with AMD processors. One is a AMD Phenom II based
> system which uses a k10temp kernel module to get the CPU temperature.
> Another system has an Athlon64 processor which apparently is supposed
> to use a k8te
On Thu, Jan 03, 2013 at 04:48:40PM -0800, Yinghai Lu wrote:
> static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
> {
> + struct x86_mapping_info info = {
> + .alloc_pgt_page = alloc_pgt_page,
> + .context= image,
> + .pmd_fla
On Fri, Jan 04, 2013 at 12:58:15PM -0800, Yinghai Lu wrote:
> more than that, that set_real_mode_permissions reference is wrong,
> actually it is set_real_mode.
Huh, set_real_mode_permissions is the name of the function above which the
comment is located. There's no set_real_mode. What do you mean
On Thu, Jan 03, 2013 at 04:48:24PM -0800, Yinghai Lu wrote:
> +int kernel_mapping_init(pgd_t *pgd_page, unsigned long addr, unsigned long
> end)
> +{
> + struct x86_mapping_info info = {
> + .alloc_pgt_page = alloc_pgt_page,
> + .pmd_flag = __PAGE_KERNEL_LARGE,
>
On Sat, Jan 05, 2013 at 08:00:19PM +0800, Hillf Danton wrote:
> Jiri posted similar locking issue at
> https://lkml.org/lkml/2013/1/4/380
>
> Take a look?
Yeah, it looks like the same issue. I'll try his patch on Monday.
Thanks for letting me know.
--
Regards/Gruss,
Boris.
--
To unsubs
On Fri, Jan 04, 2013 at 01:50:18PM -0800, Yinghai Lu wrote:
> On Thu, Jan 3, 2013 at 11:17 PM, Borislav Petkov wrote:
> > On Thu, Jan 03, 2013 at 04:48:21PM -0800, Yinghai Lu wrote:
> >> During debugging loading kernel above 4G, found one page if is not used
> >> in BRK
On Fri, Jan 04, 2013 at 02:19:17PM -0800, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 1:19 PM, Borislav Petkov wrote:
> > On Thu, Jan 03, 2013 at 04:48:24PM -0800, Yinghai Lu wrote:
> >> +int kernel_mapping_init(pgd_t *pgd_page, unsigned long addr, unsig
On Fri, Jan 04, 2013 at 02:04:05PM -0800, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 1:01 PM, Borislav Petkov wrote:
> > On Thu, Jan 03, 2013 at 04:48:40PM -0800, Yinghai Lu wrote:
> >> static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
> &g
On Fri, Jan 04, 2013 at 02:13:11PM -0800, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 1:04 PM, Borislav Petkov wrote:
> > On Fri, Jan 04, 2013 at 12:58:15PM -0800, Yinghai Lu wrote:
> >> more than that, that set_real_mode_permissions reference is wrong,
> >> a
On Tue, Dec 18, 2012 at 07:13:17AM -0500, Jeff Layton wrote:
> I agree that we often need cifsFYI debug info in order to troubleshoot
> problems. The question here though is whether compiling those in ought
> to be the default.
>
> In generic distro kernels, I think we do want that turned on even i
On Tue, Dec 18, 2012 at 10:07:02AM -0500, Jeff Layton wrote:
> Yeah, not many do, but presumably they'll set it once and forget about
> it. Once someone straightens them out, they should rarely break.
>
> OTOH, the value of defaulting to "N" is pretty low here. Maybe it
> would just be best to just
On Mon, Dec 17, 2012 at 01:39:48PM -0600, Jacob Shin wrote:
> Add MCE decoding logic for AMD Family 16h processors.
>
> Signed-off-by: Jacob Shin
> ---
> drivers/edac/mce_amd.c | 120
> ++--
> drivers/edac/mce_amd.h |6 +++
> 2 files changed, 122
On Mon, Dec 17, 2012 at 11:09:43AM -0800, Joe Perches wrote:
> This needs a new test here to avoid chirping
> on files that aren't added, deleted or renamed.
>
> next if ($realfile eq $modifiedfile);
Hmm, I don't think that catches file renames when using the normal 'git
diff' outpu
On Tue, Dec 18, 2012 at 12:09:45PM -0600, Jacob Shin wrote:
> I think I meant to say as in uu_msgs[] above. HWA stands for "Hardware
> Assertion" ..
Yep, I got it. You mean this:
const char * const uu_msgs[] = { "RESV", "RESV", "HWA", "RESV" };
and HWA is bit setting 0x2. You don't need to add a
On Tue, Dec 18, 2012 at 10:24:29AM -0800, Joe Perches wrote:
> or without all the unnecessary parens and using char:
>
> pr_cont("%cBUFF parity error\n", xec == 4 ? 'I' : 'O');
Char is fine, the parens make this more readable when you look at it
again after a couple of month
On Tue, Dec 18, 2012 at 11:34:41AM -0800, Joe Perches wrote:
> If no patch is attached, you should get
>
> ERROR: Does not appear to be a unified-diff format patch
Well, it needs to handle the case where a patch simply and only renames
a file.
Then, even if a patch follows:
diff --git a/README b
On Tue, Dec 18, 2012 at 12:36:37PM -0800, Joe Perches wrote:
> You renamed README which is one of the filenames used
> when checkpatch verifies the top-level dir kernel tree.
>
> Don't do that, README is a required filename.
$ git mv scripts/checkpatch{,-2}.pl
$ git diff --cached HEAD -- | ./scri
On Mon, Dec 17, 2012 at 11:15:32PM -0800, Yinghai Lu wrote:
> Now we have limit kdump reseved under 896M, because kexec has the limitation.
> and also bzImage need to stay under 4g.
>
> To make kexec/kdump could use range above 4g, we need to make bzImage and
> ramdisk could be loaded above 4g.
>
On Tue, Dec 18, 2012 at 02:10:59PM -0800, Joe Perches wrote:
> On Tue, 2012-12-18 at 15:06 -0600, Jacob Shin wrote:
> > Add MCE decoding logic for AMD Family 16h processors.
>
> More trivia:
>
> > diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
> []
> > @@ -64,6 +64,10 @@ EXPORT_SYMB
Hi Yinghai,
On Tue, Dec 18, 2012 at 03:08:16PM -0800, Yinghai Lu wrote:
> On Tue, Dec 18, 2012 at 2:43 PM, Borislav Petkov wrote:
> > you don't care about properly written commit messages, as long as they work
>
> It seems that you are quite upset somehow.
sorry if
Hey Jörn,
On Tue, Jul 24, 2012 at 10:28:20PM +0200, Borislav Petkov wrote:
> Ok, thanks for taking the time to explain this - very interesting
> stuff.
>
> So, as far as I'm concerned blockconsole is ready for shipping! 8-)
you're probably very busy so I'll b
On Tue, Dec 18, 2012 at 01:33:19PM -0800, Joe Perches wrote:
> On Tue, 2012-12-18 at 21:47 +0100, Borislav Petkov wrote:
> > Oh well, enough games for today.
>
> Maybe try this tomorrow?
$ git diff --cached HEAD -- | ./scripts/checkpatch.pl --strict -
Use of uninitialized val
On Tue, Dec 18, 2012 at 07:30:06PM -0800, Yinghai Lu wrote:
> change that too:
> ---
> Subject: [PATCH] x86, mm: Fix page table early allocation offset checking
>
> During debug load kernel above 4G, found one page if is not used in BRK
> and it should be with early page allocation.
>
> pgt_buf_t
On Mon, Dec 17, 2012 at 11:15:58PM -0800, Yinghai Lu wrote:
> +static u64 __init get_mem_size(unsigned long limit_pfn)
> +{
> + int i;
> + u64 pages = 0;
> + unsigned long start_pfn, end_pfn;
> +
> + for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, NULL) {
> +
On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
> On 12/15/2012 03:15 PM, Yinghai Lu wrote:
> >>
> >>That is for the kernel region itself (that code is actually unchanged from
> >>the current code), and yes, we could cap that one to _end if there are
> >>systems which have bugs in t
On Tue, Dec 18, 2012 at 07:37:14PM -0800, Yinghai Lu wrote:
> update to :
>
> ---
> Subject: [PATCH] x86, mm: make pgd next calculation consistent with pud/pmd
>
> Just like the way we calculate next for pud and pmd, aka
> round down and add size.
>
> also remove not needed next checking, just p
On Tue, Dec 18, 2012 at 07:44:55PM -0800, Yinghai Lu wrote:
> On Sat, Dec 15, 2012 at 9:06 AM, Borislav Petkov wrote:
> > On Thu, Dec 13, 2012 at 02:01:57PM -0800, Yinghai Lu wrote:
> >> We are short of space before 0x200 that is entry for startup_64.
> >
> > And y
On Wed, Dec 19, 2012 at 01:58:57PM -0800, Yinghai Lu wrote:
> On Wed, Dec 19, 2012 at 12:57 PM, Borislav Petkov wrote:
> > On Tue, Dec 18, 2012 at 07:44:55PM -0800, Yinghai Lu wrote:
> >
> > So this explains what you're doing but I'd like to know why?
> >
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
> The real question is what we can do to mitigate the damage.
Let's try the first thing that comes to mind: waste a variable MTRR on
it:
[0.00] MTRR variable ranges enabled:
[0.00] 0 base mask 8
On Wed, Dec 19, 2012 at 04:55:06PM -0600, Jacob Shin wrote:
> Well, really the problem is with any memory hole above 4GB that is too
> big to be covered by variable range MTRRs as UC.
Why, their PhysBase field is the 40 MSB bits of the physical address.
That should be more than TB.
--
Regards/Gr
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
> I can check but right, they might be used up. But even if we had slots
> available, the memory range that needs to be covered is in large
> enough address and aligned in such a way that you cannot cover it with
> variable range MTRRs.
A
On Wed, Dec 19, 2012 at 03:17:59PM -0800, H. Peter Anvin wrote:
> I presume with "too big" he really means "oddly shaped".
Yeah, that's why it could be enlarged a little in order to adjust it to
the MTRR scheme. This is what the BKDG says about it:
PhysMask and PhysBase are used together to deter
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
[ … ]
> Now, calming down a little bit, we are definitely dealing with BIOS
> engineers and so f*ckups are going to happen, again and again.
Yeppers.
> The only truly "safe" option is to limit early mappings to 4K pages.
> This is
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
> We are trying to discuss mitigation strategies with you, but you
> haven't really given us any useful information, e.g. what happens near
> the various boundaries of the hole, what could trigger prefeching into
> the range, and what
On Wed, Dec 19, 2012 at 04:02:25PM -0800, H. Peter Anvin wrote:
> The goal should be to have this into -tip and -next by the middle of
> January in order to make the 3.9 merge window, I think.
...and an easy back-out strategy in case there are too many issues while
testing. Maybe don't merge it in
bogus because ata_read_native_max_address either
returns a sensible max_sectors aka native_sectors through its second
arg pointer or an error value which is properly handled in its caller
ata_hpa_resize().
So shut up gcc already.
Cc: Jeff Garzik
Cc: linux-...@vger.kernel.org
Signed-off-by: Bor
On Thu, Dec 20, 2012 at 01:01:59PM +, Alan Cox wrote:
> Net lose IMHO - better to file a gcc bug report
Ok, I'll try that. Want on CC?
The good thing is, it is a new issue in 4.7 since it doesn't trigger
with 4.6:
$ make CC=gcc-4.6 drivers/ata/libata-core.o
make[1]: Nothing to be done for `
On Thu, Dec 20, 2012 at 04:04:23PM +0100, Borislav Petkov wrote:
> On Thu, Dec 20, 2012 at 01:01:59PM +, Alan Cox wrote:
> > Net lose IMHO - better to file a gcc bug report
> Ok, I'll try that. Want on CC?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55759
--
Regards/Gruss,
On Tue, Dec 18, 2012 at 03:06:09PM -0600, Jacob Shin wrote:
> The following patchset enables MCE decoding support for AMD Family 16h
> processors.
>
> Changes in V2:
> * Changed if/else style and pr_cont usage per feedback from:
> https://lkml.org/lkml/2012/12/17/365
>
> * Merged f14h and f16h
On Tue, Dec 18, 2012 at 11:56:10PM +0100, Borislav Petkov wrote:
> So, if you'd like, you could wait until I apply Jacob's patches and
> push that git branch to kernel.org and then write a patch ontop
> removing all the exports except pp_msgs (you could add them to the
&g
concatenation warning for you to try.
Yep, looks good. Add a proper commit message and ship it.
Tested-by: Borislav Petkov
Btw, you should credit Cesar in the commit message for the idea.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To
On Fri, Dec 21, 2012 at 05:20:18PM +0900, Namhyung Kim wrote:
> Now we have GTK2 implementation, add a new --gtk option to use it.
>
> Cc: Pekka Enberg
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/Documentation/perf-annotate.txt | 4
> tools/perf/builtin-annotate.c | 5 +++
On Fri, Dec 21, 2012 at 11:14:21AM +0530, Vineet Gupta wrote:
> Hi David,
>
> Not sure if this was report/fixed already - but as of today's Linus tree
> (tip has commit 96680d2), I'm seeing a build breakage due to a trivial
> missing def for nfs_fscache_wait_on_invalidate.
>
> Following fixes it
On Fri, Dec 21, 2012 at 03:09:48PM +, Yu, Fenghua wrote:
> > Why loading microcode this early is important? Why it is bad to load
> > it at the end of (initial) boot?
> >
> If not loading microcode early, we may hit some issues (e.g. PSE on
> Atom) and disable some CPU features. These issues ca
On Fri, Dec 21, 2012 at 06:16:46PM +0900, Namhyung Kim wrote:
> Current setup_browser() code checks the stdin to be a tty and if
> not it assumes piping to other commands so set the use_browser to 0
> (stdio) and disables GTK output.
>
> Maybe we can change this behavior for --gtk case.
Change it
now if I'm being too
overzealous. I'd like to send this out for 3.8 still so that no exports
get cast in stone.
Thanks.
--
From: Borislav Petkov
Date: Fri, 21 Dec 2012 17:03:58 +0100
Subject: [PATCH] x86, MCE: Retract most UAPI exports
Retract back most macro definitions which went into the
u
On Fri, Dec 21, 2012 at 06:22:10PM -0800, Tejun Heo wrote:
> Hello, Andrew.
>
> On Fri, Dec 21, 2012 at 06:15:23PM -0800, Andrew Morton wrote:
> > On Fri, 21 Dec 2012 17:57:15 -0800 Tejun Heo wrote:
> >
> > > There's no need to test whether a (delayed) work item in pending
> > > before queueing,
Top-posting so that the rest can remain untouched.
Right, so AFAICT, something is holding rtnl_mutex (probably some
rtnetlink traffic) and device_rename() is doing kstrdup with
GFP_KERNEL which, among others, has __GFP_WAIT and *that* triggers the
might_sleep_if() check in slab_pre_alloc_hook():
On Sat, Dec 22, 2012 at 10:10:28AM -0800, Eric Dumazet wrote:
> RTNL is a mutex, its perfectly valid to use GFP_KERNEL while holding a
> mutex.
Right, sorry. The check fires because we have preemption disabled.
> As replied before your mail, fix for the problem is already in David
> tree.
Yep, s
Hi Alex,
got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere
down radeon_fence_wait_seq, judging by the error messages.
And this doesn't happen with 3.7, of course.
Let me know if you need any more info, thanks.
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote:
> What chip is this?
I think it is RV635. Here's the whole 3.8-rc1 dmesg.
[0.00] Linux version 3.8.0-rc1 (boris@liondog) (gcc version 4.7.2
(Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012
[0.00] Command
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
> Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspen
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
> no_wb=1 should work.
Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever - so that we can save us all
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote:
> modinfo radeon
>
> will give a list assuming you use modules, I think all of them need =.
Yep, that is one way of getting that info, thanks. I always go and look
at Documentation/kernel-parameters.txt and forget about modinfo.
As yo
On Sun, Dec 23, 2012 at 04:14:39AM +0100, Sedat Dilek wrote:
> Hi,
>
> after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
> function called from invalid context"" [1] I decided to pull-in
> net.git#master (up to commit 9b1536c490d5: "bridge: call
> br_netpoll_disable in br_add_if") on
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote:
> (If you don't use modules: git grep MODULE_PARM_DESC --
> drivers/gpu/drm/radeon/ )
Yeah.
> You may have hit the same issue as I, see:
> http://thread.gmane.org/gmane.comp.video.dri.devel/78328
Yes, it very much looks like it
On Sun, Dec 23, 2012 at 06:49:55AM +0100, Mike Galbraith wrote:
> Looks a lot like my driver experience with older kernels, I had to use
> the external driver in the rare event that I needed wireless to work.
> The in tree driver works peachy these days (needed it recently, was
> pleasantly surpris
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
> Right, let me try that and report back.
Yep, looks like reverting the above commit fixes it - the boston.com
website loads just fine.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is f
On Sun, Dec 23, 2012 at 10:00:26AM -0800, Yinghai Lu wrote:
> On Sun, Dec 23, 2012 at 6:33 AM, H. Peter Anvin wrote:
> > Explanation please?
>
> you have following change in the patch
>
> /* Finally jump to run C code and to be on real kernel address
> * Since we are running on i
On Sun, Dec 23, 2012 at 01:13:20PM -0600, Larry Finger wrote:
> Again a different driver! What do you mean "in a bunch of networks"?
> How am I supposed to duplicate the conditions with descriptions like
> this?
A "bunch of networks" means, everytime I was at a coffee shop or
similar, I'd try to u
On Sun, Dec 23, 2012 at 08:54:37PM -0800, H. Peter Anvin wrote:
> Makes sense. Ljmpq it is. A comment might be useful.
Yes, a LRETQ comment is definitely useful so that we know. Yinghai,
please add it the next time you're rebasing. Btw, which branch is the
current one for that patchset so that p
On Mon, Dec 24, 2012 at 02:03:24PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> Signed-off-by: Wei WANG
> ---
> drivers/mfd/rtsx_pcr.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index 3a44efa..fa2c2bc 100644
> ---
On Mon, Dec 24, 2012 at 02:03:30PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> Signed-off-by: Wei WANG
> ---
> drivers/mfd/rtsx_pcr.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index fa2c2bc..2ee6be5 100644
>
On Mon, Dec 24, 2012 at 03:04:59PM +0900, Namhyung Kim wrote:
> Right. I also have no idea what's the best way to handle --gtk option
> with the piped output. I can think of 3 options for this:
>
> 1) exit with a error message
> 2) honor --gtk option and launch a gui browser
I could befriend #2
On Mon, Dec 24, 2012 at 02:03:56PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> WARNING: Avoid CamelCase:
> + u8 N, min_N, max_N, clk_divider;
>
> WARNING: Avoid CamelCase:
> + u8 N, min_N, max_N, clk_divider;
>
> Signed-off-by: Wei WANG
> ---
> drivers/mfd/rtsx_pcr.c
On Mon, Dec 24, 2012 at 10:33:34AM -0800, Tejun Heo wrote:
> If one looks at something happening in a path as cold as memory
> hotplug and thinks about optimizing a coupld memory accesses, the
> person's priorities need serious reconsideration. I think approaches
> like that are actively harmful. T
On Mon, Dec 24, 2012 at 11:07:23AM -0800, Tejun Heo wrote:
> And that's broken. It seems trivial but it really isn't and trying to
> optimize things like that in cold paths is just a bad idea. Not enough
> people will pay attention to them and they will stay subtly broken for
> a very long time. So
On Mon, Dec 24, 2012 at 10:45:20AM -0800, Tejun Heo wrote:
> I was confused a bit there. We can't. Nothing guarantees that the
> queuer sees the cleared PENDING before the work item starts execution,
> and I think ipc memory hotplug could also be broken from that.
Stupid question: why not clear PE
On Mon, Dec 24, 2012 at 07:29:14PM -0800, Tejun Heo wrote:
> The behavior is primarily because we want to enable workqueue users
> to guarantee that a full work item execution happens at least once
> after certain event happens. ie. Let's say there's a work item which
> processes data generated by
On Mon, Dec 24, 2012 at 09:50:11PM -0700, Shuah Khan wrote:
> Saw the same error and after reading this thread, reverted the
>
> Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2.
>
> drm/radeon: use async dma for ttm buffer moves on 6xx-SI
>
> and the problem is gone. In my case, it is a solid hang
from x86/mce. Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: Tony Luck
> Cc: Borislav Petkov
> Cc: linux-e...@vger.kernel.org
> ---
> Please let me know how this patch should be routed. I can take it
> through the workqueue tree if necessary.
>
> T
On Tue, Dec 25, 2012 at 10:43:03AM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> In function rtsx_pci_add_sg_tbl, the statement "ptr++" is useless.
>
> Signed-off-by: Wei WANG
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from
On Tue, Dec 25, 2012 at 10:43:09AM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> Signed-off-by: Wei WANG
This one is still missing a commit message. You might want to write some
blubber about the hardware supporting only 32-bit DMA or whatever the
real reason is.
Also, with the wh
proper to use macro definitions here to
> replace these variables.
>
> Signed-off-by: Wei WANG
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
On Tue, Dec 25, 2012 at 02:38:09AM -0500, bbi5291 wrote:
> When the init process is created on system startup, does it have any
> open file descriptors? If so, where do they point?
$ tree /proc/1/fd
/proc/1/fd
└── 10 -> /run/initctl
0 directories, 1 file
--
Regards/Gruss,
Boris.
Sent from
On Mon, Dec 24, 2012 at 08:04:18PM -0800, Yinghai Lu wrote:
> well, I updated for-x86-boot-v7 that stop #PF handler after
> init_mem_mapping.
>
> it has fix for AMD system aka reverting far jmp to ret.
-v7?
You told me yesterday -v8 is the current branch. Do you have -v7 which
does break KGDB and
On Mon, Dec 24, 2012 at 05:06:01PM -0800, H. Peter Anvin wrote:
> Could this be the ljmpq problem that Borislav reported
> (Intel implemented ljmpq, AMD didn't, and I was tempted by a
> micro-optimization which broke AMD which made it into the patchset)?
It has to be. Just booted Yinghai's -v8 in
First of all,
please do not top-post. You can search the net for why top-posting is
discouraged.
On Tue, Dec 25, 2012 at 06:25:11AM -0500, bbi5291 wrote:
> Well, that can't be right---I grepped the kernel source for "initctl"
> and got no results.
That's because it is a named pipe.
> Besides, i
On Thu, Nov 15, 2012 at 01:11:15PM -0600, Daniel Santos wrote:
> Ah yes. I did notice that at one point, but I think it slipped
> my mind. Also, the kernel has introduced me to the usage of the
> !! construct, of which I'm well versed in its affects in various
> situations and how gcc's optimizer e
On Thu, Nov 15, 2012 at 01:44:45PM -0600, Daniel Santos wrote:
> Yeah, I agree. Also, with the complexity, I think a few more comments
> can be helpful in compiler.h to clarify what these macros are for more
> specifically.
>From what I've read so far the comments are fine but if you want to be
mo
On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> One possibility is that BIOS already incorporated all patches (which
> typically is the case) and so the driver doesn't have to do anything.
/proc/cpuinfo contains ucode version and the processor's f/m/s, which
is enough informatio
On Mon, Oct 29, 2012 at 10:06:15AM -0700, Linus Torvalds wrote:
> On Mon, Oct 29, 2012 at 9:57 AM, Borislav Petkov wrote:
> >
> > On current AMD64 processors,
>
> Can you verify that this is true for older cpu's too (ie the old
> pre-64-bit ones, say K6 and ori
On Fri, Nov 16, 2012 at 04:46:20PM +0800, Daniel J Blueman wrote:
> Yep, the expected memory controller indexes, population, column-strobe
> rows, banks and sysfs paths are detected on my hex-northbridge fam10h
> box with 3.7-rc5 with these patches:
Thanks, it looks correct to me.
--
Regards/Gru
801 - 900 of 13227 matches
Mail list logo
