On Tuesday 19 February 2008 18:10:35 Pierre Ossman wrote:
> Primarily, the udev startup locks up. If I abort it, it just locks up on
> more or less every action after that. Some quick debugging showed that I
> had a whole bunch of modprobe processes sitting around. The new
>
On Tuesday 19 February 2008 18:10:35 Pierre Ossman wrote:
Primarily, the udev startup locks up. If I abort it, it just locks up on
more or less every action after that. Some quick debugging showed that I
had a whole bunch of modprobe processes sitting around. The new
On Tuesday 29 January 2008 01:12:33 Pallipadi, Venkatesh wrote:
> Patch looks good.
> If BIOS does not report HPET on more of such systems we may have to add
> other chipsets in ICH9 family (ICH9_8, ...) as well.
>
> Acked-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Hi Ingo,
Are you going to
On Tuesday 29 January 2008 01:12:33 Pallipadi, Venkatesh wrote:
Patch looks good.
If BIOS does not report HPET on more of such systems we may have to add
other chipsets in ICH9 family (ICH9_8, ...) as well.
Acked-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Hi Ingo,
Are you going to pick this
and as a clocksource for
the running kernel (2.6.24 here) after applying this patch.
Force enabled HPET at base address 0xfed0
hpet clockevent registered
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 64-bit timers, 14318180 Hz
Signed-off-by: Alistair John Strachan <[EMAIL PROTECTED]>
---
arch/x86/
Bugzilla for this report: http://bugzilla.kernel.org/show_bug.cgi?id=9468
On Thursday 10 January 2008 17:28:22 you wrote:
> I saw your thread on LKML about the problem with r8169. Did you ever
> find a patch or solution?
No, we have not diagnosed the cause of the problem, beyond the swiotlb
Bugzilla for this report: http://bugzilla.kernel.org/show_bug.cgi?id=9468
On Thursday 10 January 2008 17:28:22 you wrote:
I saw your thread on LKML about the problem with r8169. Did you ever
find a patch or solution?
No, we have not diagnosed the cause of the problem, beyond the swiotlb
On Saturday 15 December 2007 21:24:09 Gene Heskett wrote:
> On Saturday 15 December 2007, Robert Hancock wrote:
> >Gene Heskett wrote:
> >> Greetings;
> >>
> >> When I asked about a sata controller earlier this week, I gave a link to
> >> it. Unforch (maybe) when it actually arrived, the cards box
On Saturday 15 December 2007 21:24:09 Gene Heskett wrote:
On Saturday 15 December 2007, Robert Hancock wrote:
Gene Heskett wrote:
Greetings;
When I asked about a sata controller earlier this week, I gave a link to
it. Unforch (maybe) when it actually arrived, the cards box showed a
On Tuesday 11 December 2007 23:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
>
On Tuesday 11 December 2007 23:31:18 Rene Herman wrote:
Good day.
Would some people on x86 (both 32 and 64) be kind enough to compile and run
the attached program? This is about testing how long I/O port access to
port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
On Sunday 25 November 2007 01:27:54 Francois Romieu wrote:
> Francois Romieu <[EMAIL PROTECTED]> :
> > Alistair John Strachan <[EMAIL PROTECTED]> :
> > [...]
> >
> > > The "choke" affects other devices on the system too, notably libata,
> &
On Sunday 25 November 2007 00:25:10 Francois Romieu wrote:
> Alistair John Strachan <[EMAIL PROTECTED]> :
> [...]
>
> > The "choke" affects other devices on the system too, notably libata,
> > which does not recover gracefully. In my logs, I see a stream o
Hi,
I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there
might be a bug in the r8169 driver in >4GB RAM configurations.
Initially I can use one of two active r8169 NICs on the motherboard with this
quantity of RAM with other devices, without issue. But after some
Hi,
I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there
might be a bug in the r8169 driver in 4GB RAM configurations.
Initially I can use one of two active r8169 NICs on the motherboard with this
quantity of RAM with other devices, without issue. But after some
On Sunday 25 November 2007 00:25:10 Francois Romieu wrote:
Alistair John Strachan [EMAIL PROTECTED] :
[...]
The choke affects other devices on the system too, notably libata,
which does not recover gracefully. In my logs, I see a stream of:
DMA: Out of SW-IOMMU space for 7222 bytes
On Sunday 25 November 2007 01:27:54 Francois Romieu wrote:
Francois Romieu [EMAIL PROTECTED] :
Alistair John Strachan [EMAIL PROTECTED] :
[...]
The choke affects other devices on the system too, notably libata,
which does not recover gracefully. In my logs, I see a stream
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
> diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
> index 9e64b21..99403a6 100644
> --- a/drivers/scsi/NCR_D700.c
> +++ b/drivers/scsi/NCR_D700.c
> @@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
> siop,
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
index 9e64b21..99403a6 100644
--- a/drivers/scsi/NCR_D700.c
+++ b/drivers/scsi/NCR_D700.c
@@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
siop, int
On Thursday 01 November 2007 11:51:08 Sebastian Siewior wrote:
> * Jens Axboe | 2007-11-01 11:51:09 [+0100]:
> >On Wed, Oct 31 2007, Alistair John Strachan wrote:
> >> Hi Jens,
> >>
> >> I guessed from the oops that you might have an idea what's causing this
&g
On Thursday 01 November 2007 11:51:08 Sebastian Siewior wrote:
* Jens Axboe | 2007-11-01 11:51:09 [+0100]:
On Wed, Oct 31 2007, Alistair John Strachan wrote:
Hi Jens,
I guessed from the oops that you might have an idea what's causing this
oops on shutdown/unmount. The git version
Hi Jens,
I guessed from the oops that you might have an idea what's causing this oops
on shutdown/unmount. The git version (describe), a screenshot showing the
oops, a config, and dmesg for a booted kernel are available from:
http://devzero.co.uk/~alistair/oops-20071031/
I went back to -rc1
Hi Jens,
I guessed from the oops that you might have an idea what's causing this oops
on shutdown/unmount. The git version (describe), a screenshot showing the
oops, a config, and dmesg for a booted kernel are available from:
http://devzero.co.uk/~alistair/oops-20071031/
I went back to -rc1
On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote:
> Hello,
>
> I posted this question at comp.linux.misc and where told this would be a
> better place therefore. I would like to do a internship in the field of the
> Linux kernel.
> Can someone tell me where to find a list of companies
On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote:
Hello,
I posted this question at comp.linux.misc and where told this would be a
better place therefore. I would like to do a internship in the field of the
Linux kernel.
Can someone tell me where to find a list of companies (don't
On Friday 05 October 2007 09:32:40 you wrote:
> On Fri, 5 Oct 2007, Sam Ravnborg wrote:
> > > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> > > >
> > > > Obviously, this file has moved to arch/x86/boot, but it seems like
> > > > possibly unnecessary breakage. I've been
On Monday 08 October 2007 00:10:10 Rene Herman wrote:
> I find Alan's suggestion to provide the functionality the same way you'd
> provide for translated kernel messages (seeing as how there also are people
> that want those) much more sensible.
By the way, I agree that this is the best approach.
On Monday 08 October 2007 00:10:10 Rene Herman wrote:
> On 10/08/2007 12:40 AM, Alistair John Strachan wrote:
> > Splash screens are clearly cosmetic, and it's kind of shameful (imo) that
> > important messages explaining real problems are obscured from view by
> > functi
On Sunday 07 October 2007 20:13:09 you wrote:
> On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
> > On 10/07/2007 06:12 PM, Ingo Molnar wrote:
> > >* Oleg Verych <[EMAIL PROTECTED]> wrote:
> > >>Coloring isn't useful. If it was, it would be implemented ~16 years
> > >>ago.
> > >
> >
On Sunday 07 October 2007 20:13:09 you wrote:
On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
On 10/07/2007 06:12 PM, Ingo Molnar wrote:
* Oleg Verych [EMAIL PROTECTED] wrote:
Coloring isn't useful. If it was, it would be implemented ~16 years
ago.
Congratulations, this
On Monday 08 October 2007 00:10:10 Rene Herman wrote:
On 10/08/2007 12:40 AM, Alistair John Strachan wrote:
Splash screens are clearly cosmetic, and it's kind of shameful (imo) that
important messages explaining real problems are obscured from view by
functionless splash screens.
They're
On Monday 08 October 2007 00:10:10 Rene Herman wrote:
I find Alan's suggestion to provide the functionality the same way you'd
provide for translated kernel messages (seeing as how there also are people
that want those) much more sensible.
By the way, I agree that this is the best approach.
On Friday 05 October 2007 09:32:40 you wrote:
On Fri, 5 Oct 2007, Sam Ravnborg wrote:
cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
Obviously, this file has moved to arch/x86/boot, but it seems like
possibly unnecessary breakage. I've been copying bzImage
On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
[snip]
> In other words, people who know they may be affected and would want to
> prepare can look at (for example)
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
> and generally get ready for the
On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
[snip]
In other words, people who know they may be affected and would want to
prepare can look at (for example)
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
and generally get ready for the
On Monday 24 September 2007 17:56:39 Antoine Martin wrote:
> Hi Ted / LKML,
>
> I've got this snapshot of an ext3 filesystem with a directory that
> simply cannot be removed! (image below is just 1.2MB)
> As root:
> # wget http://users.nagafix.co.uk/~antoine/root-broken.bz2
> # bunzip2
On Monday 24 September 2007 17:56:39 Antoine Martin wrote:
Hi Ted / LKML,
I've got this snapshot of an ext3 filesystem with a directory that
simply cannot be removed! (image below is just 1.2MB)
As root:
# wget http://users.nagafix.co.uk/~antoine/root-broken.bz2
# bunzip2 root-broken.bz2
#
On Monday 10 September 2007 14:08:45 Laurent Vivier wrote:
> Avi Kivity wrote:
> > Ingo Molnar wrote:
> >> * Laurent Vivier <[EMAIL PROTECTED]> wrote:
> >>> Ingo, please, could you have a look to these patches ?
> >>>
> >>> The aim of these four patches is to introduce Virtual Machine time
> >>>
On Monday 10 September 2007 14:08:45 Laurent Vivier wrote:
Avi Kivity wrote:
Ingo Molnar wrote:
* Laurent Vivier [EMAIL PROTECTED] wrote:
Ingo, please, could you have a look to these patches ?
The aim of these four patches is to introduce Virtual Machine time
accounting.
[PATCH
On Tuesday 04 September 2007 16:26:27 Andi Kleen wrote:
> > Seconded. It's been largely ignored which is annoying because the HPET
> > works perfectly on this board. I assume the reason is still that nobody
> > from NVIDIA verified hardward support for the hack.
>
> It's IMHO a bad idea to add any
On Monday 03 September 2007 09:06:25 Nicolas Mailhot wrote:
> Mats Johannesson bredband.net> writes:
> > On 2007-09-01 16:07:48 Torsten Kaiser wrote:
> > [...]
> >
> > > The good:
> > >> +hpet-force-enable-on-vt8235-37-chipsets.patch
> > >> +hpet-force-enable-on-vt8235-37-chipsets-fix.patch
> > >
On Tuesday 04 September 2007 15:18:23 Abhijit Bhopatkar wrote:
[snip]
> > Anyway, it'd be helpful if someone else can check the same MacBook
> > (1st generation, not Pro?) whether the problem is reproducible.
>
> To be precise its Macbook 1st Generation non pro. with subsystem id
> 0x106b0a00
>
>
On Tuesday 04 September 2007 15:18:23 Abhijit Bhopatkar wrote:
[snip]
Anyway, it'd be helpful if someone else can check the same MacBook
(1st generation, not Pro?) whether the problem is reproducible.
To be precise its Macbook 1st Generation non pro. with subsystem id
0x106b0a00
Well a
On Monday 03 September 2007 09:06:25 Nicolas Mailhot wrote:
Mats Johannesson spamcan at bredband.net writes:
On 2007-09-01 16:07:48 Torsten Kaiser wrote:
[...]
The good:
+hpet-force-enable-on-vt8235-37-chipsets.patch
+hpet-force-enable-on-vt8235-37-chipsets-fix.patch
Kernel
On Tuesday 04 September 2007 16:26:27 Andi Kleen wrote:
Seconded. It's been largely ignored which is annoying because the HPET
works perfectly on this board. I assume the reason is still that nobody
from NVIDIA verified hardward support for the hack.
It's IMHO a bad idea to add any
On Sunday 02 September 2007 21:23:16 Jesper Juhl wrote:
> On 02/09/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > Hi Jesper,
> >
> > On Sun, 2 Sep 2007, Jesper Juhl wrote:
> > > > - if (!(interface = usb_find_interface(_driver,
> > > > subminor))) { -
On Sunday 02 September 2007 21:23:16 Jesper Juhl wrote:
On 02/09/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Jesper,
On Sun, 2 Sep 2007, Jesper Juhl wrote:
- if (!(interface = usb_find_interface(sisusb_driver,
subminor))) { - dev_err(sisusb-sisusb_dev-dev,
On Monday 27 August 2007 10:28:09 Dermot Bradley wrote:
[snip]
> Thanks for the help Alistair! One other point you may be able to help
> with - this is the first time I've used a dual core processor and I
> expected that /proc/interrupts would should interrupts distributed
> between both cores
On Monday 27 August 2007 10:28:09 Dermot Bradley wrote:
[snip]
Thanks for the help Alistair! One other point you may be able to help
with - this is the first time I've used a dual core processor and I
expected that /proc/interrupts would should interrupts distributed
between both cores whereas
On Friday 24 August 2007 20:20:02 Alan Cox wrote:
> On Fri, 24 Aug 2007 14:39:10 +0100
>
> "Dermot Bradley" <[EMAIL PROTECTED]> wrote:
> > I've just built a new machine using a ASUS M2A-VM boardboard (ATI SB600
> > chipset), AMD X2 3800+ processor, and 2 Western Digital 2.5" 80Gb drives
> >
On Friday 24 August 2007 20:20:02 Alan Cox wrote:
On Fri, 24 Aug 2007 14:39:10 +0100
Dermot Bradley [EMAIL PROTECTED] wrote:
I've just built a new machine using a ASUS M2A-VM boardboard (ATI SB600
chipset), AMD X2 3800+ processor, and 2 Western Digital 2.5 80Gb drives
running in RAID-1
On Sunday 12 August 2007 21:06:43 Vadim Dyadkin wrote:
> Robert Hancock пишет:
> > This could well be a problem with the nvidia driver as it shares the
> > same IRQ. The first step would be to see if the problem still shows up
> > without the nvidia binary module loaded.
>
> Thank for your answer.
On Sunday 12 August 2007 21:06:43 Vadim Dyadkin wrote:
Robert Hancock пишет:
This could well be a problem with the nvidia driver as it shares the
same IRQ. The first step would be to see if the problem still shows up
without the nvidia binary module loaded.
Thank for your answer. This
On Saturday 11 August 2007 17:58:43 Gene Heskett wrote:
> Greetings;
>
> Running 23-rc2 since it came out, I've just discovered I have only the
> system beep for sound. From lspci:
> 01:08.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
> Subsystem: Creative Labs Unknown
On Saturday 11 August 2007 17:58:43 Gene Heskett wrote:
Greetings;
Running 23-rc2 since it came out, I've just discovered I have only the
system beep for sound. From lspci:
01:08.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
Subsystem: Creative Labs Unknown device
On Saturday 04 August 2007 14:17:34 Prakash Punnoor wrote:
> Unfortunately this doesn't seem to have made it into 2.6.23-rc2. I need it
> as well, to make Windows XP boot up w/o hanging or reebooting my host
> machine.
It isn't in 2.6.23-rc2. I guess Avi should re-send to Linus and hopefully
On Saturday 04 August 2007 14:17:34 Prakash Punnoor wrote:
Unfortunately this doesn't seem to have made it into 2.6.23-rc2. I need it
as well, to make Windows XP boot up w/o hanging or reebooting my host
machine.
It isn't in 2.6.23-rc2. I guess Avi should re-send to Linus and hopefully
it'll
On Friday 03 August 2007 15:51:59 T. J. Brumfield wrote:
> > I'm not going to argue with this point because I think this is exactly
> > what Linus meant. He wanted a scheduler that worked. And he knew it
> > wouldn't work immediately after merging it. So he had to go with the
> > person that he
On Friday 03 August 2007 14:27:30 Андрій Мішковський wrote:
> Bad things may happen if Linus gives a right of making decision to
> other people (a big group of people). ;)
> As you said, Linux is a public OS, so Con's code never will be lost.
> That's the base of open source - people come and go,
The real question is WHY do people keep writing essays about topics that have
_already_ been exhaustively explored in other threads? If you want a better
understanding of the situation, read the archives, DON'T post another
duplicate message about the same scheduler parade.
Unless you've got
The real question is WHY do people keep writing essays about topics that have
_already_ been exhaustively explored in other threads? If you want a better
understanding of the situation, read the archives, DON'T post another
duplicate message about the same scheduler parade.
Unless you've got
On Friday 03 August 2007 15:51:59 T. J. Brumfield wrote:
I'm not going to argue with this point because I think this is exactly
what Linus meant. He wanted a scheduler that worked. And he knew it
wouldn't work immediately after merging it. So he had to go with the
person that he trusted
On Friday 03 August 2007 14:27:30 Андрій Мішковський wrote:
Bad things may happen if Linus gives a right of making decision to
other people (a big group of people). ;)
As you said, Linux is a public OS, so Con's code never will be lost.
That's the base of open source - people come and go, but
On Monday 30 July 2007 14:00:13 Avi Kivity wrote:
> How about the attached patch? (I haven't yet tried to reproduce, but
> this can cause an AMD-only oops).
This seems to have fixed the problem. Thanks Avi.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from
On Monday 30 July 2007 14:00:13 Avi Kivity wrote:
How about the attached patch? (I haven't yet tried to reproduce, but
this can cause an AMD-only oops).
This seems to have fixed the problem. Thanks Avi.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from
On Sunday 29 July 2007 15:57:33 Gene Heskett wrote:
> Is this a known problem? Do I need to report it to nvidia somehow? It
> looks to me like it may be their problem, and I have submitted it, but if
> anyone has a better idea, please advise. System is FC6, uptodate as of
> yesterday.
Gene,
On Sunday 29 July 2007 14:47:57 you wrote:
> Alistair John Strachan wrote:
> > On Sunday 29 July 2007 12:34:28 you wrote:
> > [snip]
> >
> >>> Doesn't help, I still get the same crashes. I tried 2.6.22 again and
> >>> it's rock solid by comparison.
&
On Sunday 29 July 2007 12:34:28 you wrote:
[snip]
> > Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's
> > rock solid by comparison.
>
> Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22?
> Please describe your configuration *exactly*.
I'm using the
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote:
> Alistair John Strachan wrote:
> > Hi,
> >
> > I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a
> > digital photo of the oops. Alarmingly, a lot of the time it triple faults
> > the machine
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote:
Alistair John Strachan wrote:
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a
digital photo of the oops. Alarmingly, a lot of the time it triple faults
the machine and I don't get a chance to grab it. This time I
On Sunday 29 July 2007 12:34:28 you wrote:
[snip]
Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's
rock solid by comparison.
Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22?
Please describe your configuration *exactly*.
I'm using the kvm-33
On Sunday 29 July 2007 14:47:57 you wrote:
Alistair John Strachan wrote:
On Sunday 29 July 2007 12:34:28 you wrote:
[snip]
Doesn't help, I still get the same crashes. I tried 2.6.22 again and
it's rock solid by comparison.
Do you mean, kvm-33 on top of 2.6.22, or the kvm modules
On Sunday 29 July 2007 15:57:33 Gene Heskett wrote:
Is this a known problem? Do I need to report it to nvidia somehow? It
looks to me like it may be their problem, and I have submitted it, but if
anyone has a better idea, please advise. System is FC6, uptodate as of
yesterday.
Gene, this
> I have absolutely no idea what triggers this crash.
Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I
wonder if this is due to the RAM failing at the point where the framebuffer
is mapped?
Try running memtest86 on it.
--
Cheers,
Alistair.
137/1 Warrender Park
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg
Unfortunately,
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg
Unfortunately,
I have absolutely no idea what triggers this crash.
Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I
wonder if this is due to the RAM failing at the point where the framebuffer
is mapped?
Try running memtest86 on it.
--
Cheers,
Alistair.
137/1 Warrender Park
On Sunday 22 July 2007 22:04:24 Linus Torvalds wrote:
> So give it all a good whacking, and report back about all the neat new
> features!
I'm fairly sure this is already known about on SPARC64 (see David Miller's
email ""build-id" changes break sparc64"), but I just thought I'd let people
know
On Sunday 22 July 2007 22:04:24 Linus Torvalds wrote:
So give it all a good whacking, and report back about all the neat new
features!
I'm fairly sure this is already known about on SPARC64 (see David Miller's
email build-id changes break sparc64), but I just thought I'd let people
know the
On Wednesday 11 July 2007 16:21:44 Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 07:06:23PM +0530, Satyam Sharma wrote:
> > Which leaves Gmail, but Gmail has the flowed text disease (that
> > cannot be disabled) and although Gmail offers SMTP/POP, our evil
> > proxy/NAT setup here wouldn't
On Thursday 12 July 2007 19:16:20 Maciej W. Rozycki wrote:
> On Thu, 12 Jul 2007, Andy Whitcroft wrote:
[snip]
> > WARNING: declaring multiple variables together should be avoided
> > #372: FILE: drivers/serial/sb1250-duart.c:246:
> > + unsigned int mctrl, status;
>
> Well, this is probably
On Thursday 12 July 2007 19:16:20 Maciej W. Rozycki wrote:
On Thu, 12 Jul 2007, Andy Whitcroft wrote:
[snip]
WARNING: declaring multiple variables together should be avoided
#372: FILE: drivers/serial/sb1250-duart.c:246:
+ unsigned int mctrl, status;
Well, this is probably superfluous
On Wednesday 11 July 2007 16:21:44 Christoph Hellwig wrote:
On Wed, Jul 11, 2007 at 07:06:23PM +0530, Satyam Sharma wrote:
Which leaves Gmail, but Gmail has the flowed text disease (that
cannot be disabled) and although Gmail offers SMTP/POP, our evil
proxy/NAT setup here wouldn't let me
(Sorry, accidentally dropped LKML)
On Sunday 24 June 2007 01:52:30 you wrote:
> Googling around lkml.org, I found a few threads investigating what look
> like very similar problems, some of which never seemed to find the
> solution, but one of which came up with a fairly quick answer it seemed,
>
(Sorry, accidentally dropped LKML)
On Sunday 24 June 2007 01:52:30 you wrote:
Googling around lkml.org, I found a few threads investigating what look
like very similar problems, some of which never seemed to find the
solution, but one of which came up with a fairly quick answer it seemed,
On Saturday 16 June 2007 11:36:00 Thomas Gleixner wrote:
> The -hrt tree at http://www.tglx.de/projects/hrtimers/2.6.22-rc4/ contains
> also an hpet force patch series from Venki Pallipadi, but I leave this up
> to Venki to send it mainline wards.
What's the status on the nForce "hpet force fix"
On Saturday 16 June 2007 11:36:00 Thomas Gleixner wrote:
The -hrt tree at http://www.tglx.de/projects/hrtimers/2.6.22-rc4/ contains
also an hpet force patch series from Venki Pallipadi, but I leave this up
to Venki to send it mainline wards.
What's the status on the nForce hpet force fix
On Sunday 10 June 2007 13:03:15 you wrote:
> 訳注(2)
> 「引火性の高い」の原文は "valatile"。
> valatile には「揮発性の」「爆発しやすい」という意味の他、「変わり
> やすい」「移り気な」という意味がある。
> 「（この話題は）爆発的に激しい論争を巻き起こしかねない」ということ
> を、「（カーネルのソースレベルインターフェースは）移ろい行くもので
> ある」ということを連想させる "valatile" という単語で表現している。
Not speaking Japanese, I'm probably missing
On Sunday 10 June 2007 13:03:15 you wrote:
訳注(2)
「引火性の高い」の原文は valatile。
valatile には「揮発性の」「爆発しやすい」という意味の他、「変わり
やすい」「移り気な」という意味がある。
「（この話題は）爆発的に激しい論争を巻き起こしかねない」ということ
を、「（カーネルのソースレベルインターフェースは）移ろい行くもので
ある」ということを連想させる valatile という単語で表現している。
Not speaking Japanese, I'm probably missing some
On Thursday 07 June 2007 22:17:18 Krzysztof Halasa wrote:
> Alan Cox <[EMAIL PROTECTED]> writes:
> > The intel-rng printed a nice well formatted message when the port was
> > disabled. Someone then came along and blindly trashed it by screwing up a
> > trim down to 80 columns.
>
> Perhaps we
On Thursday 07 June 2007 22:17:18 Krzysztof Halasa wrote:
Alan Cox [EMAIL PROTECTED] writes:
The intel-rng printed a nice well formatted message when the port was
disabled. Someone then came along and blindly trashed it by screwing up a
trim down to 80 columns.
Perhaps we should drop that
On Tuesday 22 May 2007 23:09:39 Richard Griffiths wrote:
> Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> the embedded Linux community for years, updated for 2.6.21. Tested on
> several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
> Freescale iMX31ADS.
On Tuesday 22 May 2007 23:09:39 Richard Griffiths wrote:
Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
the embedded Linux community for years, updated for 2.6.21. Tested on
several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
Freescale iMX31ADS.
On Tuesday 15 May 2007 09:18:02 Thomas Gleixner wrote:
> I've uploaded a new version of the x86_64 highres/dyntick patches:
>
> http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig
>hres-v4.patch
>
> Broken out version:
>
>
On Tuesday 15 May 2007 09:18:02 Thomas Gleixner wrote:
I've uploaded a new version of the x86_64 highres/dyntick patches:
http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig
hres-v4.patch
Broken out version:
On Monday 14 May 2007 23:05:14 Thomas Gleixner wrote:
> On Mon, 2007-05-14 at 22:15 +0100, Alistair John Strachan wrote:
> > On Monday 14 May 2007 11:26:08 Thomas Gleixner wrote:
> > > I'm pleased to announce an updated version of the x86_64
> > > highres/dyntick support
On Monday 14 May 2007 11:26:08 Thomas Gleixner wrote:
> I'm pleased to announce an updated version of the x86_64 highres/dyntick
> support patches against 2.6.22-rc1:
[snip]
> - Various fixups from Chris Wright
> - TSC calibration fix (pointed out by Alistair John Strachan)
On Monday 14 May 2007 21:22:50 Jan Engelhardt wrote:
> On May 12 2007 22:12, Alistair John Strachan wrote:
> >On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
> >> What's eating the battery life of my laptop? Why isn't it many more
> >> hours? Which software comp
On Monday 14 May 2007 06:50:39 Oliver Neukum wrote:
> Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan:
> > > What did you use instead of hci_usb then ? usbkbd ? This won't give you
> > > the special keys etc...
> >
> > Sorry, I wasn't clear. hci_usb is
On Monday 14 May 2007 06:50:39 Oliver Neukum wrote:
Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan:
What did you use instead of hci_usb then ? usbkbd ? This won't give you
the special keys etc...
Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's
1 - 100 of 417 matches
Mail list logo
