On Mon, 7 Sep 2020, Ville Syrjälä wrote:
> On Fri, Sep 04, 2020 at 12:21:26AM -0700, Zwane Mwaikambo wrote:
> > I observed this when unplugging a DP monitor whilst a computer is asleep
> > and then waking it up. This left DP chardev nodes still being present on
> > the fil
int minor = iminor(inode);
struct drm_dp_aux_dev *aux_dev;
aux_dev = drm_dp_aux_dev_get_by_minor(minor); <
if (!aux_dev)
return -ENODEV;
file->private_data = aux_dev;
return 0;
}
Fixes: e94cb37b34eb8 ("Add a drm_aux-dev module for reading/writing d
On Wed, 12 Aug 2020, Lyude Paul wrote:
> On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
> > > On Tue, 11 Aug 2020, Daniel Vetter wrote:
> > >
> > > > On Mon, Aug 10, 2020 at
On Wed, 12 Aug 2020, Lyude Paul wrote:
> On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
> > > On Tue, 11 Aug 2020, Daniel Vetter wrote:
> > >
> > > > On Mon, Aug 10, 2020 at
On Tue, 11 Aug 2020, Daniel Vetter wrote:
> On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > Hi Folks,
> > I know this thread eventually dropped off due to not identifying
> > the underlying issue. It's still occuring on 5.8 and in my case it
Hi Folks,
I know this thread eventually dropped off due to not identifying
the underlying issue. It's still occuring on 5.8 and in my case it
happened because the udev device nodes for the DP aux devices were not
cleaned up whereas the kernel had no association with them. I can
On Sat, 25 Jul 2020, Zwane Mwaikambo wrote:
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index d0c63afaf..30d0857e4 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -218,9 +218,12 @@ void ucsi_altmode_updat
The following crash occurs whilst plugging in a Thinkpad USB type C dock
and appears to be affecting other users as seen below;
https://bbs.archlinux.org/viewtopic.php?id=256404
https://forums.linuxmint.com/viewtopic.php?p=1826251
My specific crash is;
[ 565.427757] input: USBPS2 as
On Wed, 13 Feb 2013, Andrew Morton wrote:
> On Wed, 13 Feb 2013 10:55:28 +
> Russell King - ARM Linux wrote:
>
> > Zwane's arm.linux.org.uk email address has not been functional for
> > a number of years now. It's time that all references to it were
> > removed. I no longer have a
On Wed, 13 Feb 2013, Andrew Morton wrote:
On Wed, 13 Feb 2013 10:55:28 +
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
Zwane's arm.linux.org.uk email address has not been functional for
a number of years now. It's time that all references to it were
removed. I no longer
Hi Daniel,
On Tue, 31 Jul 2007, Daniel Drake wrote:
> Hi,
>
> H. Peter Anvin wrote:
> > > So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are
> > > further patches needed?
> > >
> >
> > It should, yes.
>
> It didn't work, and the bug still exists in 2.6.23-rc1: the
Hi Daniel,
On Tue, 31 Jul 2007, Daniel Drake wrote:
Hi,
H. Peter Anvin wrote:
So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are
further patches needed?
It should, yes.
It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is
wrong by
On Mon, 30 Apr 2007, William Lee Irwin III wrote:
> -static char softirq_stack[NR_CPUS * THREAD_SIZE]
> - __attribute__((__aligned__(THREAD_SIZE)));
> +static DEFINE_PER_CPU(char *, softirq_stack);
> +static DEFINE_PER_CPU(char *, hardirq_stack);
>
> -static char
On Mon, 30 Apr 2007, William Lee Irwin III wrote:
-static char softirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static DEFINE_PER_CPU(char *, softirq_stack);
+static DEFINE_PER_CPU(char *, hardirq_stack);
-static char hardirq_stack[NR_CPUS *
On Sun, 4 Mar 2007, Gene Heskett wrote:
> >There will be times when the mainline scheduler feels more interactive
> > than this scheduler, and that is because it has significant unfairness
> > granted towards interactive tasks. This degree of unfairness in an
> > effort to maintain interactivity
On Sun, 4 Mar 2007, Gene Heskett wrote:
There will be times when the mainline scheduler feels more interactive
than this scheduler, and that is because it has significant unfairness
granted towards interactive tasks. This degree of unfairness in an
effort to maintain interactivity has been
On Tue, 27 Feb 2007, Eric W. Biederman wrote:
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
> >>
> >> That's mainly an Andi decision. Let's cc him.
> >
> > Would be good to have
On Tue, 27 Feb 2007, Eric W. Biederman wrote:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
That's mainly an Andi decision. Let's cc him.
Would be good to have Eric also ack
On Mon, 19 Feb 2007, Prarit Bhargava wrote:
> /* For assembly routines */
> +#ifdef CONFIG_HOTPLUG_CPU
> +#define __INIT .section".text","ax"
> +#define __INITDATA .section".data","aw"
> +#else
> #define __INIT .section".init.text","ax"
>
On Mon, 19 Feb 2007, Olaf Hering wrote:
>
> 2.6.20-git14
>
> cp arch/powerpc/configs/g5_defconfig ../O-linus/.config
> time env LC_ALL=C make -k O=../O-linus
> ...
> Building modules, stage 2.
> MODPOST 127 modules
> WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!
>
On Mon, 19 Feb 2007, Andi Kleen wrote:
>
> > I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need
> > a VBE1.2 on x86_64 test.
>
> Does this mean you want to have an updated patch or not?
Nope, i'm happy with the last patch i sent (below to reconfirm).
Thanks
Index:
On Mon, 19 Feb 2007, Andi Kleen wrote:
I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need
a VBE1.2 on x86_64 test.
Does this mean you want to have an updated patch or not?
Nope, i'm happy with the last patch i sent (below to reconfirm).
Thanks
Index:
On Mon, 19 Feb 2007, Olaf Hering wrote:
2.6.20-git14
cp arch/powerpc/configs/g5_defconfig ../O-linus/.config
time env LC_ALL=C make -k O=../O-linus
...
Building modules, stage 2.
MODPOST 127 modules
WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!
make[2]: ***
On Mon, 19 Feb 2007, Prarit Bhargava wrote:
/* For assembly routines */
+#ifdef CONFIG_HOTPLUG_CPU
+#define __INIT .section.text,ax
+#define __INITDATA .section.data,aw
+#else
#define __INIT .section.init.text,ax
-#define __FINIT
On Sun, 18 Feb 2007, Andi Kleen wrote:
> On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote:
> > On Fri, 16 Feb 2007, Andrew Morton wrote:
> >
> > > On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL
> > > PROTECTED]> wrote:
> >
On Sun, 18 Feb 2007, Andi Kleen wrote:
On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote:
On Fri, 16 Feb 2007, Andrew Morton wrote:
On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo [EMAIL
PROTECTED] wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote
On Fri, 16 Feb 2007, Andrew Morton wrote:
> On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 15 Feb 2007, Andrew Morton wrote:
> >
> > > It's not an X problem - the screen is black immediately upon loading
On Fri, 16 Feb 2007, Andrew Morton wrote:
On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo [EMAIL PROTECTED]
wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote:
It's not an X problem - the screen is black immediately upon loading the
kernel.
But I guess you knew
On Thu, 15 Feb 2007, Andrew Morton wrote:
> It's not an X problem - the screen is black immediately upon loading the
> kernel.
>
> But I guess you knew that and you're just after display info:
> http://userweb.kernel.org/~akpm/Xorg.0.log.txt
Thanks, the X log told me your VBE version. I tried
On Thu, 15 Feb 2007, Andrew Morton wrote:
It's not an X problem - the screen is black immediately upon loading the
kernel.
But I guess you knew that and you're just after display info:
http://userweb.kernel.org/~akpm/Xorg.0.log.txt
Thanks, the X log told me your VBE version. I tried to
On Fri, 16 Feb 2007, Kyle McMartin wrote:
> On Thu, Feb 15, 2007 at 10:09:57PM -0800, Zwane Mwaikambo wrote:
> > +ifeq ($(CONFIG_COMPAT),y)
> > +agpgart-y += compat_ioctl.o
> > +endif
> > +
>
> eh?
>
> Couldn't this be?
> agpgart-$(
On Thu, 15 Feb 2007, Andrew Morton wrote:
> On Thu, 15 Feb 2007 21:45:06 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 15 Feb 2007 21:35:35 -0800 (PST) Zwane Mwaikambo <[EMAIL
> > PROTECTED]> wrote:
> >
> > > On Thu, 15 Feb 2007, A
My previous compat AGP patch broke modular AGPGART.
Test built on;
i386 CONFIG_AGP=y,m
x86_64 CONFIG_AGP=y
ia64 CONFIG_AGP=m
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.20-mm1-ia64/drivers/char/agp/Ma
On Thu, 15 Feb 2007, Andrew Morton wrote:
> This makes the long-suffering-but-vigorously-defended Vaio come up with a
> black display. Everything's working OK otherwise. Sort of a Black Screen
> of Life. I wouldn't call it an improvement though.
Bugger, what does your kernel commandline look
On Thu, 15 Feb 2007, Randy Dunlap wrote:
> On Thu, 15 Feb 2007 08:29:49 -0800 (PST) Zwane Mwaikambo wrote:
>
> > VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst
> > uncompressing kernel with some video cards. Make sure we check VBE version
> >
thanks to Tobias Hain for help in testing and investigating the bug.
Tested on;
i386, Chips & Technologies 65548 VESA VBE 1.2
CONFIG_VIDEO_SELECT=Y
CONFIG_FIRMWARE_EDID=Y
Untested on x86_64.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc6-mm1/arch/i386/bo
thanks to Tobias Hain for help in testing and investigating the bug.
Tested on;
i386, Chips Technologies 65548 VESA VBE 1.2
CONFIG_VIDEO_SELECT=Y
CONFIG_FIRMWARE_EDID=Y
Untested on x86_64.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.20-rc6-mm1/arch/i386/boot/video.S
On Thu, 15 Feb 2007, Randy Dunlap wrote:
On Thu, 15 Feb 2007 08:29:49 -0800 (PST) Zwane Mwaikambo wrote:
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst
uncompressing kernel with some video cards. Make sure we check VBE version
before fiddling around with DDC
On Thu, 15 Feb 2007, Andrew Morton wrote:
This makes the long-suffering-but-vigorously-defended Vaio come up with a
black display. Everything's working OK otherwise. Sort of a Black Screen
of Life. I wouldn't call it an improvement though.
Bugger, what does your kernel commandline look
My previous compat AGP patch broke modular AGPGART.
Test built on;
i386 CONFIG_AGP=y,m
x86_64 CONFIG_AGP=y
ia64 CONFIG_AGP=m
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.20-mm1-ia64/drivers/char/agp/Makefile
On Thu, 15 Feb 2007, Andrew Morton wrote:
On Thu, 15 Feb 2007 21:45:06 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007 21:35:35 -0800 (PST) Zwane Mwaikambo [EMAIL
PROTECTED] wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote:
This makes the long-suffering
On Fri, 16 Feb 2007, Kyle McMartin wrote:
On Thu, Feb 15, 2007 at 10:09:57PM -0800, Zwane Mwaikambo wrote:
+ifeq ($(CONFIG_COMPAT),y)
+agpgart-y += compat_ioctl.o
+endif
+
eh?
Couldn't this be?
agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
Yep thay works too
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
> > 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
> > http://download.intel.com/design/chipsets/datashts/30262802.pdf
>
> Ouch. And this kind of thing isn't exactly uncommon.
>
> However if we have the irqs also disabled in the i8259
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
> What I am looking at doing is:
>
> mask
> read io_apic
> -- Past this point no more irqs are expected from the io_apic
> -- Now I work to drain any inflight/pending instances of the irq
> send ipi to all irq destinations cpus and wait for it to
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
What I am looking at doing is:
mask
read io_apic
-- Past this point no more irqs are expected from the io_apic
-- Now I work to drain any inflight/pending instances of the irq
send ipi to all irq destinations cpus and wait for it to return
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
Ouch. And this kind of thing isn't exactly uncommon.
However if we have the irqs also disabled in the i8259 we should
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
> There are not enough details in the justification to really understand
> the issue so I'm asking to see if someone has some more details.
>
> The description makes the assertion that reprograming the ioapic
> when an interrupt is pending is the
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
There are not enough details in the justification to really understand
the issue so I'm asking to see if someone has some more details.
The description makes the assertion that reprograming the ioapic
when an interrupt is pending is the only
(1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f70 (1527MB), size= 1MB: uncachable, count=1
reg03: base=0x5f80 (1528MB), size= 8MB: uncachable, count=1
reg04: base=0xd000 (3328MB), size= 256MB: write-combining, count=1
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTEC
(1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f70 (1527MB), size= 1MB: uncachable, count=1
reg03: base=0x5f80 (1528MB), size= 8MB: uncachable, count=1
reg04: base=0xd000 (3328MB), size= 256MB: write-combining, count=1
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index
On Tue, 30 Jan 2007, Kyle McMartin wrote:
> On Sat, Jan 27, 2007 at 07:28:07PM -0800, Zwane Mwaikambo wrote:
> > Hi Dave,
> > The following video card requires the agpgart driver ioctl
> > interface in order to detect video memory.
> >
>
> Tested with test
On Tue, 30 Jan 2007, Kyle McMartin wrote:
On Sat, Jan 27, 2007 at 07:28:07PM -0800, Zwane Mwaikambo wrote:
Hi Dave,
The following video card requires the agpgart driver ioctl
interface in order to detect video memory.
Tested with testgart.c on parisc64, seems to work alright
Hi Christoph,
Thanks for the input. The following has your recommendations;
drivers/char/agp/Makefile |1
drivers/char/agp/agp.h |2
drivers/char/agp/compat_ioctl.c | 282
drivers/char/agp/compat_ioctl.h | 105 ++
Hi Christoph,
Thanks for the input. The following has your recommendations;
drivers/char/agp/Makefile |1
drivers/char/agp/agp.h |2
drivers/char/agp/compat_ioctl.c | 282
drivers/char/agp/compat_ioctl.h | 105 ++
debian Xorg is at;
http://montezuma.homeunix.net/Xorg.0.log
Cheers,
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
drivers/char/agp/frontend.c | 253
include/linux/agpgart.h | 61 ++
2 files changed, 314 insertions(+)
Index:
debian Xorg is at;
http://montezuma.homeunix.net/Xorg.0.log
Cheers,
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
drivers/char/agp/frontend.c | 253
include/linux/agpgart.h | 61 ++
2 files changed, 314 insertions(+)
Index: linux
On Fri, 10 Sep 2005, Andi Kleen wrote:
> On Fri, Sep 09, 2005 at 10:07:28AM -0700, Zwane Mwaikambo wrote:
> > On Tue, 6 Sep 2005, Ashok Raj wrote:
> >
> > > On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
> > > > On Sat, Sep 03, 2005 at 02:33
On Tue, 6 Sep 2005, Ashok Raj wrote:
> On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
> > On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
> > >
> > > From: Ashok Raj <[EMAIL PROTECTED]>
> > >
> > > Newly introduced physflat_* shares way too much with cluster with
Hello Jan,
On Fri, 9 Sep 2005, Jan Beulich wrote:
> - spin_lock_irq();
> + spin_lock_irqsave(, flags);
> die.lock_owner = smp_processor_id();
> die.lock_owner_depth = 0;
> bust_spinlocks(1);
> }
> + else
> +
On Fri, 9 Sep 2005, Andrew Morton wrote:
> > static void __init MP_processor_info (struct mpc_config_processor *m)
> > {
> > - int ver, apicid;
> > + int ver, apicid, cpu, found_bsp = 0;
> > physid_mask_t tmp;
> >
> > if (!(m->mpc_cpuflag & CPU_ENABLED))
> > @@ -181,6 +181,7 @@
On Fri, 9 Sep 2005, Keith Owens wrote:
> The new ia64 MCA/INIT handlers[1] (think of them as super NMI) run on
> separate stacks. 99% of the changes for these new handlers is ia64
> only code, however they need a couple of scheduler hooks to support
> these extra stacks. The complete patch set
On Fri, 9 Sep 2005, Keith Owens wrote:
The new ia64 MCA/INIT handlers[1] (think of them as super NMI) run on
separate stacks. 99% of the changes for these new handlers is ia64
only code, however they need a couple of scheduler hooks to support
these extra stacks. The complete patch set will
On Fri, 9 Sep 2005, Andrew Morton wrote:
static void __init MP_processor_info (struct mpc_config_processor *m)
{
- int ver, apicid;
+ int ver, apicid, cpu, found_bsp = 0;
physid_mask_t tmp;
if (!(m-mpc_cpuflag CPU_ENABLED))
@@ -181,6 +181,7 @@ static void
Hello Jan,
On Fri, 9 Sep 2005, Jan Beulich wrote:
- spin_lock_irq(die.lock);
+ spin_lock_irqsave(die.lock, flags);
die.lock_owner = smp_processor_id();
die.lock_owner_depth = 0;
bust_spinlocks(1);
}
+ else
+
On Tue, 6 Sep 2005, Ashok Raj wrote:
On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
From: Ashok Raj [EMAIL PROTECTED]
Newly introduced physflat_* shares way too much with cluster with only a
very
On Fri, 10 Sep 2005, Andi Kleen wrote:
On Fri, Sep 09, 2005 at 10:07:28AM -0700, Zwane Mwaikambo wrote:
On Tue, 6 Sep 2005, Ashok Raj wrote:
On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
From
On Thu, 8 Sep 2005, Jan Beulich wrote:
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c 2005-09-01
>
On Thu, 8 Sep 2005, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Move some code unrelated to any dealing with hardware bugs from i386's
> bugs.h to a more logical place.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>
>
On Thu, 8 Sep 2005, Jan Beulich wrote:
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-die-irq/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++ 2.6.13-i386-die-irq/arch/i386/kernel/traps.c 2005-09-07
> 11:39:40.0
Hello Martin,
On Thu, 8 Sep 2005, Martin Vlk wrote:
> I am running a custom-built kernel 2.6.10 on an Intel Mobile P3 processor.
> (Acer
> TravelMate 620)
Please try it with a more recent kernel, there have been some patches
which take into consideration SMIs occuring during the calibration
On Thu, 8 Sep 2005, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> A change not too long ago made i386's genapic symbol no longer be
> exported,
> and thus certain low-level functions no longer be usable. Since
> close-to-
>
On Thu, 8 Sep 2005, Jan Beulich wrote:
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
A change not too long ago made i386's genapic symbol no longer be
exported,
and thus certain low-level functions no longer be usable. Since
close-to-
the-hardware
Hello Martin,
On Thu, 8 Sep 2005, Martin Vlk wrote:
I am running a custom-built kernel 2.6.10 on an Intel Mobile P3 processor.
(Acer
TravelMate 620)
Please try it with a more recent kernel, there have been some patches
which take into consideration SMIs occuring during the calibration
On Thu, 8 Sep 2005, Jan Beulich wrote:
diff -Npru 2.6.13/arch/i386/kernel/traps.c
2.6.13-i386-die-irq/arch/i386/kernel/traps.c
--- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
+0200
+++ 2.6.13-i386-die-irq/arch/i386/kernel/traps.c 2005-09-07
11:39:40.0 +0200
On Thu, 8 Sep 2005, Jan Beulich wrote:
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Move some code unrelated to any dealing with hardware bugs from i386's
bugs.h to a more logical place.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
diff -Npru
On Thu, 8 Sep 2005, Jan Beulich wrote:
diff -Npru 2.6.13/arch/i386/kernel/traps.c
2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c
--- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
+0200
+++
2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c 2005-09-01
On Sun, 4 Sep 2005, Willy Tarreau wrote:
> On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
> > I just bought a new notebook. Here is the output from lspci using the
> > latest
> > pci.ids file from sourceforge:
>
> You seem to be surprized by the contents. When I recently changed
On Sat, 3 Sep 2005, Kyuma Ohta wrote:
> Thanx David,
>
> Written by David Ranson <[EMAIL PROTECTED]>
>at Sat, 03 Sep 2005 09:33:56 +0100 :
> Subject: Re: [x86_64] Exception when using powernowd.
>
> spam.david.trap> Kyuma Ohta wrote:
> spam.david.trap>
> spam.david.trap>
>
On Fri, 2 Sep 2005, Christopher Friesen wrote:
>
> I'm debugging a problem. Unfortunately, I have a module loaded that taints
> the kernel.
>
> Now that that's out of the way, if anyone is still willing to help, the oops
> is below, along with the disassembly of filp_close(). One thing I
On Fri, 2 Sep 2005, Christopher Friesen wrote:
I'm debugging a problem. Unfortunately, I have a module loaded that taints
the kernel.
Now that that's out of the way, if anyone is still willing to help, the oops
is below, along with the disassembly of filp_close(). One thing I don't
On Sat, 3 Sep 2005, Kyuma Ohta wrote:
Thanx David,
Written by David Ranson [EMAIL PROTECTED]
at Sat, 03 Sep 2005 09:33:56 +0100 :
Subject: Re: [x86_64] Exception when using powernowd.
spam.david.trap Kyuma Ohta wrote:
spam.david.trap
spam.david.trap
spam.david.trap Hi,
On Sun, 4 Sep 2005, Willy Tarreau wrote:
On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
I just bought a new notebook. Here is the output from lspci using the
latest
pci.ids file from sourceforge:
You seem to be surprized by the contents. When I recently changed my
ossible
processors, upto NR_CPUS.
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Thanks Alex,
Acked-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
> Index: mm/arch/i386/kernel/smpboot.c
> ===
> --- mm.orig
]
Thanks Alex,
Acked-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: mm/arch/i386/kernel/smpboot.c
===
--- mm.orig/arch/i386/kernel/smpboot.c2005-09-02 15:28:20.0
+0200
+++ mm/arch/i386/kernel/smpboot.c 2005-09
>
> Well I was hoping that someone with knowledge of the low-level Intel model
> differences would pipe up, but they all seem to be in hiding. (Wildly
> bcc's lots of x86 people).
Looks ok to me, they haven't changed the performance counter setup on
those processors.
Acked-by: Z
On Fri, 19 Aug 2005, Andi Kleen wrote:
> > Thanks for the feedback, ugly indeed, i was really trying to avoid adding
> > a new API function or extra cpu_* variables. Ok, here is an
> > early_node_to_cpumask instead.
>
> Thinking about it again it's most likely broken with CPU hotplug anyways
>
On Fri, 19 Aug 2005, Andi Kleen wrote:
> On Thu, Aug 18, 2005 at 08:07:53PM -0600, Zwane Mwaikambo wrote:
> > node_to_cpumask on non NUMA systems is broken if used before all the
> > processors have been brought up as it returns cpu_online_map, as opposed
> > to NUMA i3
normal runtime. This was found whilst testing a
patch which does node dependent work before APs have all gone online.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/include/asm-i386/topology.h
=
normal runtime. This was found whilst testing a
patch which does node dependent work before APs have all gone online.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc5-mm1/include/asm-i386/topology.h
===
RCS
On Fri, 19 Aug 2005, Andi Kleen wrote:
On Thu, Aug 18, 2005 at 08:07:53PM -0600, Zwane Mwaikambo wrote:
node_to_cpumask on non NUMA systems is broken if used before all the
processors have been brought up as it returns cpu_online_map, as opposed
to NUMA i386 systems which does it earlier
On Fri, 19 Aug 2005, Andi Kleen wrote:
Thanks for the feedback, ugly indeed, i was really trying to avoid adding
a new API function or extra cpu_* variables. Ok, here is an
early_node_to_cpumask instead.
Thinking about it again it's most likely broken with CPU hotplug anyways
whatever
would pipe up, but they all seem to be in hiding. (Wildly
bcc's lots of x86 people).
Looks ok to me, they haven't changed the performance counter setup on
those processors.
Acked-by: Zwane Mwaikambo [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, 15 Aug 2005, Con Kolivas wrote:
> > Why not just set it to a fixed frequency, suspend and then on boot resume
> > to a fixed frequency and let the timer tick code eventually switch back.
>
> It's probably worth holding off further discussion on this point till the SMP
> scalable version
On Mon, 15 Aug 2005, Harald Welte wrote:
> On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote:
>
> > Is the following patch correct? ip_conntrack_event_cache should never be
> > called with ip_conntrack_lock held and ct_add_counters does not need
On Mon, 15 Aug 2005, Harald Welte wrote:
On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote:
Is the following patch correct? ip_conntrack_event_cache should never be
called with ip_conntrack_lock held and ct_add_counters does not need to be
called with ip_conntrack_lock
On Mon, 15 Aug 2005, Con Kolivas wrote:
Why not just set it to a fixed frequency, suspend and then on boot resume
to a fixed frequency and let the timer tick code eventually switch back.
It's probably worth holding off further discussion on this point till the SMP
scalable version is
On Sun, 14 Aug 2005, James Cleverdon wrote:
> > > +static int next_irq = 16;
> >
> > Won't this need a lock for hotplug later?
>
> That's what I thought originally, but maybe not. We initialize all RTEs
> and assign IRQs+vectors fairly early in boot, plus store the results in
> arrays.
On Sun, 14 Aug 2005, Robert Love wrote:
> On Sun, 2005-08-14 at 20:40 -0600, Zwane Mwaikambo wrote:
>
> > I'm new here, if the inode isn't being watched, what's to stop d_delete
> > from removing the inode before fsnotify_unlink proceeds to use it?
>
> Nothing.
On Sun, 14 Aug 2005, Phil Dier wrote:
> I just got this:
>
> Unable to handle kernel paging request at virtual address eeafefc0
> printing eip:
> c0188487
> *pde = 00681067
> *pte = 2eafe000
> Oops: [#1]
> SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU:1
> EIP:0060:[]Not
On Sun, 14 Aug 2005, Rafael J. Wysocki wrote:
> I've got the following BUG on Asus L5D (x86-64) with the 2.6.13-rc5-mm1
> kernel:
>
> BUG: rwlock recursion on CPU#0, nscd/3668, 8817d4a0
>
> Call Trace:{add_preempt_count+105}
> {rwlock_bug+114}
>{_raw_write_lock+62}
>
1 - 100 of 335 matches
Mail list logo
