* Re: [PATCH] set_cpus_allowed() for 2.4
From: Christoph Hellwig @ 2002-12-13 23:08 UTC (permalink / raw)
To: marcelo; +Cc: rml, linux-kernel
Hi Marcelo,
now that all vendors ship a backport of Ingo's O(1) scheduler, external
projects like XFS have to track those trees in addition to the mainline kernel.
Having the common new APIs available in mainline would be a very good thing
to have for us and others. Now that 2.4.20 already has a working yield()
the biggest missing part is set_cpus_allowed() to limit (kernel-)threads
to a specific CPU or set of CPUs.
--- linux/include/linux/sched.h~ Mon Sep 30 17:41:22 2002
+++ linux/include/linux/sched.h Tue Oct 1 18:35:28 2002
@@ -163,6 +164,12 @@
extern int start_context_thread(void);
extern int current_is_keventd(void);
+#if CONFIG_SMP
+extern void set_cpus_allowed(struct task_struct *p, unsigned long new_mask);
+#else
+# define set_cpus_allowed(p, new_mask) do { } while (0)
+#endif
+
/*
* The default fd array needs to be at least BITS_PER_LONG,
* as this is the granularity returned by copy_fdset().
--- linux/kernel/ksyms.c~ Mon Sep 30 17:41:22 2002
+++ linux/kernel/ksyms.c Tue Oct 1 18:34:41 2002
@@ -451,6 +451,9 @@
EXPORT_SYMBOL(interruptible_sleep_on_timeout);
EXPORT_SYMBOL(schedule);
EXPORT_SYMBOL(schedule_timeout);
+#if CONFIG_SMP
+EXPORT_SYMBOL(set_cpus_allowed);
+#endif
EXPORT_SYMBOL(yield);
EXPORT_SYMBOL(__cond_resched);
EXPORT_SYMBOL(jiffies);
--- linux/kernel/sched.c~ Mon Sep 30 17:41:22 2002
+++ linux/kernel/sched.c Tue Oct 1 18:54:49 2002
@@ -850,6 +850,45 @@
void scheduling_functions_end_here(void) { }
+#if CONFIG_SMP
+/**
+ * set_cpus_allowed() - change a given task's processor affinity
+ * @p: task to bind
+ * @new_mask: bitmask of allowed processors
+ *
+ * Upon return, the task is running on a legal processor. Note the caller
+ * must have a valid reference to the task: it must not exit() prematurely.
+ * This call can sleep; do not hold locks on call.
+ */
+void set_cpus_allowed(struct task_struct *p, unsigned long new_mask)
+{
+ new_mask &= cpu_online_map;
+ BUG_ON(!new_mask);
+
+ p->cpus_allowed = new_mask;
+
+ /*
+ * If the task is on a no-longer-allowed processor, we need to move
+ * it. If the task is not current, then set need_resched and send
+ * its processor an IPI to reschedule.
+ */
+ if (!(p->cpus_runnable & p->cpus_allowed)) {
+ if (p != current) {
+ p->need_resched = 1;
+ smp_send_reschedule(p->processor);
+ }
+
+ /*
+ * Wait until we are on a legal processor. If the task is
+ * current, then we should be on a legal processor the next
+ * time we reschedule. Otherwise, we need to wait for the IPI.
+ */
+ while (!(p->cpus_runnable & p->cpus_allowed))
+ schedule();
+ }
+}
+#endif /* CONFIG_SMP */
+
#ifndef __alpha__
/*
^ permalink raw reply
* Re: Unauthorized Activity Detection using IPTables
From: Maciej Soltysiak @ 2002-12-13 15:46 UTC (permalink / raw)
To: Amit Kumar Gupta; +Cc: netfilter
In-Reply-To: <4223A04BF7D1B941A25246ADD0462FF559A362@blr-m3-msg.wipro.com>
Hello,
If you construct your firewall like this:
- allow what's allow
- log and drop everything else.
You will have what you need.
you can use something like:
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
and at the end of your chains add:
iptables -A FORWARD -j logdrop
This is for FORWARD chain, change it to whatever you need.
Regards,
Maciej Soltysiak
^ permalink raw reply
* oops in the 2.4.20-NFSALL sunrpc code
From: Trond Myklebust @ 2002-12-13 15:42 UTC (permalink / raw)
To: Ion Badulescu; +Cc: nfs
In-Reply-To: <Pine.LNX.4.44.0212131002500.15305-100000@moisil.badula.org>
>>>>> " " == Ion Badulescu <ionut@badula.org> writes:
> It's caused, from what I can tell, by task->tk_client being
> NULL in xprt_timer() at the time it is dereferenced. Looks like
> a race condition, probably facilitated by the SMP kernel.
It's definitely not a race condition: Every new task is supposed to
call rpc_init_task() prior to calling rpc_execute(). This
again initializes task->tk_client once and for all. It is never
allowed to change.
There is only one exception to the above rule, namely nfs_flushd,
(which can never stray into net/sunrpc/xprt.c).
All I can say about this one is that it doesn't look like anything
I've come across on any other setups. Have you tried to reproduce it
on an actual 2.4.20 kernel?
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
* [PATCH 2.5] cpufreq: move x86 configuration to "Power Management"
From: Dominik Brodowski @ 2002-12-13 15:47 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, cpufreq, alan, davej
This patch moves the Kconfig entries for CPUfreq from "Processor type and
features" to "Power management options".
Dominik
diff -ruN linux-cpuinfo/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-cpuinfo/arch/i386/Kconfig 2002-12-13 15:56:21.000000000 +0100
+++ linux/arch/i386/Kconfig 2002-12-13 16:20:24.000000000 +0100
@@ -465,104 +465,6 @@
Enabling this feature will cause a message to be printed when the P4
enters thermal throttling.
-config CPU_FREQ
- bool "CPU Frequency scaling"
- help
- Clock scaling allows you to change the clock speed of CPUs on the
- fly. This is a nice method to save battery power on notebooks,
- because the lower the clock speed, the less power the CPU consumes.
-
- For more information, take a look at linux/Documentation/cpufreq or
- at <http://www.brodo.de/cpufreq/>
-
- If in doubt, say N.
-
-config CPU_FREQ_24_API
- bool "/proc/sys/cpu/ interface (2.4. / OLD)"
- depends on CPU_FREQ
- help
- This enables the /proc/sys/cpu/ sysctl interface for controlling
- CPUFreq, as known from the 2.4.-kernel patches for CPUFreq. 2.5
- uses /proc/cpufreq instead. Please note that some drivers do not
- work well with the 2.4. /proc/sys/cpu sysctl interface, so if in
- doubt, say N here.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config X86_POWERNOW_K6
- tristate "AMD Mobile K6-2/K6-3 PowerNow!"
- depends on CPU_FREQ
- help
- This adds the CPUFreq driver for mobile AMD K6-2+ and mobile
- AMD K6-3+ processors.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config ELAN_CPUFREQ
- tristate "AMD Elan"
- depends on CPU_FREQ && MELAN
- ---help---
- This adds the CPUFreq driver for AMD Elan SC400 and SC410
- processors.
-
- You need to specify the processor maximum speed as boot
- parameter: elanfreq=maxspeed (in kHz) or as module
- parameter "max_freq".
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config X86_LONGHAUL
- tristate "VIA Cyrix III Longhaul"
- depends on CPU_FREQ
- help
- This adds the CPUFreq driver for VIA Samuel/CyrixIII,
- VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T
- processors.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config X86_SPEEDSTEP
- tristate "Intel Speedstep"
- depends on CPU_FREQ
- help
- This adds the CPUFreq driver for certain mobile Intel Pentium III
- (Coppermine), all mobile Intel Pentium III-M (Tulatin) and all
- mobile Intel Pentium 4 P4-Ms.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config X86_P4_CLOCKMOD
- tristate "Intel Pentium 4 clock modulation"
- depends on CPU_FREQ
- help
- This adds the CPUFreq driver for Intel Pentium 4 / XEON
- processors.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
-config X86_LONGRUN
- tristate "Transmeta LongRun"
- depends on CPU_FREQ
- help
- This adds the CPUFreq driver for Transmeta Crusoe processors which
- support LongRun.
-
- For details, take a look at linux/Documentation/cpufreq.
-
- If in doubt, say N.
-
config TOSHIBA
tristate "Toshiba Laptop support"
---help---
@@ -985,6 +887,104 @@
a work-around for a number of buggy BIOSes. Switch this option on if
your computer crashes instead of powering off properly.
+config CPU_FREQ
+ bool "CPU Frequency scaling"
+ help
+ Clock scaling allows you to change the clock speed of CPUs on the
+ fly. This is a nice method to save battery power on notebooks,
+ because the lower the clock speed, the less power the CPU consumes.
+
+ For more information, take a look at linux/Documentation/cpufreq or
+ at <http://www.brodo.de/cpufreq/>
+
+ If in doubt, say N.
+
+config CPU_FREQ_24_API
+ bool "/proc/sys/cpu/ interface (2.4. / OLD)"
+ depends on CPU_FREQ
+ help
+ This enables the /proc/sys/cpu/ sysctl interface for controlling
+ CPUFreq, as known from the 2.4.-kernel patches for CPUFreq. 2.5
+ uses /proc/cpufreq instead. Please note that some drivers do not
+ work well with the 2.4. /proc/sys/cpu sysctl interface, so if in
+ doubt, say N here.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config X86_POWERNOW_K6
+ tristate "AMD Mobile K6-2/K6-3 PowerNow!"
+ depends on CPU_FREQ
+ help
+ This adds the CPUFreq driver for mobile AMD K6-2+ and mobile
+ AMD K6-3+ processors.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config ELAN_CPUFREQ
+ tristate "AMD Elan"
+ depends on CPU_FREQ && MELAN
+ ---help---
+ This adds the CPUFreq driver for AMD Elan SC400 and SC410
+ processors.
+
+ You need to specify the processor maximum speed as boot
+ parameter: elanfreq=maxspeed (in kHz) or as module
+ parameter "max_freq".
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config X86_LONGHAUL
+ tristate "VIA Cyrix III Longhaul"
+ depends on CPU_FREQ
+ help
+ This adds the CPUFreq driver for VIA Samuel/CyrixIII,
+ VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T
+ processors.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config X86_SPEEDSTEP
+ tristate "Intel Speedstep"
+ depends on CPU_FREQ
+ help
+ This adds the CPUFreq driver for certain mobile Intel Pentium III
+ (Coppermine), all mobile Intel Pentium III-M (Tulatin) and all
+ mobile Intel Pentium 4 P4-Ms.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config X86_P4_CLOCKMOD
+ tristate "Intel Pentium 4 clock modulation"
+ depends on CPU_FREQ
+ help
+ This adds the CPUFreq driver for Intel Pentium 4 / XEON
+ processors.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
+config X86_LONGRUN
+ tristate "Transmeta LongRun"
+ depends on CPU_FREQ
+ help
+ This adds the CPUFreq driver for Transmeta Crusoe processors which
+ support LongRun.
+
+ For details, take a look at linux/Documentation/cpufreq.
+
+ If in doubt, say N.
+
endmenu
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: William Lee Irwin III @ 2002-12-13 15:45 UTC (permalink / raw)
To: Mike Hayward; +Cc: linux-kernel
In-Reply-To: <200212090830.gB98USW05593@flux.loup.net>
On Mon, Dec 09, 2002 at 01:30:28AM -0700, Mike Hayward wrote:
> Any ideas? Not sure I want to upgrade to the P7 architecture if this
> is right, since for me system calls are probably more important than
> raw cpu computational power.
This is the same for me. I'm extremely uninterested in the P-IV for my
own use because of this.
Bill
^ permalink raw reply
* Updated Release
From: Howard Holm @ 2002-12-13 15:41 UTC (permalink / raw)
To: selinux
The SELinux web site <http://www.nsa.gov/selinux/> including the mail
list archive has been updated. The site includes a new release of the
LSM-based SELinux prototype. The base kernel versions have been updated
to 2.4.20 and 2.5.51. Initial SID and context for SCMP packets has been
added. Additional policy enhancement and patch contributions have been
merged. The logrotate patch has been updated to 3.6.5-2. The private
file oversight in LSM, inode_doinit bug in SELinux, and selopt compile
problems have all been fixed.
--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* raid5: switching cache buffer size
From: Gordon Henderson @ 2002-12-13 15:38 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <Pine.LNX.4.43.0212091504450.30636-100000@unicorn.drogon.net>
Anyone know what this means?
My big server is currently fscking a lvm partition which sits on-top of a
raid5 device and the console is scrolling these messages as fast as it can.
It says it's switching from 0 to 512, from 512 to 0 and 0 to 1024 ( or
maybe 512 to 1024, its hard to tell).
What's happening and how do I stop it?
Cheers,
Gordon
Ps. earlier FSCK problems seemed to be due to dodgy AMD motherboard
hardware and (U)DMA. It's a documented AMD bug and they have no
workaround, but plugging a ps/2 mouse in seems to fix it...
^ permalink raw reply
* Re: mcc support on mpc8260
From: Omanakuttan @ 2002-12-13 15:38 UTC (permalink / raw)
To: gianfranco.morandi, linuxppc-embedded
In-Reply-To: <00ee01c2a28c$9758de20$0700a8c0@pc005>
Ing.Gianfranco Morandi wrote:
> I have promised to Pete of releasing some code for such driver. We will
> provide to perform such task during the next days.
Thank you very much for this information. Since I will be working on
that, I will also be glad to contribute something to your activities.
>
> Actually we are writing some documents to better describe the driver and how
> to lock it to the kernel tree.
Once I understand it, I will definitely contribute to your efforts.
> Anyway on the Motorola site, You can find some example on how program the
> mcc.
I downloaded some small code from motorola site and going through it.
>
> Be aware do not use the mcc with the silicon revision older than B.1.
I don't know how to do that yet.(I am very much new to embedded world)
Is it explained in motorola site? I came across checking the chip
version and the meaning of letters.
Thank you,
Om.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* (unknown),
From: Paresh Sawant @ 2002-12-13 5:02 UTC (permalink / raw)
To: linux-ide
unsubscribe linux-ide
^ permalink raw reply
* RE: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
From: Nakajima, Jun @ 2002-12-13 15:43 UTC (permalink / raw)
To: jamesclv, Nakajima, Jun, Zwane Mwaikambo
Cc: Martin Bligh, John Stultz, Linux Kernel
I/O APIC? I'm talking about xAPIC, i.e. local APIC which is part of the
chip. Also note that I/O subsystem can generate interrupts (e.g. MSI,
Message Signaled Interrupt), bypassing I/O APICs.
Jun
> -----Original Message-----
> From: James Cleverdon [mailto:jamesclv@us.ibm.com]
> Sent: Thursday, December 12, 2002 7:22 PM
> To: Nakajima, Jun; Zwane Mwaikambo
> Cc: Martin Bligh; John Stultz; Linux Kernel
> Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
>
> On Thursday 12 December 2002 07:05 pm, Nakajima, Jun wrote:
> > BTW, we are working on a xAPIC patch that supports more than 8 CPUs in a
> > generic fashion (don't use hardcode OEM checking). We already tested it
> on
> > two OEM systems with 16 CPUs.
> > - It uses clustered mode. We don't want to use physical mode because it
> > does not support lowest priority delivery mode.
> > - We also check the version of the local APIC if it's xAPIC or not. It's
> > possible that some other x86 architecture (other than P4P) uses xAPIC.
> >
> > Stay tuned.
> >
> > Jun
>
> See my 2.5 summit patch for one that uses logical mode and lowest priority
> delivery. I haven't submitted that for 2.4 because the physical patch has
> the most run time on it, both in Alan's tree and SuSE 8.0+.
>
> The hardcoded OEM checking was necessary because the Summit I/O APICs were
> still using the older version number. (The HW folks claim that Intel
> didn't
> specify the new number soon enough for them.)
>
> I'm hesitant to key xAPIC vs. flat off the local APIC version number
> because
> it's possible to build a flat system out of P4 CPUs. I/O APIC version
> numbers combined with the parallel vs. serial bit would be safer (except
> for
> the Summit problem above). I've also tried checking all the CPU's
> physical
> APIC IDs to see if they use multiple APIC clusters.
>
> > > -----Original Message-----
> > > From: James Cleverdon [mailto:jamesclv@us.ibm.com]
> > > Sent: Thursday, December 12, 2002 6:42 PM
> > > To: Zwane Mwaikambo
> > > Cc: Martin Bligh; John Stultz; Linux Kernel
> > > Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on
> !Summit
> > >
> > > On Thursday 12 December 2002 06:21 pm, Zwane Mwaikambo wrote:
> > > > On Thu, 12 Dec 2002, James Cleverdon wrote:
> > > > > On Thursday 12 December 2002 05:44 pm, Zwane Mwaikambo wrote:
> > > > > > Hi,
> > > > > > I've got an 32x SMP system which has an xAPIC but utilises
> > >
> > > flat
> > >
> > > > > > addressing. This patch is to rename what was formerly x86_summit
> to
> > > > > > x86_xapic (just to avoid confusion) and then select mask
> depending
> > >
> > > on
> > >
> > > > > > that.
> > > > > >
> > > > > > Untested/uncompiled patch
> > > > >
> > > > > Hi Zwane,
> > > > >
> > > > > How can you have a 32-way SMP system with flat addressing? There
> are
> > > > > only 8 bits in the destination address field. Even if you work
> > > > > around that by assigning a set of CPUs to each dest addr bit,
> there
> > > > > can only
> > >
> > > be
> > >
> > > > > 15 physical APIC IDs in flat mode. To get to 32 you must switch
> into
> > > > > clustered mode.
> > > > >
> > > > > Please tell me more. I'm intrigued how this can be done.
> > > >
> > > > Hi James,
> > > > with the xAPIC we can use the 8bit address space everywhere
in
> > > > physical destination mode. For example the ICR now has an 8bit space
> > > > for destination.
> > > >
> > > > "Specifies the target processor or processors. This field is only
> used
> > > > when the destination shorthand field is set to 00B. If the
> destination
> > > > mode is set to physical, then bits 56 through 59 contain the APIC ID
> of
> > > > the target processor for Pentium and P6 family processors and bits
> 56
> > > > through 63 contain the APIC ID of the target processor the for
> Pentium
> > > > 4 and Intel Xeon processors. If the destination mode is set to
> logical,
> > >
> > > the
> > >
> > > > interpretation of the 8-bit destination field depends on the
> settings
> > > > of the DFR and LDR registers of the local APICs in all the
> processors
> > > > in
> > >
> > > the
> > >
> > > > system (see Section 8.6.2., Determining IPI Destination )."
> > > > - System Developer's Manual vol3 p291
> > > >
> > > > Regards,
> > > > Zwane
> > >
> > > Sure you can physically address them, if you assign IDs using Intel's
> > > official
> > > xAPIC numbering scheme (which must be clustered for more than 7 CPUs).
> > > But,
> > > you still don't have enough destination address bits to go around. In
> > > flat
> > > mode, the kernel assumes you have one bit per CPU and phys IDs will be
> <
> > > 0xF.
> > >
> > > Bill tells me that you may be doing this for an emulator. Why not
> > > emulate clusered APIC mode, like the real hardware uses?
> > >
> > > I know the name x86_summit doesn't really fit. The summit patch
> should
> > > work
> > > for any xAPIC box that uses the system bus for interrupt delivery and
> has
> > > multiple APIC clusters. Is that what you're working towards?
> > >
> > > --
> > > James Cleverdon
> > > IBM xSeries Linux Solutions
> > > {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
>
>
> --
> James Cleverdon
> IBM xSeries Linux Solutions
> {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
^ permalink raw reply
* Re: 2.5.50-mm2
From: Christoph Hellwig @ 2002-12-13 22:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
In-Reply-To: <3DF453C8.18B24E66@digeo.com>
On Mon, Dec 09, 2002 at 12:26:48AM -0800, Andrew Morton wrote:
> +remove-PF_SYNC.patch
>
> remove the current->flags:PF_SYNC abomination. Adds a `sync' arg to
> all writepage implementations to tell them whether they are being
> called for memory cleansing or for data integrity.
Any chance you could pass down a struct writeback_control instead of
just the sync flag? XFS always used ->writepage similar to the
->vm_writeback in older kernel releases because writing out more
than one page of delalloc space is really needed to be efficient and
this would allow us to get a few more hints about the VM's intentions.
^ permalink raw reply
* Re: ospmd or acpid
From: Knut Neumann @ 2002-12-13 15:32 UTC (permalink / raw)
To: Matthew Tippett; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <3DF8A5CF.1000909@casero.com>
> Just a quick question regarding the user space daemons for ACPI. There
> is ospmd which is part of the acpi project, and there is acpid which is
> a seperate project which Andrew is a member of both.
Hmm...so what is your question? I assume you meant to ask which daemon to
use, so if thats right read on:
While acpid already reached version 1.0 and is quite ready to use, ospmd is
supposed to be better of the two but it is still under development - though
actually no one is really working on it. When its done it should replace not
only acpid but also apmd and it is thought to handle UPSes and other power
related devices as well.
-knut
-------------------------------------------------------
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/
^ permalink raw reply
* [PATCH] cciss/cpqarray/md should use generic BLKGETSIZE
From: Christoph Hellwig @ 2002-12-13 22:52 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
I did that already in 2.4.9/2.4.10 timeframe but it looks like a few
offenders started duplicating code again..
--- 1.27/drivers/block/cciss.c Wed Dec 4 01:00:00 2002
+++ edited/drivers/block/cciss.c Fri Dec 13 15:23:19 2002
@@ -468,16 +468,12 @@
return -EFAULT;
return(0);
}
- case BLKGETSIZE:
- put_user(hba[ctlr]->hd[MINOR(inode->i_rdev)].nr_sects, (unsigned long *)arg);
- return 0;
- case BLKGETSIZE64:
- put_user((u64)hba[ctlr]->hd[MINOR(inode->i_rdev)].nr_sects << 9, (u64*)arg);
- return 0;
case BLKRRPART:
if(!capable(CAP_SYS_ADMIN))
return -EPERM;
return revalidate_logvol(inode->i_rdev, 1);
+ case BLKGETSIZE:
+ case BLKGETSIZE64:
case BLKFLSBUF:
case BLKBSZSET:
case BLKBSZGET:
--- 1.26/drivers/block/cpqarray.c Mon Oct 28 16:18:57 2002
+++ edited/drivers/block/cpqarray.c Fri Dec 13 15:24:07 2002
@@ -1287,12 +1287,6 @@
case IDAGETDRVINFO:
return copy_to_user(&io->c.drv,&hba[ctlr]->drv[dsk],sizeof(drv_info_t));
- case BLKGETSIZE:
- if (!arg) return -EINVAL;
- return put_user(hba[ctlr]->hd[MINOR(inode->i_rdev)].nr_sects,
- (unsigned long *)arg);
- case BLKGETSIZE64:
- return put_user((u64)(hba[ctlr]->hd[MINOR(inode->i_rdev)].nr_sects) << 9, (u64*)arg);
case BLKRRPART:
return revalidate_logvol(inode->i_rdev, 1);
case IDAPASSTHRU:
@@ -1360,6 +1354,8 @@
return(0);
}
+ case BLKGETSIZE:
+ case BLKGETSIZE64:
case BLKFLSBUF:
case BLKBSZSET:
case BLKBSZGET:
--- 1.33/drivers/md/md.c Tue Aug 6 16:42:18 2002
+++ edited/drivers/md/md.c Fri Dec 13 15:24:42 2002
@@ -2610,21 +2610,8 @@
goto done;
#endif
- case BLKGETSIZE: /* Return device size */
- if (!arg) {
- err = -EINVAL;
- MD_BUG();
- goto abort;
- }
- err = md_put_user(md_hd_struct[minor].nr_sects,
- (unsigned long *) arg);
- goto done;
-
- case BLKGETSIZE64: /* Return device size */
- err = md_put_user((u64)md_hd_struct[minor].nr_sects << 9,
- (u64 *) arg);
- goto done;
-
+ case BLKGETSIZE:
+ case BLKGETSIZE64:
case BLKRAGET:
case BLKRASET:
case BLKFLSBUF:
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Matt Porter @ 2002-12-13 15:28 UTC (permalink / raw)
To: Tom Rini; +Cc: Cort Dougan, linuxppc-embedded
In-Reply-To: <20021213151808.GI19456@opus.bloom.county>
On Fri, Dec 13, 2002 at 08:18:08AM -0700, Tom Rini wrote:
>
> On Thu, Dec 12, 2002 at 09:51:26PM -0700, 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.
>
> One of my goals for winter break is to try and make the _devel tree less
> divergent, at least w.r.t. 'classic' PPCs. I'm not sure if 4xx support
> is in a stage yet that Paul is happy to move it to the _2_4 tree and
> then on to Marcelo yet.
At a minimum, the 4xx DBCR handling via thread struct would need to
be finished to make Paul happy, I believe. Luckily, I don't need
a debugger so I've had no reason to finish the task that he left
"as an exercise for the reader".
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Compilation problems with local APIC for uniprocessors in linux 2.4.20-ac2
From: Steffen Maier @ 2002-12-13 15:32 UTC (permalink / raw)
To: system_lists; +Cc: linux-kernel
In-Reply-To: <fa.frihumv.5jq19j@ifi.uio.no>
On Wed, 11 Dec 2002, system_lists@nullzone.org wrote:
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-ac2/include
> -I/usr/lib/gcc-lib/i386-linux/3.2.2/include -Wall -Wstrict-prototypes
> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
> -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix
> include -DKBUILD_BASENAME=mpparse -c -o mpparse.o mpparse.c
> mpparse.c:75: `dest_LowestPrio' undeclared here (not in a function)
> mpparse.c: In function `smp_read_mpc':
> mpparse.c:607: `dest_Fixed' undeclared (first use in this function)
> mpparse.c:607: (Each undeclared identifier is reported only once
> mpparse.c:607: for each function it appears in.)
> mpparse.c:607: `dest_LowestPrio' undeclared (first use in this function)
> make[1]: *** [mpparse.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4.20-ac2/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2
I just bumped into the same error using 2.4.20-ac1 and came up with the
appended short term fix.
HTH,
Steffen.
diff -ur linux-2.4.20-ac1_orig/arch/i386/kernel/mpparse.c linux-2.4.20-ac1/arch/i386/kernel/mpparse.c
--- linux-2.4.20-ac1_orig/arch/i386/kernel/mpparse.c Fri Dec 13 16:24:47 2002
+++ linux-2.4.20-ac1/arch/i386/kernel/mpparse.c Fri Dec 13 16:22:01 2002
@@ -28,6 +28,7 @@
#include <asm/mpspec.h>
#include <asm/pgalloc.h>
#include <asm/smpboot.h>
+#include <asm/io_apic.h>
/* Have we found an MP table */
int smp_found_config;
diff -ur linux-2.4.20-ac1_orig/include/asm/io_apic.h linux-2.4.20-ac1/include/asm/io_apic.h
--- linux-2.4.20-ac1_orig/include/asm/io_apic.h Fri Dec 13 16:24:39 2002
+++ linux-2.4.20-ac1/include/asm/io_apic.h Fri Dec 13 16:27:35 2002
@@ -47,17 +47,6 @@
extern int nr_ioapics;
extern int nr_ioapic_registers[MAX_IO_APICS];
-enum ioapic_irq_destination_types {
- dest_Fixed = 0,
- dest_LowestPrio = 1,
- dest_SMI = 2,
- dest__reserved_1 = 3,
- dest_NMI = 4,
- dest_INIT = 5,
- dest__reserved_2 = 6,
- dest_ExtINT = 7
-};
-
struct IO_APIC_route_entry {
__u32 vector : 8,
delivery_mode : 3, /* 000: FIXED
@@ -147,4 +136,15 @@
#define io_apic_assign_pci_irqs 0
#endif
+enum ioapic_irq_destination_types {
+ dest_Fixed = 0,
+ dest_LowestPrio = 1,
+ dest_SMI = 2,
+ dest__reserved_1 = 3,
+ dest_NMI = 4,
+ dest_INIT = 5,
+ dest__reserved_2 = 6,
+ dest_ExtINT = 7
+};
+
#endif
^ permalink raw reply
* oops in the 2.4.20-NFSALL sunrpc code
From: Ion Badulescu @ 2002-12-13 15:22 UTC (permalink / raw)
To: Trond Myklebust; +Cc: nfs
Hi Trond,
I'm running a locally concocted kernel, which is essentially RedHat's
2.4.18-18.7.x with the {nfs,nfsd,sunrpc} code replaced by the code in
2.4.20 + NFSALL + Neil's {001,006,008-015,022} patches from Nov 19. Neil's
patches don't touch the sunrpc code, except for patch 001 which only
changes an error path, so I'm pretty sure it's the changes in NFSALL that
cause the problem.
The problem:
Unable to handle kernel NULL pointer dereference at virtual address 00000058
printing eip:
c0967736
*pde = 00000000
Oops: 0000
nfs rocket nfsd lockd sunrpc autofs 3c59x nls_iso8859-1 isofs loop ext3 jbd
CPU: 0
EIP: 0010:[<c0967736>] Not tainted
EFLAGS: 00010202
EIP is at xprt_timer [sunrpc] 0x46 (2.4.18-18.7.x.lime2smp)
eax: 0000002c ebx: 00000000 ecx: 00000008 edx: 00000001
esi: 8655a074 edi: afe00340 ebp: 8655a000 esp: 80367ed0
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=80367000)
Stack: afe00340 c09676f0 00000000 00000000 c0968952 afe00340 afe00394 c09688d0
8012654a afe00340 80367f00 00000086 80367f00 80367f00 00000000 00000001
00000000 00000000 801227bb 803cf780 80122661 00000000 00000001 803ac100
Call Trace: [<c09676f0>] xprt_timer [sunrpc] 0x0 (0x80367ed4))
[<c0968952>] rpc_run_timer [sunrpc] 0x82 (0x80367ee0))
[<c09688d0>] rpc_run_timer [sunrpc] 0x0 (0x80367eec))
[<8012654a>] timer_bh [kernel] 0x29a (0x80367ef0))
[<801227bb>] bh_action [kernel] 0x4b (0x80367f18))
[<80122661>] tasklet_hi_action [kernel] 0x61 (0x80367f20))
[<801223eb>] do_softirq [kernel] 0x6b (0x80367f38))
[<8010a85e>] do_IRQ [kernel] 0xfe (0x80367f54))
[<8010d018>] call_do_IRQ [kernel] 0x5 (0x80367f6c))
[<801a38a3>] pr_power_idle [kernel] 0x113 (0x80367f98))
[<80106e60>] default_idle [kernel] 0x0 (0x80367fc4))
[<80105000>] stext [kernel] 0x0 (0x80367fc8))
[<80106ef4>] cpu_idle [kernel] 0x24 (0x80367fcc))
Code: 8b 40 2c 83 f8 09 0f 4c c8 b8 01 00 00 00 d3 e0 39 c2 7d 16
It's caused, from what I can tell, by task->tk_client being NULL in
xprt_timer() at the time it is dereferenced. Looks like a race condition,
probably facilitated by the SMP kernel.
The machine is a dual Athlon MP2100, and it was doing lots of NFS client
activity at the time it crashed. It's got 1GB of RAM, but I don't think
that's relevant.
The kernel is SMP and is compiled with a 2GB/2GB kernel/user address space
split, hence the kernel addresses starting with 8. Highmem support is
turned off.
If you (or anyone else) have any idea about how to fix this, I'd be really
grateful..
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-------------------------------------------------------
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
* Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103
From: Ducrot Bruno @ 2002-12-13 15:21 UTC (permalink / raw)
To: NoZizzing OrDripping
Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021213004316.39542.qmail-ugbtuMWqwv6A/QwVtaZbd3CJp6faPEW9@public.gmane.org>
On Thu, Dec 12, 2002 at 04:43:16PM -0800, NoZizzing OrDripping wrote:
>
> --- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > On Mon, Dec 09, 2002 at 10:59:22PM -0800, NoZizzing
> > OrDripping wrote:
> > >
> > > Status report for Toshiba Satellite 1115-S103
> > laptop....
> > >
> > > Just tried 2.4.20 + acpi-20021205-2.4.20.diff with
> > a Toshiba Satellite
> > > 1115-s103 laptop (new model, BIOS is "first
> > production release", dated
> > > 11/01/2002, street price is between $650 and
> > $1000, depending on
> > > rebates). Built it all-modular and with debug
> > messages.
> > > $ root modprobe ac; dmesg
> > >
> > > exfldio-0122 [31] Ex_setup_region : Field
> > [ACPW] Base+Offset+Width 38+0+4 is beyond end of
> > region [GPIO] (length 3B)
>
> > Known issue with most of the Toshiba Satellite
> > series with a Phoenix
> > BIOS. I guess that Toshiba (or in fact Compal)
> > still don't
> > know how to debug correctly their ASLs.
> >
> > You need a patched DSDT for this model.
>
> I don't believe that Toshiba/Microsoft will ever
> change their ways. This is a brand new model.
> However, it looks to me like I could easily make
> a kernel patch to add a CONFIG_ACPI_RELAXED
> configuration option that will allow these ASL
> mistakes, such as off-by-one on region size, to
> be accepted. That would allow people to use many
> broken DSDT's without having to go thru all of the
> trouble of the current method of DSDT overriding.
MS miss the check bounding in their AML interpreter, _but_
not in MS XP. Though, your new brand model could potentially
have the exact same problem with this OS as well. Really,
this up to Toshiba to debug their DSDT for their Satellites.
Actually, they have to cry to the real ODM, the real manufacturer
of allmost of their Satellite models, that is Compal.
(http://www.compal.com).
A 'real' Toshiba shipping a toshiba bios do not have this bug.
(it has others, but it was fixed by the help of FreeBSD team and
Intel)
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
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/
^ permalink raw reply
* Re: Symlink indirection
From: Richard B. Johnson @ 2002-12-13 15:30 UTC (permalink / raw)
To: Marc-Christian Petersen; +Cc: linux-kernel, Andrew Walrond
In-Reply-To: <200212131611.04355.m.c.p@wolk-project.de>
On Fri, 13 Dec 2002, Marc-Christian Petersen wrote:
> 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
No, that thing (whetever it is) is different.
Script started on Fri Dec 13 10:26:30 2002
# file *
foo: symbolic link to ../foo
typescript: empty
# pwd
/root/foo
# cd *
# cd *
# cd *
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# exit
exit
Script done on Fri Dec 13 10:27:21 2002
You can do this until you run out of string-space. Your "link-count"
has something to do with something else.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-13 15:18 UTC (permalink / raw)
To: Cort Dougan; +Cc: linuxppc-embedded
In-Reply-To: <20021212215126.V23952@duath.fsmlabs.com>
On Thu, Dec 12, 2002 at 09:51:26PM -0700, 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.
One of my goals for winter break is to try and make the _devel tree less
divergent, at least w.r.t. 'classic' PPCs. I'm not sure if 4xx support
is in a stage yet that Paul is happy to move it to the _2_4 tree and
then on to Marcelo yet.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-13 15:16 UTC (permalink / raw)
To: Gary Thomas; +Cc: Cort Dougan, linuxppc embedded
In-Reply-To: <1039789562.7542.14781.camel@hermes.chez-thomas.org>
On Fri, Dec 13, 2002 at 07:26:02AM -0700, Gary Thomas wrote:
> 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?
The _2_4_devel tree at the moment, since that still has generally better
infrastructure for non-pmacs :) I would also like to see a patch
against the current linuxppc-2.5 tree as well. It doesn't have to be as
well tested as the 2_4_devel version, and if the tree as a whole doesn't
compile at the time, make a/b/c.o is actually legal in 2.5 so just make
sure your changes still compile.
> * 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.
If you aren't already on the linuxppc-commit@source.mvista.com list, you
might want to join that. If a change makes it into any of the
linuxppc_* lists, a msg gets sent there. If you want to propose a
change cc relevant people (generally Paul and / or myself) and send it
to the linuxppc-dev and / or linuxppc-embedded lists. Someone will
speak up, even if it's only me to say I'm too busy today. :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Symlink indirection
From: Richard B. Johnson @ 2002-12-13 15:23 UTC (permalink / raw)
To: Andrew Walrond; +Cc: linux-kernel, libc-alpha
In-Reply-To: <3DF9F780.1070300@walrond.org>
On Fri, 13 Dec 2002, Andrew Walrond wrote:
> 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
>
Since a symlink is just a file containing a name, the resulting path
length is simply the maximum path length that user-space tools allow.
This should be defined as "PATH_MAX". Posix defines this as 255 characters
but I think posix requires that this be the minimum and all file-name
handling buffers must be at least PATH_MAX in length.
A hard link is just another directory-entry for the same file. This,
therefore follows the same rules. There must be enough space on the
device to contain the number of directory entries, as well as enough
buffer length in the tools necessary to manipulate these "nested"
directories, which are not really "nested" at all.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-13 15:20 UTC (permalink / raw)
To: Marc-Christian Petersen; +Cc: linux-kernel
In-Reply-To: <200212131611.04355.m.c.p@wolk-project.de>
Thanks Marc
5 is very low isn't it? Certainly marginal for an application I have in
mind.
What's the reasoning behind it being a) 5 and b) so low?
Marc-Christian Petersen wrote:
> 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]Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-13 15:10 UTC (permalink / raw)
To: Alan Cox; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <1039641154.18412.28.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
On Среда 11 Декабрь 2002 13:12, Alan Cox wrote:
> On Wed, 2002-12-11 at 19:42, Fedor Karpelevitch wrote:
> > So I wonder what toggling those bits is supposed to change. I
> > would test that somehow then
>
> 6 channel audio mode
so here is the patch against 2.4.21-pre1 (I beleive it should equally
apply to 20-ac2)
It works for me and fixes all four occurences of that error in the
driver.
Fedor
[-- Attachment #2: patch-tridfix.txt --]
[-- Type: text/plain, Size: 1480 bytes --]
--- linux-2.4.21-pre1-tridfix/drivers/sound/trident.c.orig 2002-12-12 15:28:00.000000000 -0800
+++ linux-2.4.21-pre1-tridfix/drivers/sound/trident.c 2002-12-12 15:30:48.000000000 -0800
@@ -3368,15 +3368,17 @@
pci_dev = pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
- pci_write_config_byte(pci_dev, 0x59, ~temp);
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp &= ~0x80;
+ pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
- pci_write_config_byte(pci_dev, 0xB8, ~temp);
+ pci_read_config_byte(pci_dev, 0xB8, &temp);
+ temp &= ~0x20;
+ pci_write_config_byte(pci_dev, 0xB8, temp);
return 0;
}
@@ -3390,13 +3392,15 @@
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp |= 0x80;
pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
+ pci_read_config_byte(pci_dev, (int)0xB8, &temp);
+ temp |= 0x20;
pci_write_config_byte(pci_dev, (int)0xB8,(u8) temp);
if (chan_nums == 6) {
dwValue = inl(TRID_REG(card, ALI_SCTRL)) | 0x000f0000;
^ permalink raw reply
* Re: procps 2.x vs. procps 3.x
From: Albert D. Cahalan @ 2002-12-13 15:14 UTC (permalink / raw)
To: linux-kernel; +Cc: lostlogic, acahalan
Brandon Low writes:
> Well at Gentoo, we are kinda using both right now. We've noticed
> some querkiness with the 3.x series where TOP will miss certain
> characters in output,
If nobody else knows about it, it's not too likely to get fixed.
Send bug reports to procps-feedback@lists.sf.net please.
Before you do: "certain characters" will need some explaining.
(position? value? completely gone or turned into a space?)
> but the 3.x series is much prettier and
> feature rich than the 2.x series. On the other hand, 2.x is
> consistently more up to date with kernel changes since RML and Riel
> maintain it and are intimately familiar with current kernel
> development.
I just got the last bit, /proc/*/wchan usage on 2.5.xx kernels.
Oddly, I'm ahead right now. I have a vmstat that uses a fast O(1)
algorithm on 2.5.xx kernels and reports the IO-wait time. I also
have a sysctl that handles the 2.5.xx VLAN interfaces.
^ permalink raw reply
* [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
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.