* [U-Boot-Users] Big ppcboot image
From: Wolfgang Denk @ 2002-12-13 15:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB4E9CE4@kuumex05.barco.com>
In message <81A66F72DCACD511B0600002A551BFCB4E9CE4@kuumex05.barco.com> you wrote:
>
> I am using ppcboot 2.0.0 and I placed the linux kernel in the ppcboot image
> ( included in an header file).
How did you do that? Did you simply concatenate the images (probably
with some gap for proper alignment of the second image)?
> 120 kBytes. And something goes wrong at the end of the board_init_f just
> before the realocation (realocate_code) or in it.
> PPCBoot give me the following message "PPCBoot size -292044 > reserved
> (786432)"
>
> Some tips on what is going wrong.
This probably means that you editied the linker script and use the
linker to integrate your image. Don't do that. Just concatenate the
binary images, or use a multifile image (for loading with PPCBoot).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
^ permalink raw reply
* Re: Symlink indirection
From: Marc-Christian Petersen @ 2002-12-13 15:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Walrond
In-Reply-To: <3DF9F780.1070300@walrond.org>
On Friday 13 December 2002 16:06, Andrew Walrond wrote:
Hi Andrew,
> Is the number of allowed levels of symlink indirection (if that is the
> right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
> kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c
if (current->link_count >= 5)
change to a higher value.
So, the answer is: Kernel :)
ciao, Marc
^ permalink raw reply
* [PATCH 2.5] cpufreq: clean up CPU information
From: Dominik Brodowski @ 2002-12-13 15:07 UTC (permalink / raw)
To: torvalds; +Cc: alan, linux-kernel, cpufreq, davej
[-- Attachment #1: Type: text/plain, Size: 17453 bytes --]
This patch moves some basic per-CPU static information (minimum frequency,
maximum frequency and maximum transition latency) into a struct
cpufreq_cpuinfo. This offers a much cleaner struct cpufreq_driver and
struct cpufreq_policy.
Dominik
diff -ruN linux-original/arch/arm/mach-integrator/cpu.c linux/arch/arm/mach-integrator/cpu.c
--- linux-original/arch/arm/mach-integrator/cpu.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/arm/mach-integrator/cpu.c 2002-12-13 15:44:26.000000000 +0100
@@ -77,8 +77,8 @@
{
struct vco vco;
- if (policy->max > policy->max_cpu_freq)
- policy->max = policy->max_cpu_freq;
+ if (policy->max > policy->cpuinfo.max_freq)
+ policy->max = policy->cpuinfo.max_freq;
if (policy->max < 12000)
policy->max = 12000;
@@ -148,7 +148,9 @@
static struct cpufreq_policy integrator_policy = {
.cpu = 0,
.policy = CPUFREQ_POLICY_POWERSAVE,
- .max_cpu_freq = 160000,
+ .cpuinfo.max_cpu_freq = 160000,
+ .cpuinfo.min_cpu_freq = 12000,
+ .cpuinfo.transition_latency = CPUFREQ_ETERNAL,
};
static struct cpufreq_driver integrator_driver = {
@@ -197,7 +199,9 @@
policies[cpu].cpu = cpu;
policies[cpu].policy = CPUFREQ_POLICY_POWERSAVE,
- policies[cpu].max_cpu_freq = 160000;
+ policies[cpu].cpuinfo.max_freq = 160000;
+ policies[cpu].cpuinfo.min_freq = 12000;
+ policies[cpu].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
policies[cpu].min =
policies[cpu].max = vco_to_freq(vco, 1);
}
@@ -205,8 +209,6 @@
set_cpus_allowed(current, cpus_allowed);
#ifdef CONFIG_CPU_FREQ
- for (cpu=0; cpu<NR_CPUS; cpu++)
- integrator_driver.cpu_min_freq[cpu] = 12000;
integrator_driver.policy = policies;
cpufreq_register(&integrator_driver);
#else
diff -ruN linux-original/arch/arm/mach-sa1100/cpu-sa1100.c linux/arch/arm/mach-sa1100/cpu-sa1100.c
--- linux-original/arch/arm/mach-sa1100/cpu-sa1100.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/arm/mach-sa1100/cpu-sa1100.c 2002-12-13 15:25:38.000000000 +0100
@@ -203,14 +203,15 @@
static struct cpufreq_policy sa1100_policy = {
.cpu = 0,
.policy = CPUFREQ_POLICY_POWERSAVE,
- .max_cpu_freq = 287000,
+ .cpuinfo.max_freq = 287000,
+ .cpuinfo.min_freq = 59000,
+ .cpuinfo.transition_latency = CPUFREQ_ETERNAL,
};
static struct cpufreq_driver sa1100_driver = {
.verify = sa11x0_verify_speed,
.setpolicy = sa1100_setspeed,
.policy = &sa1100_policy,
- .cpu_min_freq[0]= 59000,
};
static int __init sa1100_dram_init(void)
diff -ruN linux-original/arch/arm/mach-sa1100/cpu-sa1110.c linux/arch/arm/mach-sa1100/cpu-sa1110.c
--- linux-original/arch/arm/mach-sa1100/cpu-sa1110.c 2002-12-13 14:41:27.000000000 +0100
+++ linux/arch/arm/mach-sa1100/cpu-sa1110.c 2002-12-13 15:27:01.000000000 +0100
@@ -298,14 +298,15 @@
static struct cpufreq_policy sa1110_policy = {
.cpu = 0,
.policy = CPUFREQ_POLICY_POWERSAVE,
- .max_cpu_freq = 287000,
+ .cpuinfo.max_freq = 287000,
+ .cpuinfo.min_freq = 59000,
+ .cpuinfo.transition_latency = CPUFREQ_ETERNAL,
};
static struct cpufreq_driver sa1110_driver = {
.verify = sa11x0_verify_speed,
.setpolicy = sa1110_setspeed,
.policy = &sa1110_policy,
- .cpu_min_freq = { 59000, },
};
static int __init sa1110_clk_init(void)
diff -ruN linux-original/arch/arm/mach-sa1100/generic.c linux/arch/arm/mach-sa1100/generic.c
--- linux-original/arch/arm/mach-sa1100/generic.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/arm/mach-sa1100/generic.c 2002-12-13 15:22:36.000000000 +0100
@@ -69,8 +69,8 @@
*/
int sa11x0_verify_speed(struct cpufreq_policy *policy)
{
- if (policy->max > policy->max_cpu_freq)
- policy->max = policy->max_cpu_freq;
+ if (policy->max > policy->cpuinfo.max_freq)
+ policy->max = policy->cpuinfo.max_freq;
policy->max = cclk_frequency_100khz[sa11x0_freq_to_ppcr(policy->max)] * 100;
policy->min = policy->max;
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/elanfreq.c linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/elanfreq.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c 2002-12-13 15:01:35.000000000 +0100
@@ -296,7 +296,6 @@
max_freq = elanfreq_get_cpu_frequency();
#ifdef CONFIG_CPU_FREQ_24_API
- driver->cpu_min_freq[0] = 1000;
driver->cpu_cur_freq[0] = elanfreq_get_cpu_frequency();
#endif
@@ -307,7 +306,9 @@
driver->policy[0].min = 1000;
driver->policy[0].max = max_freq;
driver->policy[0].policy = CPUFREQ_POLICY_PERFORMANCE;
- driver->policy[0].max_cpu_freq = max_freq;
+ driver->policy[0].cpuinfo.max_freq = max_freq;
+ driver->policy[0].cpuinfo.min_freq = min_freq;
+ driver->policy[0].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
elanfreq_driver = driver;
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/longhaul.c linux/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/longhaul.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/longhaul.c 2002-12-13 15:03:20.000000000 +0100
@@ -779,7 +779,6 @@
driver->policy = (struct cpufreq_policy *) (driver + 1);
#ifdef CONFIG_CPU_FREQ_24_API
- driver->cpu_min_freq[0] = (unsigned int) lowest_speed;
driver->cpu_cur_freq[0] = currentspeed;
#endif
@@ -790,7 +789,9 @@
driver->policy[0].min = (unsigned int) lowest_speed;
driver->policy[0].max = (unsigned int) highest_speed;
driver->policy[0].policy = CPUFREQ_POLICY_PERFORMANCE;
- driver->policy[0].max_cpu_freq = (unsigned int) highest_speed;
+ driver->policy[0].cpuinfo.min_freq = (unsigned int) lowest_speed;
+ driver->policy[0].cpuinfo.max_freq = (unsigned int) highest_speed;
+ driver->policy[0].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
longhaul_driver = driver;
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/longrun.c linux/arch/i386/kernel/cpu/cpufreq/longrun.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/longrun.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/longrun.c 2002-12-13 15:06:32.000000000 +0100
@@ -121,8 +121,9 @@
return -EINVAL;
policy->cpu = 0;
- cpufreq_verify_within_limits(policy, 0,
- longrun_driver->policy[0].max_cpu_freq);
+ cpufreq_verify_within_limits(policy,
+ longrun_driver->policy[0].cpuinfo.min_freq,
+ longrun_driver->policy[0].cpuinfo.max_freq);
return 0;
}
@@ -247,12 +248,13 @@
kfree(driver);
return -EIO;
}
- driver->policy[0].max_cpu_freq = longrun_high_freq;
+ driver->policy[0].cpuinfo.min_freq = longrun_low_freq;
+ driver->policy[0].cpuinfo.max_freq = longrun_high_freq;
+ driver->policy[0].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
longrun_get_policy(&driver->policy[0]);
#ifdef CONFIG_CPU_FREQ_24_API
- driver->cpu_min_freq[0] = longrun_low_freq;
driver->cpu_cur_freq[0] = longrun_high_freq; /* dummy value */
#endif
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2002-12-13 15:04:26.000000000 +0100
@@ -257,7 +257,6 @@
#ifdef CONFIG_CPU_FREQ_24_API
for (i=0;i<NR_CPUS;i++) {
- driver->cpu_min_freq[i] = stock_freq / 8;
driver->cpu_cur_freq[i] = stock_freq;
}
#endif
@@ -272,7 +271,10 @@
driver->policy[i].min = stock_freq / 8;
driver->policy[i].max = stock_freq;
driver->policy[i].policy = CPUFREQ_POLICY_PERFORMANCE;
- driver->policy[i].max_cpu_freq = stock_freq;
+ driver->policy[i].cpuinfo.min_freq = driver->policy[i].min;
+ driver->policy[i].cpuinfo.max_freq = stock_freq;
+ driver->policy[i].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+
driver->policy[i].cpu = i;
}
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k6.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k6.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c 2002-12-13 15:04:49.000000000 +0100
@@ -242,7 +242,6 @@
driver->policy = (struct cpufreq_policy *) (driver + 1);
#ifdef CONFIG_CPU_FREQ_24_API
- driver->cpu_min_freq[0] = busfreq * 20;
driver->cpu_cur_freq[0] = busfreq * max_multiplier;
#endif
@@ -253,7 +252,9 @@
driver->policy[0].min = busfreq * 20;
driver->policy[0].max = busfreq * max_multiplier;
driver->policy[0].policy = CPUFREQ_POLICY_PERFORMANCE;
- driver->policy[0].max_cpu_freq = busfreq * max_multiplier;
+ driver->policy[0].cpuinfo.max_freq = busfreq * max_multiplier;
+ driver->policy[0].cpuinfo.min_freq = busfreq * 20;
+ driver->policy[0].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
powernow_driver = driver;
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c linux/arch/i386/kernel/cpu/cpufreq/speedstep.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c 2002-11-23 09:08:56.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep.c 2002-12-13 15:05:14.000000000 +0100
@@ -693,7 +693,6 @@
driver->policy = (struct cpufreq_policy *) (driver + 1);
#ifdef CONFIG_CPU_FREQ_24_API
- driver->cpu_min_freq[0] = speedstep_low_freq;
driver->cpu_cur_freq[0] = speed;
#endif
@@ -703,7 +702,10 @@
driver->policy[0].cpu = 0;
driver->policy[0].min = speedstep_low_freq;
driver->policy[0].max = speedstep_high_freq;
- driver->policy[0].max_cpu_freq = speedstep_high_freq;
+ driver->policy[0].cpuinfo.min_freq = speedstep_low_freq;
+ driver->policy[0].cpuinfo.max_freq = speedstep_high_freq;
+ driver->policy[0].cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+
driver->policy[0].policy = (speed == speedstep_low_freq) ?
CPUFREQ_POLICY_POWERSAVE : CPUFREQ_POLICY_PERFORMANCE;
diff -ruN linux-original/drivers/acpi/processor.c linux/drivers/acpi/processor.c
--- linux-original/drivers/acpi/processor.c 2002-12-13 14:41:28.000000000 +0100
+++ linux/drivers/acpi/processor.c 2002-12-13 15:11:27.000000000 +0100
@@ -1849,10 +1849,15 @@
#ifdef CONFIG_CPU_FREQ_24_API
for (i=0;i<NR_CPUS;i++) {
driver->cpu_cur_freq[0] = pr->performance.states[current_state].core_frequency * 1000;
- driver->cpu_min_freq[0] = pr->performance.states[pr->performance.state_count - 1].core_frequency * 1000;
}
#endif
+ /* detect highest transition latency */
+ for (i=0;i<pr->performance.state_count;i++) {
+ if (pr->performance.states[i].transition_latency > driver->policy[0].cpuinfo.transition_latency)
+ driver->policy[0].cpuinfo.transition_latency = pr->performance.states[i].transition_latency;
+ }
+
driver->verify = &acpi_cpufreq_verify;
driver->setpolicy = &acpi_cpufreq_setpolicy;
@@ -1860,7 +1865,9 @@
driver->policy[i].cpu = pr->id;
driver->policy[i].min = pr->performance.states[pr->performance.state_count - 1].core_frequency * 1000;
driver->policy[i].max = pr->performance.states[pr->limit.state.px].core_frequency * 1000;
- driver->policy[i].max_cpu_freq = pr->performance.states[0].core_frequency * 1000;
+ driver->policy[i].cpuinfo.max_freq = pr->performance.states[0].core_frequency * 1000;
+ driver->policy[i].cpuinfo.min_freq = pr->performance.states[pr->performance.state_count - 1].core_frequency * 1000;
+ driver->policy[i].cpuinfo.transition_latency = driver->policy[0].cpuinfo.transition_latency;
driver->policy[i].policy = ( pr->performance.states[current_state].core_frequency * 1000 == driver->policy[i].max) ?
CPUFREQ_POLICY_PERFORMANCE : CPUFREQ_POLICY_POWERSAVE;
}
diff -ruN linux-original/include/linux/cpufreq.h linux/include/linux/cpufreq.h
--- linux-original/include/linux/cpufreq.h 2002-11-23 09:09:03.000000000 +0100
+++ linux/include/linux/cpufreq.h 2002-12-13 14:50:53.000000000 +0100
@@ -37,15 +37,26 @@
#define CPUFREQ_POLICY_POWERSAVE (1)
#define CPUFREQ_POLICY_PERFORMANCE (2)
-/* values here are CPU kHz so that hardware which doesn't run with some
- * frequencies can complain without having to guess what per cent / per
- * mille means. */
+/* Frequency values here are CPU kHz so that hardware which doesn't run
+ * with some frequencies can complain without having to guess what per
+ * cent / per mille means.
+ * Maximum transition latency is in nanoseconds - if it's unknown,
+ * CPUFREQ_ETERNAL shall be used.
+ */
+
+#define CPUFREQ_ETERNAL (-1)
+struct cpufreq_cpuinfo {
+ unsigned int max_freq;
+ unsigned int min_freq;
+ unsigned int transition_latency;
+};
+
struct cpufreq_policy {
unsigned int cpu; /* cpu nr or CPUFREQ_ALL_CPUS */
unsigned int min; /* in kHz */
unsigned int max; /* in kHz */
unsigned int policy; /* see above */
- unsigned int max_cpu_freq; /* for information */
+ struct cpufreq_cpuinfo cpuinfo; /* see above */
};
#define CPUFREQ_ADJUST (0)
@@ -116,7 +127,6 @@
#endif
/* 2.4. compatible API */
#ifdef CONFIG_CPU_FREQ_24_API
- unsigned int cpu_min_freq[NR_CPUS];
unsigned int cpu_cur_freq[NR_CPUS];
#endif
};
diff -ruN linux-original/kernel/cpufreq.c linux/kernel/cpufreq.c
--- linux-original/kernel/cpufreq.c 2002-11-23 09:09:03.000000000 +0100
+++ linux/kernel/cpufreq.c 2002-12-13 15:07:23.000000000 +0100
@@ -119,8 +119,8 @@
if (sscanf(input_string, "%d%%%d%%%d%%%s", &cpu, &min, &max, policy_string) == 4)
{
if (!cpufreq_get_policy(¤t_policy, cpu)) {
- policy->min = (min * current_policy.max_cpu_freq) / 100;
- policy->max = (max * current_policy.max_cpu_freq) / 100;
+ policy->min = (min * current_policy.cpuinfo.max_freq) / 100;
+ policy->max = (max * current_policy.cpuinfo.max_freq) / 100;
policy->cpu = cpu;
result = 0;
goto scan_policy;
@@ -138,8 +138,8 @@
if (sscanf(input_string, "%d%%%d%%%s", &min, &max, policy_string) == 3)
{
if (!cpufreq_get_policy(¤t_policy, cpu)) {
- policy->min = (min * current_policy.max_cpu_freq) / 100;
- policy->max = (max * current_policy.max_cpu_freq) / 100;
+ policy->min = (min * current_policy.cpuinfo.max_freq) / 100;
+ policy->max = (max * current_policy.cpuinfo.max_freq) / 100;
result = 0;
goto scan_policy;
}
@@ -229,11 +229,11 @@
cpufreq_get_policy(&policy, i);
- if (!policy.max_cpu_freq)
+ if (!policy.cpuinfo.max_freq)
continue;
- min_pctg = (policy.min * 100) / policy.max_cpu_freq;
- max_pctg = (policy.max * 100) / policy.max_cpu_freq;
+ min_pctg = (policy.min * 100) / policy.cpuinfo.max_freq;
+ max_pctg = (policy.max * 100) / policy.cpuinfo.max_freq;
p += sprintf(p, "CPU%3d %9d kHz (%3d %%) - %9d kHz (%3d %%) - ",
i , policy.min, min_pctg, policy.max, max_pctg);
@@ -279,6 +279,7 @@
int result = 0;
char proc_string[42] = {'\0'};
struct cpufreq_policy policy;
+ unsigned int i = 0;
if ((count > sizeof(proc_string) - 1))
@@ -293,7 +294,17 @@
if (result)
return -EFAULT;
- cpufreq_set_policy(&policy);
+ if (policy.cpu == CPUFREQ_ALL_CPUS)
+ {
+ for (i=0; i<NR_CPUS; i++)
+ {
+ policy.cpu = i;
+ if (cpu_online(i))
+ cpufreq_set_policy(&policy);
+ }
+ }
+ else
+ cpufreq_set_policy(&policy);
return count;
}
@@ -811,7 +822,9 @@
policy->min = cpufreq_driver->policy[cpu].min;
policy->max = cpufreq_driver->policy[cpu].max;
policy->policy = cpufreq_driver->policy[cpu].policy;
- policy->max_cpu_freq = cpufreq_driver->policy[cpu].max_cpu_freq;
+ policy->cpuinfo.max_freq = cpufreq_driver->policy[cpu].cpuinfo.max_freq;
+ policy->cpuinfo.min_freq = cpufreq_driver->policy[cpu].cpuinfo.min_freq;
+ policy->cpuinfo.transition_latency = cpufreq_driver->policy[cpu].cpuinfo.transition_latency;
policy->cpu = cpu;
up(&cpufreq_driver_sem);
@@ -835,16 +848,14 @@
down(&cpufreq_driver_sem);
if (!cpufreq_driver || !cpufreq_driver->verify ||
!cpufreq_driver->setpolicy || !policy ||
- (policy->cpu > NR_CPUS)) {
+ (policy->cpu >= NR_CPUS) || (!cpu_online(policy->cpu))) {
up(&cpufreq_driver_sem);
return -EINVAL;
}
- if (policy->cpu == CPUFREQ_ALL_CPUS)
- policy->max_cpu_freq = cpufreq_driver->policy[0].max_cpu_freq;
- else
- policy->max_cpu_freq = cpufreq_driver->policy[policy->cpu].max_cpu_freq;
-
+ policy->cpuinfo.max_freq = cpufreq_driver->policy[policy->cpu].cpuinfo.max_freq;
+ policy->cpuinfo.min_freq = cpufreq_driver->policy[policy->cpu].cpuinfo.min_freq;
+ policy->cpuinfo.transition_latency = cpufreq_driver->policy[policy->cpu].cpuinfo.transition_latency;
/* verify the cpu speed can be set within this limit */
ret = cpufreq_driver->verify(policy);
@@ -1039,8 +1050,8 @@
down(&cpufreq_driver_sem);
for (i=0; i<NR_CPUS; i++)
{
- cpu_min_freq[i] = driver_data->cpu_min_freq[i];
- cpu_max_freq[i] = driver_data->policy[i].max_cpu_freq;
+ cpu_min_freq[i] = driver_data->policy[i].cpuinfo.min_freq;
+ cpu_max_freq[i] = driver_data->policy[i].cpuinfo.max_freq;
cpu_cur_freq[i] = driver_data->cpu_cur_freq[i];
}
up(&cpufreq_driver_sem);
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: oops: 2.5.51 lock_get_status
From: Alex Riesen @ 2002-12-13 15:08 UTC (permalink / raw)
To: Burton Windle; +Cc: linux-kernel, Matthew Wilcox, mdew
In-Reply-To: <Pine.LNX.4.43.0212130942110.31117-100000@morpheus>
Burton Windle, Fri, Dec 13, 2002 15:42:20 +0100:
> This might also be of interest...
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103825968004879&w=2
>
hmm... This:
| note, do not use NFS when using this patch. really; i mean it. somehow
| i managed to corrupt thread_info.cpu causing _udelay_ to oops.
doesn't look very encouraging.
Maybe there is already some news about it?
I volunteer to test anything :)
as being hit by the bug.
-alex
> On Fri, 13 Dec 2002, Alex Riesen wrote:
>
> > Burton Windle, Fri, Dec 13, 2002 15:08:45 +0100:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=16
> > >
> >
> > Oh, thanks. Still fogetting about the new thing to look before.
> >
> > > On Fri, 13 Dec 2002, Alex Riesen wrote:
> > >
> > > > 2.5.51+bk as of 12 Dec 23:00 CET.
> > > >
> > > > tried to strace(4.4) the d4x with follow-fork mode.
> > > > d4x is a multi-threaded app using posix advisory locks.
> > > > (http://www.krasu.ru/soft/chuchelo/)
> > > >
> > > > The thing calls fcntl, which fails as if the file were locked:
> > > >
> >
^ permalink raw reply
* RE: mcc support on mpc8260
From: Allen Curtis @ 2002-12-13 14:59 UTC (permalink / raw)
To: Ing.Gianfranco Morandi, Omanakuttan, linuxppc-embedded
In-Reply-To: <00ee01c2a28c$9758de20$0700a8c0@pc005>
> Be aware do not use the mcc with the silicon revision older than B.1.
Could you provide more information on this comment. There are lots of
reasons not to use a rev A.1 chip. This is the first time that I heard about
using too new of a chip.
THX
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Symlink indirection
From: Andrew Walrond @ 2002-12-13 15:06 UTC (permalink / raw)
To: linux-kernel, libc-alpha
Quick question;
Is the number of allowed levels of symlink indirection (if that is the
right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
kernel, or libc ? Where is it defined, and can it be changed?
TIA
Andrew
^ permalink raw reply
* Re: [LARTC] How to limit bandwidth by port?
From: Andrea Rossato @ 2002-12-13 14:57 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103972758027709@msgid-missing>
DOWNLINK"0
UPLINK\x125
DEV=ppp0
tc qdisc add dev $DEV root handle 1: htb default 10
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
ceil $[UPLINK}kbit burst 6k prio 1
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[3*$UPLINK/10]kbit\
ceil $[9*$UPLINK/10]kbit burst 6k prio 2
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip dport 8080 0xffff flowid 1:20
traffic to dport 80 will get 3/10 of bandwith (with possibility to
borrow up to 9/10)
andrea
David Coello wrote:
> Hi again
>
> I am making all the test and probes i cann´t imagine but i begin to
> think it´s imposible to limit bandwidth by port. Anybody could put me a
> code example that makes this please?
>
> Thanks and regards
> David Coello
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [U-Boot-Users] Big ppcboot image
From: Chris Hallinan @ 2002-12-13 14:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB4E9CE4@kuumex05.barco.com>
The fact that PPCBoot is reporting incorrect sizes indicates that
your image is too big for the linker script (.lds file) object file
allocation and memory organization. Your image is far too big. You
would have to customize your .lds file and it isn't worth the
effort. Another option might be this: burn your linux kernel image
into an unused portion of your flash at a known address, and have
your boot command do the "bootm" command at that address, such as
the following:
prog 0xffa00000 ppcboot-linux-image
and your boot command would be:
bootm 0xffa00000
Chris Hallinan
DS4.COM, Inc.
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On
> Behalf Of Callebaut,
> Beno?t
> Sent: Friday, December 13, 2002 9:37 AM
> To: U-Boot-Users at Sourceforge. Net (E-mail)
> Subject: [U-Boot-Users] Big ppcboot image
>
>
>
> Hello,
> I am using ppcboot 2.0.0 and I placed the linux kernel in
> the ppcboot image
> ( included in an header file).
> Note that I use automatic boot (ie I don't use the main loop)
> The idea is that instead of loading the image from an
> esternal source
> (nfs,...) I use only bootm to boot the image directly from memory.
> THe problem is that the ppcboot image is now around 720
> kBytes instead of
> 120 kBytes. And something goes wrong at the end of the
> board_init_f just
> before the realocation (realocate_code) or in it.
> PPCBoot give me the following message "PPCBoot size
> -292044 > reserved
> (786432)"
>
> Some tips on what is going wrong.
> ----------------------------------------------------------
> ------------------
> ------
> Benoit Callebaut
> Software Development Engineer
> Barco | Control Rooms
> Noordlaan 5, 8520 Kuurne, Belgium
>
> Tel +32(0)56 36 84 28
> Fax +32(0)56 36 86 05
>
> mailto:benoit.callebaut at barco.com
> http://www.barcocontrolrooms.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance
> Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
* [U-Boot-Users] Big ppcboot image
From: Marius Groeger @ 2002-12-13 14:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB4E9CE4@kuumex05.barco.com>
On Fri, 13 Dec 2002, "Callebaut, Beno?t" wrote:
> I am using ppcboot 2.0.0 and I placed the linux kernel in the ppcboot image
> ( included in an header file).
Why don't you build a multi-file image (see the mkimage tool options)?
This implements just what you seem to need.
> PPCBoot give me the following message "PPCBoot size -292044 > reserved
> (786432)"
If you _must_ do this for some strange reason, check the
CFG_MONITOR_LEN setting in your platform's config file. But again: I
don't think you should be doing this.
Regards
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger at sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
^ permalink raw reply
* Unauthorized Activity Detection using IPTables
From: Amit Kumar Gupta @ 2002-12-13 14:44 UTC (permalink / raw)
To: netfilter
[-- Attachment #1.1: Type: text/plain, Size: 248 bytes --]
Hi,
I want to know how to detect unauthorized activities in firewall using
IPtables.
If any user tries for some unauthorized service, I should be able to log
it and drop it.
Please give suggestions.
Thanks & Regards.
Amit
[-- Attachment #1.2: Type: text/html, Size: 4561 bytes --]
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 514 bytes --]
**************************Disclaimer************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************************
^ permalink raw reply
* Re: PROCESS IMIGRATION
From: Arnaldo Carvalho de Melo @ 2002-12-13 14:47 UTC (permalink / raw)
To: Breno; +Cc: Kernel List
In-Reply-To: <000701c2a208$f50e7a40$8be1a7c8@bsb.virtua.com.br>
Em Thu, Dec 12, 2002 at 04:04:46PM -0200, Breno escreveu:
> I saw something about one project of FreeBSD and this is about imigration of
> processes between two machines.
> The kernel Linux has something about this , or some project like that ?
Right next door (oops, city):
http://www.cos.ufrj.br/~edpin/epckpt/
What is EPCKPT?
EPCKPT is a checkpoint/restart utility built into the Linux kernel.
Checkpointing is the ability to save an image of the state of a
process (or group of processes) at a certain point during its
lifetime. Checkpoints are important to a wide range of applications.
The most common uses for checkpointing are:
* Fault-tolerance
* Applications trace/Debugging
* Rollback/Animated playback
* Process migration
Our main interest right now is process migration. So, we optimized
EPCKPT to make process' image the smaller possible, so migration costs
would be low.
- Arnaldo
^ permalink raw reply
* Re: IDE feature request & problem
From: Vojtech Pavlik @ 2002-12-13 14:41 UTC (permalink / raw)
To: Pavel Machek
Cc: Vojtech Pavlik, Alan Cox, Milan Roubal, Petr Sebor,
Linux Kernel Mailing List
In-Reply-To: <20021212181250.GB184@elf.ucw.cz>
On Thu, Dec 12, 2002 at 07:12:50PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > I have got xfs partition and man fsck.xfs say
> > > > that it will run automatically on reboot.
> > >
> > > You need to force one. Something (I assume XFS) asked the disk for a
> > > stupid sector number. Thats mostly likely due to some kind of internal
> > > corruption on the XFS
> >
> > Or the power supply doesn't give enough power to the drives anymore (my
> > 350W PSU is having heavy problems with five or more drives), and the IDE
> > transfers get garbled. Note that there is no CRC protection for non-data
> > xfers even when UDMA is in use, which includes LBA sector addressing.
>
> But kernel would not log bogus LBA in such case.
It could, if the drive has read a different sector than it was supposed
to and the filesystem got confused by the data ...
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* [U-Boot-Users] Big ppcboot image
From: "Callebaut, Benoît" @ 2002-12-13 14:36 UTC (permalink / raw)
To: u-boot
Hello,
I am using ppcboot 2.0.0 and I placed the linux kernel in the ppcboot image
( included in an header file).
Note that I use automatic boot (ie I don't use the main loop)
The idea is that instead of loading the image from an esternal source
(nfs,...) I use only bootm to boot the image directly from memory.
THe problem is that the ppcboot image is now around 720 kBytes instead of
120 kBytes. And something goes wrong at the end of the board_init_f just
before the realocation (realocate_code) or in it.
PPCBoot give me the following message "PPCBoot size -292044 > reserved
(786432)"
Some tips on what is going wrong.
----------------------------------------------------------------------------
------
Benoit Callebaut
Software Development Engineer
Barco | Control Rooms
Noordlaan 5, 8520 Kuurne, Belgium
Tel +32(0)56 36 84 28
Fax +32(0)56 36 86 05
mailto:benoit.callebaut at barco.com
http://www.barcocontrolrooms.com
^ permalink raw reply
* Re: using 2 TB in real life
From: Anders Henke @ 2002-12-13 14:43 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel, marcelo
In-Reply-To: <UTC200212122315.gBCNFdp22965.aeb@smtp.cwi.nl>
On December 13th 2002, Andries.Brouwer@cwi.nl wrote:
> > SCSI device sdb: -320126976 512-byte hdwr sectors (-163904 MB)
>
> Yes, the code in 2.4.20 works up to 30 bits.
> A slight modification works up to 31 bits.
It works up to less than 30 bits - a 0.9 TB Device shows up as
SCSI device sdb: 1806745600 512-byte hdwr sectors (-174457 MB)
while a 480 GB Device (correctly) shows up this way:
SCSI device sda: 961818624 512-byte hdwr sectors (492451 MB)
At 0.5 TB (29 bits) the first problem occurs: negative size.
At 1 T (30 bits), the sector count also becomes negative.
Your patch (thank you!) does fix both problems and up to 1.9 TB,
everything works as expected:
SCSI device sdb: 3974840320 512-byte hdwr sectors (2035118 MB)
Yes, it's purely cosmetical, but should be included in the main tree.
Regards,
Anders
--
http://sysiphus.de
^ permalink raw reply
* Re: key "stuck" after resume
From: Vojtech Pavlik @ 2002-12-13 14:43 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list
In-Reply-To: <20021212194644.GA767@elf.ucw.cz>
On Thu, Dec 12, 2002 at 08:46:44PM +0100, Pavel Machek wrote:
> Hi!
>
> Vojtech, would it be possible to clear "keyboard down" map during
> resume? It is pretty unlikely to be valid at that point :-).
> Pavel
Yes, that is possible (and not that hard to do).
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: [2.5.51] Failure to mount ext3 root when ext2 compiled in
From: Mohamed El Ayouty @ 2002-12-13 14:35 UTC (permalink / raw)
To: Rusty Russell; +Cc: LKML
Hi,
This sounds more like the bug I have opened:
http://bugme.osdl.org/show_bug.cgi?id=110
where if CONFIG_DEVFS_FS = Y and CONFIG_DEVFS_MOUNT = Y, you will get:
VFS: Cannot open root device "hda2" or 03:02
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 03:02
I worked around it by enabling CONFIG_UNIX98_PTYS = Y under the
character devices.
But, a recent update to the bug shows that a patch was posted but nobody
cared.
Personally, I think the patch should be merged.
Mohamed
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Gary Thomas @ 2002-12-13 14:26 UTC (permalink / raw)
To: Cort Dougan; +Cc: linuxppc embedded
In-Reply-To: <20021212215126.V23952@duath.fsmlabs.com>
On Thu, 2002-12-12 at 21:51, Cort Dougan wrote:
>
> Would you be able to commit them to _2_4 instead so they're not in the
> wildly divergent _2_4_devel tree? That would definitely be handy when
> trying to find where the working trees are.
>
> } The patch below adds support for IBM's Arctic-II development system,
> } based on the 405LP processor. For now this is just the core support,
> } more drivers coming soon. Are there any objections, or suggestions
> } for doing things better before I commit this to linuxppc_2_4_devel?
> }
This brings up some really good questions. I have support for three new
platforms based on the _2_4_devel tree which I'd like to get submitted
soon [so far, I've just been following along] So,
* Which tree should be best for new development/ports/etc?
* What's the best process for proposing changes? I've seen many
patches come along on this list, but it's not clear to me if/when
they made it to any particular tree.
Thanks.
--
------------------------------------------------------------
Gary Thomas |
MLB Associates | Consulting for the
+1 (970) 229-1963 | Embedded world
http://www.mlbassoc.com/ |
email: <gary@mlbassoc.com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [2.5.51] Failure to mount ext3 root when ext2 compiled in
From: Wayne Willson @ 2002-12-13 14:31 UTC (permalink / raw)
To: Rusty Russell, akpm, viro; +Cc: linux-kernel
In-Reply-To: <20021213035016.339092C24F@lists.samba.org>
I have seen the exact same problem. Turning off CONFIG_EXT2_FS fixes it for
me as well.
----- Original Message -----
From: "Rusty Russell" <rusty@rustcorp.com.au>
To: <akpm@zip.com.au>; <viro@math.psu.edu>
Cc: <linux-kernel@vger.kernel.org>
Sent: Thursday, December 12, 2002 9:48 PM
Subject: [2.5.51] Failure to mount ext3 root when ext2 compiled in
> Just noticed this (usually ext2 is compiled as a module, but was
> testing a patch with CONFIG_MODULES=n). Reverted to plain 2.5.51, and
> it's still there:
>
> VFS: Cannot open root device "301" or 03:01
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 03:01
>
> Now, I have an ext3 root, but when CONFIG_EXT3_FS=y and
> CONFIG_EXT2_FS=y, I get this failure. Turning off CONFIG_EXT2_FS
> "fixes" it.
>
> Hope this helps,
> Rusty.
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Linux installation on DOC / problems / I need your help
From: Carlos Mateo @ 2002-12-13 16:50 UTC (permalink / raw)
To: Alejandro O. Gonzalez, linux-mtd
In-Reply-To: <002c01c2a2a9$54ea2900$a2e4f4d8@nnn123>
The second problem you described (UnitSizeFactor != 1) was solved some time
ago. Try the latest CVS code.
I have used it with DFORMAT and grub as bootloader and it works.
Carlos Mateo
El Vie 13 Dic 2002 12:12, Alejandro O. Gonzalez escribió:
> I rebuild the kernel. Then I made this
>
> 1- run the driver
> #modprobe doc2000
> #modprobe docprobe
>
> 2- format the memory
> #nftl_format /dev/mtd0 0 16777216
>
> 3- run nftl
> #modprobe nftl
>
> 4- make a partition
> #fdisk /dev/nftla
> I make two partition first DOS, and second Linux.
>
> 5- make filesystem
> #mkfs.msdos /dev/nftla1
> #mke2fs /dev/nftla2
>
> 6-Install syslinux
> #syslinux /dev/nftla1
>
> 7-configure boot and reboot
>
> I don´t know if this procedure is correct, but when reboot the bios not
> found a valid boot device.
> When I format all memory with nftl_format command I delete the TrueFFS bios
> of MSYS. This is Ok ?
>
> I try then to overwrite the TrueFFS bios driver
>
> DFORMAT /WIN:E000 /S:DOC512.EXB /NOFORMAT /FIRST
>
> but display an error, can´t write the bios.
>
> I do so that the bios recognize the DOC like a valid device of boot.
>
> I try also to format with MSYS utility, then create a 2MB of DOS partition.
> Boot with linux and format the last 14 MB of memory with
> nftl_format. But when startup nftl driver says "we don´t support
> UnitSizeFactor!=1" and it is not possible to work with a nftl partition.
> I will appreciate any commentary, thank you for your time.
> Regards,
> Alejandro Gonzalez
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: Linux 2.4.21-pre1 IDE
From: Tomas Szepe @ 2002-12-13 14:23 UTC (permalink / raw)
To: Alan Cox; +Cc: andersen, Marcelo Tosatti, lkml
In-Reply-To: <1039698648.21446.30.camel@irongate.swansea.linux.org.uk>
> > hda: DMA disabled
> > ^^^^^^^^^^^^^^^^^
> >
> > What's up with this? For each drive in my system it claims it
> > has disabled DMA. But hdparm later reports that DMA is in fact
> > enabled. In fact, later on the kernel ever reports the drive
> > as being in UDMA 100 mode... I think these "DMA disabled"
> > messages are bogus.
>
> Cosmetic and known. It in fact turns DMA back on - quietly
Alan, I sent you a patch fixing this last week, can resend if necessary.
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply
* kernel.org down?
From: John Bradford @ 2002-12-13 14:35 UTC (permalink / raw)
To: linux-kernel
I can't connect via http to kernel.org - ftp is fine. Is this a planned outage?
John.
^ permalink raw reply
* Re: separation of sysctl and tcp-window-tracking patch?
From: Denis Ducamp @ 2002-12-13 14:17 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <Pine.LNX.4.44.0212120252370.3113-100000@shieldbreaker.l33tskillz.org>
On Thu, Dec 12, 2002 at 03:05:33AM -0500, James Ralston wrote:
> (My specific need is related to DNS service: namely, in many cases, 30
> seconds to establish a UDP session simply isn't enough time to permit
> a reply to an outstanding DNS query. I want to be able to up that
> timeout to something closer to 60 or 120 seconds.)
If your DNS servers serve zones then make them send requests from the udp/53
port, then late replies are accepted as requests by the filter.
Denis Ducamp.
^ permalink raw reply
* FTP and connection tracking
From: Hans Jorgensen @ 2002-12-13 14:16 UTC (permalink / raw)
To: netfilter-devel
Dear list
I am currently developing an application which is using DNAT and
masquerading. First an incoming packet is DNAT'ed to have as specific dest.
ip. The it is masquerading when it is leaving the decided interface.
This works fine, but when I use FTP, the following shows up in the kernel
log:
<4>ip_conntrack_in: related packet for c3a22310
<4>nat_expected: We have a connection!
<4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
<4>nat_expected: IP to 192.168.4.1
<4>Found best for tuple c3d69db8: 6 10.0.0.8:1026 -> 192.168.4.1:11697
<4>nat_expected: We have a connection!
<4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
<4>nat_expected: IP to 192.168.1.254
<4>Found best for tuple c3d69cf0: 6 192.168.1.254:1026 -> 192.168.4.1:11697
<4>Altering reply tuple of c3a22310 to tuple c3d69cd0: 6 192.168.4.1:11697
-> 192.168.1.254:1026
<4>Mangling c3ad4140: SRC to 192.168.1.254 1026
<4>Confirming conntrack c3a22310
My question is:
Why does: "We have a connection!" and the following lines show up two times?
Is the connection data traversing the same chain twice?
Does anybody know where I can find more information on how the code in
connection tracking and NAT works?
Thanks in advance.
/Hans
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Bom dia netdev
From: Ricardo @ 2002-12-13 14:08 UTC (permalink / raw)
To: netdev
Olá netdev netdev@oss.sgi.com
Estou fazendo a divulgação dos produtos abaixo.
Se lhe interessar visite o site dos distribuidores, com certeza será uma boa oputunidade de negócios.
Caso não seje de seu interesse favor deletar este e-mail ou se possível repasse aos seus amigos.
Boas festas e feliz 2003.
Atenciosamente....
Ricardo L. C. Kampff.
=========================================================================================
Camera Falsa: Site de produtos de segurança e espionagem.
Destaques: Cameras de segurança falsas, escuta telefonica entre outros...
http://www.camerafalsa.home-page.cc/
=========================================================================================
Clássicos da literatura infantil: Kit maleta com 10 livros infantis e CD de aúdio com a narrativas das estórias apenas R$19,80.
http://www.livro.url4life.com
=========================================================================================
^ permalink raw reply
* Re: Vaguely NFS related problem
From: Trond Myklebust @ 2002-12-13 14:07 UTC (permalink / raw)
To: Jeff L. Smith; +Cc: Neil Brown, nfs
In-Reply-To: <3DF8C2BF.8050109@atheros.com>
>>>>> " " == Jeff L Smith <jeff@atheros.com> writes:
> I plan to upgrade to 2.4.20 as soon as I can take the
> fileservers down long enough, but that will be a few weeks.
> But then that begs the question, should I apply Trond's 2.4.20
> patches?
FYI: There are no further NFS server-related patches in my 2.4.20
patchsets.
The only server patches I included earlier were beta-versions of the
NFS over TCP related stuff ('cos they conflicted with some of the
client changes). Now that the finalized TCP code has been merged into
the mainstream kernel by Neil, I've dropped them.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.