* HT apparently not detected properly on 2.4.23
@ 2003-12-03 18:46 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
2003-12-03 22:40 ` William Lee Irwin III
0 siblings, 2 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 18:46 UTC (permalink / raw)
To: linux-kernel
Hi,
With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
/proc/cpuinfo|proc/interrupts, with:
CONFIG_ACPI=y
CONFIG_ACPI_HT_ONLY=y
The same config with 2.4.23 only shows 2 cpus, even with:
CONFIG_NR_CPUS=4
Also, I believe this has been reported before, but the system only seems
to interrupt on CPU0 with either kernel, unless I apply a patch I found
here:
http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
or run the `irqbalance' program.. which I don't care to do. This
problem _seems_ to be isolated to the Supermicro, as HT does seem
properly detected on several other SMP systems I have at work (compaq
ML370/ML380) with 2.4.23
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
@ 2003-12-03 19:40 ` Andre Tomt
2003-12-03 19:56 ` Mike Fedyk
2003-12-03 22:40 ` William Lee Irwin III
1 sibling, 1 reply; 16+ messages in thread
From: Andre Tomt @ 2003-12-03 19:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Ethan Weinstein
On Wed, 2003-12-03 at 19:46, Ethan Weinstein wrote:
> Hi,
>
> With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> /proc/cpuinfo|proc/interrupts, with:
> CONFIG_ACPI=y
> CONFIG_ACPI_HT_ONLY=y
> The same config with 2.4.23 only shows 2 cpus, even with:
> CONFIG_NR_CPUS=4
This may be the known problem about CONFIG_NR_CPU's not working properly
in all cases. Try up'ing it to 32.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 19:40 ` Andre Tomt
@ 2003-12-03 19:56 ` Mike Fedyk
2003-12-03 20:30 ` Ethan Weinstein
0 siblings, 1 reply; 16+ messages in thread
From: Mike Fedyk @ 2003-12-03 19:56 UTC (permalink / raw)
To: Andre Tomt; +Cc: linux-kernel, Ethan Weinstein
On Wed, Dec 03, 2003 at 08:40:51PM +0100, Andre Tomt wrote:
> On Wed, 2003-12-03 at 19:46, Ethan Weinstein wrote:
> > Hi,
> >
> > With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> > xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> > /proc/cpuinfo|proc/interrupts, with:
> > CONFIG_ACPI=y
> > CONFIG_ACPI_HT_ONLY=y
> > The same config with 2.4.23 only shows 2 cpus, even with:
> > CONFIG_NR_CPUS=4
>
> This may be the known problem about CONFIG_NR_CPU's not working properly
> in all cases. Try up'ing it to 32.
Depending on the logical addressing of your processors, CONFIG_NR_CPUS=8 may
work in this case too.
Some processors/motherboards logically address the CPUs other that 0-3 if
there are 4 processors.
Currently CONFIG_NR_CPUS needs to be big enough to hold the largest logical
processor number.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 19:56 ` Mike Fedyk
@ 2003-12-03 20:30 ` Ethan Weinstein
0 siblings, 0 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 20:30 UTC (permalink / raw)
To: linux-kernel
Mike Fedyk wrote:
> Depending on the logical addressing of your processors, CONFIG_NR_CPUS=8 may
> work in this case too.
>
> Some processors/motherboards logically address the CPUs other that 0-3 if
> there are 4 processors.
>
> Currently CONFIG_NR_CPUS needs to be big enough to hold the largest logical
> processor number.
Thanks. This rings a bell, I seem to remember what I thought to be
"impossible numbering" on the CPUs such as "CPU7" or somesuch in a
dmesg.. Will have to look through logs. I'll raise CONFIG_NR_CPUS and
see what I get. Now, the question is, why do we only interrupt on CPU0
on this pasrticular box|chipset with a vanilla kernel? ACPI problem? My
SMP G4 ppc has an option in menuconfig: "distribute interrupts on all
CPUs by default", the x86 has no such option.
Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
@ 2003-12-03 22:40 ` William Lee Irwin III
2003-12-03 23:41 ` Ethan Weinstein
1 sibling, 1 reply; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-03 22:40 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
On Wed, Dec 03, 2003 at 01:46:38PM -0500, Ethan Weinstein wrote:
> With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> /proc/cpuinfo|proc/interrupts, with:
> CONFIG_ACPI=y
> CONFIG_ACPI_HT_ONLY=y
> The same config with 2.4.23 only shows 2 cpus, even with:
> CONFIG_NR_CPUS=4
> Also, I believe this has been reported before, but the system only seems
> to interrupt on CPU0 with either kernel, unless I apply a patch I found
> here:
> http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
> or run the `irqbalance' program.. which I don't care to do. This
> problem _seems_ to be isolated to the Supermicro, as HT does seem
> properly detected on several other SMP systems I have at work (compaq
> ML370/ML380) with 2.4.23
You probably have sparse physical APIC ID's.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 22:40 ` William Lee Irwin III
@ 2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:46 ` William Lee Irwin III
0 siblings, 2 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 23:41 UTC (permalink / raw)
To: linux-kernel; +Cc: William Lee Irwin III
William Lee Irwin III wrote:
> On Wed, Dec 03, 2003 at 01:46:38PM -0500, Ethan Weinstein wrote:
>
>>With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
>>xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
>>/proc/cpuinfo|proc/interrupts, with:
>>CONFIG_ACPI=y
>>CONFIG_ACPI_HT_ONLY=y
>>The same config with 2.4.23 only shows 2 cpus, even with:
>>CONFIG_NR_CPUS=4
>>Also, I believe this has been reported before, but the system only seems
>>to interrupt on CPU0 with either kernel, unless I apply a patch I found
>>here:
>>http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
>>or run the `irqbalance' program.. which I don't care to do. This
>>problem _seems_ to be isolated to the Supermicro, as HT does seem
>>properly detected on several other SMP systems I have at work (compaq
>>ML370/ML380) with 2.4.23
>
> You probably have sparse physical APIC ID's.
>
Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
it was the numbering scheme:
Dec 3 18:32:28 spicymeatball kernel: CPU 0 (0x0000) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #0 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0001] id[0x6]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 1 (0x0600) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #6 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0002] id[0x1]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 2 (0x0100) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #1 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0003] id[0x7]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 3 (0x0700) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #7 Pentium 4(tm)
XEON(tm) APIC version 16
But we're still only interrupting on CPU0 with this kernel.
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:41 ` Ethan Weinstein
@ 2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
2003-12-04 0:46 ` William Lee Irwin III
1 sibling, 2 replies; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-03 23:58 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
William Lee Irwin III wrote:
>>You probably have sparse physical APIC ID's.
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> it was the numbering scheme:
It's easy to fix this; just terminate the loop when the count of cpus
kicked hits NR_CPUS or the bit would overflow the map instead of the bit
hitting NR_CPUS. Compare smpboot.c in 2.4 vs. 2.6. No need for the extra
CONFIG_NR_CPUS bloat.
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> But we're still only interrupting on CPU0 with this kernel.
That's P-IV retardation. Not really fixable, but irqbalance daemons
etc. can help mitigate the severity of the erratum. I'm not sure if
2.4 has the interfaces for the userspace solutions to work or the
kernel solutions either.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:58 ` William Lee Irwin III
@ 2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
1 sibling, 0 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-04 0:18 UTC (permalink / raw)
To: linux-kernel; +Cc: William Lee Irwin III
William Lee Irwin III wrote:
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
>
>>But we're still only interrupting on CPU0 with this kernel.
>
>
> That's P-IV retardation. Not really fixable, but irqbalance daemons
> etc. can help mitigate the severity of the erratum. I'm not sure if
> 2.4 has the interfaces for the userspace solutions to work or the
> kernel solutions either.
>
I somehow suspected that, and appreciate the clarification. I'll see if
I can't get that patch I found to apply to 2.4.23, it seems to solve
this a bit more elegantly than the irqbalance program.
CPU0 CPU1 CPU2 CPU3
0: 67962 69066 68010 68954 IO-APIC-edge timer
1: 1 0 0 1 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
3: 10027 10944 9904 11063 IO-APIC-edge serial
8: 2 0 0 0 IO-APIC-edge rtc
16: 9 7 7 18 IO-APIC-level sym53c8xx
22: 6842 7336 7166 7429 IO-APIC-level eth0
48: 6429 6370 6202 6268 IO-APIC-level aic79xx
49: 1939 2018 2067 1949 IO-APIC-level aic79xx
54: 340 345 340 352 IO-APIC-level eth1
NMI: 0 0 0 0
LOC: 273824 273846 273844 273845
ERR: 0
MIS: 0
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
@ 2003-12-04 0:46 ` William Lee Irwin III
1 sibling, 0 replies; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-04 0:46 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> it was the numbering scheme:
Something like this might do the trick. NR_CPUS is already checked
indirectly via max_cpus.
-- wli
===== arch/i386/kernel/smpboot.c 1.17 vs edited =====
--- 1.17/arch/i386/kernel/smpboot.c Mon Nov 3 05:48:33 2003
+++ edited/arch/i386/kernel/smpboot.c Wed Dec 3 16:45:27 2003
@@ -1106,7 +1106,7 @@
*/
Dprintk("CPU present map: %lx\n", phys_cpu_present_map);
- for (bit = 0; bit < NR_CPUS; bit++) {
+ for (bit = 0; bit < BITS_PER_LONG; bit++) {
apicid = cpu_present_to_apicid(bit);
/* don't try to boot BAD_APICID */
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
@ 2003-12-05 17:12 ` Marcelo Tosatti
2003-12-05 17:48 ` William Lee Irwin III
1 sibling, 1 reply; 16+ messages in thread
From: Marcelo Tosatti @ 2003-12-05 17:12 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Ethan Weinstein, linux-kernel
On Wed, 3 Dec 2003, William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >>You probably have sparse physical APIC ID's.
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> > Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> > it was the numbering scheme:
>
> It's easy to fix this; just terminate the loop when the count of cpus
> kicked hits NR_CPUS or the bit would overflow the map instead of the bit
> hitting NR_CPUS. Compare smpboot.c in 2.4 vs. 2.6. No need for the extra
> CONFIG_NR_CPUS bloat.
>
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> > But we're still only interrupting on CPU0 with this kernel.
>
> That's P-IV retardation. Not really fixable, but irqbalance daemons
> etc. can help mitigate the severity of the erratum. I'm not sure if
> 2.4 has the interfaces for the userspace solutions to work or the
> kernel solutions either.
I think I will just remove CONFIG_NR_CPUS instead... it seems to bring
more trouble than advantages.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-05 17:12 ` Marcelo Tosatti
@ 2003-12-05 17:48 ` William Lee Irwin III
2003-12-05 18:07 ` Re[2]: " Russell "Elik" Rademacher
0 siblings, 1 reply; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-05 17:48 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Ethan Weinstein, linux-kernel
On Fri, Dec 05, 2003 at 03:12:14PM -0200, Marcelo Tosatti wrote:
> I think I will just remove CONFIG_NR_CPUS instead... it seems to bring
> more trouble than advantages.
I've gotten a success report from this patch (forwarded separately),
but that's okay.
To handle sparse physical APIC ID's within 2.4 limitations without
this patch, NR_CPUS == BITS_PER_LONG whenever CONFIG_SMP=y is an
effective requirement.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: HT apparently not detected properly on 2.4.23
2003-12-05 17:48 ` William Lee Irwin III
@ 2003-12-05 18:07 ` Russell "Elik" Rademacher
[not found] ` <3FD0CD65.5080307@stinkfoot.org>
0 siblings, 1 reply; 16+ messages in thread
From: Russell "Elik" Rademacher @ 2003-12-05 18:07 UTC (permalink / raw)
To: linux-kernel
Hmmmm.....
SO someone finally realized that HT is not being detected properly dispite all the boot time parameters in the lilo/grub with APIC turned on? It just seems to be a major problem since 2.4.21 version and I was hoping it was resolved. :)
This patch you mentioned, can you send a copy to me as well? Just want to get my clients off my back. :)
--
Best regards,
Russell "Elik" Rademacher
Freelance Remote System Adminstrator/Tech Support
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: HT apparently not detected properly on 2.4.23
[not found] ` <3FD0CD65.5080307@stinkfoot.org>
@ 2003-12-05 23:02 ` Russell "Elik" Rademacher
2003-12-05 23:28 ` Ethan Weinstein
0 siblings, 1 reply; 16+ messages in thread
From: Russell "Elik" Rademacher @ 2003-12-05 23:02 UTC (permalink / raw)
To: linux-kernel
Hello Ethan,
Seems that patch of yours finally did the job of reporting it right this time around. I had to gank a few servers of different versions and giving the webhosting customers some little inconvience of downtime of 3 to 10 minutes for the linux recompile and reboot. And they all finally reports the number of processors correctly as it should be.
Thanks Ethan. I going to put it on more servers that got those and see how they all go as well. As for the servers, they are all usually ServerWorks, Intel Chipsets of various types with Intel E1000, E100, Realtek network ports and with 3Ware or SCSI Adaptec adapters. Got about 80 of them in various types to go though, but 5 of them I that tested it on, it all reports correctly.
Let see if the Dell servers also report the same as well when I get though with them tonight.
Friday, December 5, 2003, 11:24:37 AM, you wrote:
Ethan Weinstein> Russell "Elik" Rademacher wrote:
>> Hmmmm.....
>>
>> SO someone finally realized that HT is not being detected properly
>> dispite all the boot time parameters in the lilo/grub with APIC turned on?
>> It just seems to be a major problem since 2.4.21 version and I was hoping it
>> was resolved. :)
>>
>> This patch you mentioned, can you send a copy to me as well? Just
>> want to get my clients off my back. :)
>>
>>
Ethan Weinstein> heheh. Welcome to linux-kernel. Try running
Ethan Weinstein> an arch other than x86 if
Ethan Weinstein> you _really_ like having your problems ignored =)
Ethan Weinstein> ===== arch/i386/kernel/smpboot.c 1.17 vs edited =====
Ethan Weinstein> --- 1.17/arch/i386/kernel/smpboot.c Mon Nov 3 05:48:33 2003
Ethan Weinstein> +++ edited/arch/i386/kernel/smpboot.c Wed Dec 3 16:45:27 2003
Ethan Weinstein> @@ -1106,7 +1106,7 @@
Ethan Weinstein> */
Ethan Weinstein> Dprintk("CPU present map: %lx\n", phys_cpu_present_map);
Ethan Weinstein> - for (bit = 0; bit < NR_CPUS; bit++) {
Ethan Weinstein> + for (bit = 0; bit < BITS_PER_LONG; bit++) {
Ethan Weinstein> apicid = cpu_present_to_apicid(bit);
Ethan Weinstein> /* don't try to boot BAD_APICID */
--
Best regards,
Russell "Elik" Rademacher
Freelance Remote System Adminstrator/Tech Support
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-05 23:02 ` Russell "Elik" Rademacher
@ 2003-12-05 23:28 ` Ethan Weinstein
2003-12-05 23:31 ` Re[2]: " Russell "Elik" Rademacher
0 siblings, 1 reply; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-05 23:28 UTC (permalink / raw)
To: Rusell "Elik" Rademacher; +Cc: linux-kernel
Russell "Elik" Rademacher wrote:
> Hello Ethan,
>
> Seems that patch of yours finally did the job of reporting it right this time around. I had to gank a few servers of different versions and giving the webhosting customers some little inconvience of downtime of 3 to 10 minutes for the linux recompile and reboot. And they all finally reports the number of processors correctly as it should be.
>
> Thanks Ethan. I going to put it on more servers that got those and see how they all go as well. As for the servers, they are all usually ServerWorks, Intel Chipsets of various types with Intel E1000, E100, Realtek network ports and with 3Ware or SCSI Adaptec adapters. Got about 80 of them in various types to go though, but 5 of them I that tested it on, it all reports correctly.
>
> Let see if the Dell servers also report the same as well when I get though with them tonight.
>
Glad to help, but don't credit me with that patch, it was courtesy of
William Irwin.
-E
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: HT apparently not detected properly on 2.4.23
2003-12-05 23:28 ` Ethan Weinstein
@ 2003-12-05 23:31 ` Russell "Elik" Rademacher
2003-12-05 23:38 ` William Lee Irwin III
0 siblings, 1 reply; 16+ messages in thread
From: Russell "Elik" Rademacher @ 2003-12-05 23:31 UTC (permalink / raw)
To: linux-kernel
Hello Ethan,
So noted. Thanks William for this. Now I have to resume patching the rest of 284 servers from various clients this weekend and have it all brought up to speed.
Friday, December 5, 2003, 4:28:37 PM, you wrote:
Ethan Weinstein> Russell "Elik" Rademacher wrote:
>> Hello Ethan,
>>
>> Seems that patch of yours finally did the job of reporting it right
>> this time around. I had to gank a few servers of different versions and
>> giving the webhosting customers some little inconvience of downtime of 3 to
>> 10 minutes for the linux recompile and reboot. And they all finally reports
>> the number of processors correctly as it should be.
>>
>> Thanks Ethan. I going to put it on more servers that got those and
>> see how they all go as well. As for the servers, they are all usually
>> ServerWorks, Intel Chipsets of various types with Intel E1000, E100, Realtek
>> network ports and with 3Ware or SCSI Adaptec adapters. Got about 80 of them
>> in various types to go though, but 5 of them I that tested it on, it all
>> reports correctly.
>>
>> Let see if the Dell servers also report the same as well when I get though with them tonight.
>>
Ethan Weinstein> Glad to help, but don't credit me with that
Ethan Weinstein> patch, it was courtesy of
Ethan Weinstein> William Irwin.
Ethan Weinstein> -E
--
Best regards,
Russell "Elik" Rademacher
Freelance Remote System Adminstrator/Tech Support
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-05 23:31 ` Re[2]: " Russell "Elik" Rademacher
@ 2003-12-05 23:38 ` William Lee Irwin III
0 siblings, 0 replies; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-05 23:38 UTC (permalink / raw)
To: Russell Elik Rademacher; +Cc: linux-kernel
On Fri, Dec 05, 2003 at 04:31:29PM -0700, Russell Elik Rademacher wrote:
> So noted. Thanks William for this. Now I have to resume patching
> the rest of 284 servers from various clients this weekend and have it
> all brought up to speed.
Good to hear it's resolved the issue.
Thanks for testing.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-12-05 23:38 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
2003-12-03 19:56 ` Mike Fedyk
2003-12-03 20:30 ` Ethan Weinstein
2003-12-03 22:40 ` William Lee Irwin III
2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
2003-12-05 17:48 ` William Lee Irwin III
2003-12-05 18:07 ` Re[2]: " Russell "Elik" Rademacher
[not found] ` <3FD0CD65.5080307@stinkfoot.org>
2003-12-05 23:02 ` Russell "Elik" Rademacher
2003-12-05 23:28 ` Ethan Weinstein
2003-12-05 23:31 ` Re[2]: " Russell "Elik" Rademacher
2003-12-05 23:38 ` William Lee Irwin III
2003-12-04 0:46 ` William Lee Irwin III
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).