* FAQ submission with answer
From: Duane Ellis @ 2002-10-26 17:22 UTC (permalink / raw)
To: trmcneal, nfs
I have a "FAQ" question and at least
an Answer or work around for the problem.
I hope this helps others on this list
(I am not on the nfs list)
I am an administer a fairly large
Unix network ( +50 SunOS boxes, and +20 linux boxes)
and have hit this problem a few times when
configuring a new linux machine.
I am trying to export "/" (root) file system
from one linux box to all others via the
the directory construct:
# cd /net/HOSTNAME/filesystem
When I run the exportfs command, I got a cryptic
message that did not help what so ever.
# exportfs -ra
europa:/: Invalid argument
Manytimes this is mis-diagnosted as a condition
where you are exporting a sub-directory of an
already exported file system - That's not my
problem.
Specifically my problem is this:
The file /var/lib/nfs/rmtab had a stale
entry in it.
Specifically to fix my problem I had to do this:
# [stop nfs]
# cd /var/lib/nfs
# rm -f etab mtab rmtab
# touch rmtab
[otherwise exportfs complains]
# [start nfs]
A better answer would be to explain or fix why
the file /var/lib/nfs/rmtab had the stale entry
or to fix what ever updates the file.
Perhaps this is a latent bug that is inside of NFS or
one of the other utlities, or maybe these files
should be removed during a reboot as part of some
type of 'house-cleaning' operation.
It appears that a fix was offered to this problem
in this posting, but it has ether not picked up
or not trickled through to all the various distros.
http://sourceforge.net/mailarchive/message.php?msg_id=553411
look for:
>> # First we should cleanup and then prepare our exports.
> /var/lib/nfs/etab #
> /var/lib/nfs/xtab # contains list of exportable filesystems
>> /var/lib/nfs/rmtab # list of used exported filesystems
Thanks.
-Duane Ellis
Others have seen this problem too:
http://sourceforge.net/mailarchive/message.php?msg_id=1228515
http://sourceforge.net/mailarchive/message.php?msg_id=550491
It appears that a fix was offered to this problem
in this posting:
http://sourceforge.net/mailarchive/message.php?msg_id=553411
look for:
>> # First we should cleanup and then prepare our exports.
> /var/lib/nfs/etab #
> /var/lib/nfs/xtab # contains list of exportable filesystems
>> /var/lib/nfs/rmtab # list of used exported filesystems
http://www.geocrawler.com/archives/3/789/2001/8/50/6372419/
http://www.cs.helsinki.fi/linux/linux-kernel/2002-01/0811.html
https://listman.redhat.com/pipermail/wolverine-list/2001-March/001096.html
http://plug.skylab.org/199906/msg00469.html
http://www.van-dijk.net/linuxkernel/200202/0583.html.gz
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Was: Trying to get GUI'ed
From: Bryan Simmons @ 2002-10-26 17:11 UTC (permalink / raw)
To: John E. Jay Maass; +Cc: linux-newbie
In-Reply-To: <20021026110108.EOTG9549.out019.verizon.net@[127.0.0.1]>
didn't mean to sound condescending. I was just trying to add to the
point of importance of RAM. Virtual memory makes it so that you can
address MORE RAM than you physically have. It has many other benefits
as well. But it goes without saying that the more RAM you have, the
better. When I first installed Mandrake 9.0, I ran it for 2 months
without using any swap space. I have 512MB RAM. I don't intend to
screw around with performance. Hell, I'd use a gig or more if I thought
it wasn't overkill for my applications...
On Sat, 2002-10-26 at 07:01, John E. Jay Maass wrote:
> Bryan Simmons <bsimmo1@gl.umbc.edu> writes:
>
> > Think that was informative? Learn assembly on x86 Linux.
> > You have NO idea what a computer goes through just to add
> > two numbers, let alone manage network traffic... The most
> > shocking part is the idea of virtual memory.
>
> Bryan,
>
> I thought my little RAM thing was informative, yeah. It was
> intended as practical, nothing esoteric or high minded. About
> assembly language, a friend of mine worked with it and I took
> a peek. I would love to know a little assembly. What I read
> of it was impossible for me to grasp. Somehow I get by. With
> great perseverance I manage to eventually grasp a little of
> what others take for granted. Certainly nothing like assembly,
> though <grins>.
>
> All best,
> Jay
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
--
Bryan Simmons <bsimmo1@gl.umbc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: 2.5.44-ac3 usb audio - illegal sleep call
From: Greg KH @ 2002-10-26 17:11 UTC (permalink / raw)
To: Kevin Brosius; +Cc: kernel
In-Reply-To: <3DBAA320.B02AB7FC@compuserve.com>
On Sat, Oct 26, 2002 at 10:13:52AM -0400, Kevin Brosius wrote:
> I've been trying to get USB up to test a audio device and just managed
> to get it all working to some extent. When using xmms to play audio
> (usb audio module - oss soundcore) I see the following kernel messages
> repeatedly, maybe once a second or so:
Can you try this patch and let us know if it fixes your problem?
thanks,
greg k-h
===== drivers/usb/class/audio.c 1.43 vs edited =====
--- 1.43/drivers/usb/class/audio.c Fri Oct 18 21:31:28 2002
+++ edited/drivers/usb/class/audio.c Sat Oct 26 10:22:43 2002
@@ -914,7 +914,7 @@
if (!usbin_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
!usbin_prepare_desc(u, urb) &&
- (suret = usb_submit_urb(urb, GFP_KERNEL)) == 0) {
+ (suret = usb_submit_urb(urb, GFP_ATOMIC)) == 0) {
u->flags |= mask;
} else {
u->flags &= ~(mask | FLG_RUNNING);
@@ -1274,7 +1274,7 @@
if (!usbout_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
!usbout_prepare_desc(u, urb) &&
- (suret = usb_submit_urb(urb, GFP_KERNEL)) == 0) {
+ (suret = usb_submit_urb(urb, GFP_ATOMIC)) == 0) {
u->flags |= mask;
} else {
u->flags &= ~(mask | FLG_RUNNING);
^ permalink raw reply
* Re: [parisc-linux] Branch Prediction
From: John David Anglin @ 2002-10-26 17:05 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
In-Reply-To: <20021026051138.248F24834@dsl2.external.hp.com>
> "John David Anglin" wrote:
> > Does anyone know which PA processors if any implement the BTS?
>
> No clue. I had to read the PA2.0 arch book (page 6-15, "Branch
> Target Stack) to learn what this is and what it does.
I did a quick hack to gcc yesterday to try it on the a500. It
didn't seem to make any difference, so I think the PA-8500 doesn't
have a branch target stack. I wonder if the PA-8700 in the rp2470
has it? I suppose it also could be an add-on chip.
It's fairly easy to implement and the assembler already supports
the feature. However, there might be issues with software compiled
without the feature not inter-operating with software compiled
with it. For call-return acceleration, the safe solution of
pushing the return in the callee results in reduced performance.
You have to do the push in the call. Maybe I will add this
as an option if there is actually some gear that has the option.
> Anyay, it would be interesting to know if HPUX's acc uses it.
> ie did it's usage ever get validated for both systems that do
> and don't implement BTS?
>
> > I was also wondering about the ITLB P bit and what parisc-linux does
> > with it. The came up in regard to accelerating branches for calls
> > and returns.
>
> It sounds like parisc-linux does nothing with P-bit.
> We could just always enable it if you think that's the right
> thing to do for now. Looks like could be done by adding one more
> insn to itlb_miss_common_20w in entry.S.
I am guessing but I think setting it would help on machines with
dynamic prediction hardware. There is probably a paper somewhere
on this on the HP site. I tried to find info on the branch target
stack but didn't have any success.
My understanding is that pc-relative branches can be predicted
from examination of the code. Indirect branches (e.g., call
returns) can't. I don't know how the dynamic prediction hardware
works but I would think it wouldn't be there if it didn't
improve branch prediction.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Re: 2.5.44-ac3 usb audio - illegal sleep call
From: Oliver Neukum @ 2002-10-26 17:02 UTC (permalink / raw)
To: Kevin Brosius, kernel
In-Reply-To: <3DBAA320.B02AB7FC@compuserve.com>
Am Samstag, 26. Oktober 2002 16:13 schrieb Kevin Brosius:
> I've been trying to get USB up to test a audio device and just managed
> to get it all working to some extent. When using xmms to play audio
> (usb audio module - oss soundcore) I see the following kernel messages
> repeatedly, maybe once a second or so:
Go edit usbout_completed() and usbin_completed(). Change the GFP_KERNEL
in usb_submit_urb to GFP_ATOMIC.
Does that help ?
Regards
Oliver
^ permalink raw reply
* Pinging a IP , how to stop it bringing diald live
From: Sean Rima @ 2002-10-26 16:55 UTC (permalink / raw)
To: linux-diald
In-Reply-To: <3DBAB558.30408@sympatico.ca>
Originally to: Mark Frey
Hello Mark.
26 Oct 02 11:31, you wrote to all:
MF> Hi Sean,
MF> Try putting this near the top of your standard.filter file, or the
MF> file where you're defining your rules:
MF> ignore icmp ip.daddr=ip.address.to.ignore
Thanks Mark, that is it :)
Sean
--- GoldED+/LNX 1.1.5
^ permalink raw reply
* Re: [LARTC] can anyone help me to solve this problem?
From: Werner Almesberger @ 2002-10-26 16:49 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103555834517971@msgid-missing>
Folke Aeon wrote:
> it works currently, but wonder whether there will be
> any negative influence or not. would you please give
> some comment on this ?
It should work. You just have to be aware that your kernel
is doing some odd things ...
> another thing, i noticed that since the dsmark dequeue
> function does not support mpls protocol, so when a mpls
> packet arrives, it complains "unsupported protocol".
Only if you try to change the DS field.
> Although the tcindex value is still there, it just cannot
> use it . i think this is where the problem lies in.
No. tc_index does not have to equal the DSCP or DS field.
In dsmark, tc_index is an index to a table with DS field
changes. All you need to do is to reserve a tc_index value
for non-IP traffic, and only mark IP traffic with other
values than that.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH] use 64 bit jiffies for exported values
From: Tim Schmielau @ 2002-10-26 16:51 UTC (permalink / raw)
To: lkml; +Cc: Dave Jones
Now that we have HZ=1000 even on 32bit platforms, we really should
use the 64 bit jiffies value for exported interfaces like uptime, process
start time etc. Otherwise innocent users might get quite surprised
when ps output goes berzerk after 49.5 days.
Note that the appended patch does not change any of the exported
interfaces, it just avoids internal overflows.
This patch has been in -dj (modulo the HZ=1000 change) since 2.5.20-dj3.
I just forward ported it from 2.5.39-dj1 to 2.5.44, and renamed
jiffies_64_to_clock_t() to jiffies_64_to_user_HZ().
A version that additionally bumps up kstat.per_cpu_... counters to 64 bit
can be found at
http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-27.patch.gz
I believe this counts as a bugfix (it fixes a regression from 2.4), but
still I wanted to put it out before the feature freeze deadline.
Tim
--- linux-2.5.44/kernel/timer.c Sat Oct 19 06:01:19 2002
+++ linux-2.5.44-j64/kernel/timer.c Sat Oct 26 13:21:02 2002
@@ -24,8 +24,10 @@
#include <linux/percpu.h>
#include <linux/init.h>
#include <linux/mm.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
+#include <asm/div64.h>
/*
* per-CPU timer vector definitions:
@@ -1001,13 +1003,16 @@
asmlinkage long sys_sysinfo(struct sysinfo *info)
{
struct sysinfo val;
+ u64 uptime;
unsigned long mem_total, sav_total;
unsigned int mem_unit, bitcount;
memset((char *)&val, 0, sizeof(struct sysinfo));
read_lock_irq(&xtime_lock);
- val.uptime = jiffies / HZ;
+ uptime = jiffies_64;
+ do_div(uptime, HZ);
+ val.uptime = (unsigned long) uptime;
val.loads[0] = avenrun[0] << (SI_LOAD_SHIFT - FSHIFT);
val.loads[1] = avenrun[1] << (SI_LOAD_SHIFT - FSHIFT);
--- linux-2.5.44/include/linux/jiffies.h Sat Oct 19 06:01:08 2002
+++ linux-2.5.44-j64/include/linux/jiffies.h Sat Oct 26 13:00:11 2002
@@ -2,14 +2,34 @@
#define _LINUX_JIFFIES_H
#include <linux/types.h>
+#include <linux/spinlock.h>
+#include <asm/system.h>
#include <asm/param.h> /* for HZ */
/*
* The 64-bit value is not volatile - you MUST NOT read it
- * without holding read_lock_irq(&xtime_lock)
+ * without holding read_lock_irq(&xtime_lock).
+ * get_jiffies_64() will do this for you as appropriate.
*/
extern u64 jiffies_64;
extern unsigned long volatile jiffies;
+
+static inline u64 get_jiffies_64(void)
+{
+#if BITS_PER_LONG < 64
+ extern rwlock_t xtime_lock;
+ unsigned long flags;
+ u64 tmp;
+
+ read_lock_irqsave(&xtime_lock, flags);
+ tmp = jiffies_64;
+ read_unlock_irqrestore(&xtime_lock, flags);
+ return tmp;
+#else
+ return (u64)jiffies;
+#endif
+}
+
/*
* These inlines deal with timer wrapping correctly. You are
--- linux-2.5.44/fs/proc/array.c Sat Oct 19 06:01:59 2002
+++ linux-2.5.44-j64/fs/proc/array.c Sat Oct 26 13:00:11 2002
@@ -344,7 +344,7 @@
ppid = task->pid ? task->real_parent->pid : 0;
read_unlock(&tasklist_lock);
res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
-%lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \
+%lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
task->pid,
task->comm,
@@ -367,7 +367,7 @@
nice,
0UL /* removed */,
jiffies_to_clock_t(task->it_real_value),
- jiffies_to_clock_t(task->start_time),
+ (unsigned long long) jiffies_64_to_user_HZ(task->start_time),
vsize,
mm ? mm->rss : 0, /* you might want to shift this left 3 */
task->rlim[RLIMIT_RSS].rlim_cur,
--- linux-2.5.44/fs/proc/proc_misc.c Sat Oct 19 06:01:14 2002
+++ linux-2.5.44-j64/fs/proc/proc_misc.c Sat Oct 26 13:16:34 2002
@@ -39,12 +39,14 @@
#include <linux/seq_file.h>
#include <linux/times.h>
#include <linux/profile.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
#include <asm/io.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
+#include <asm/div64.h>
#define LOAD_INT(x) ((x) >> FSHIFT)
#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
@@ -97,34 +99,36 @@
static int uptime_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
- unsigned long uptime;
- unsigned long idle;
+ u64 uptime;
+ unsigned long uptime_remainder;
int len;
- uptime = jiffies;
- idle = init_task.utime + init_task.stime;
+ uptime = get_jiffies_64();
+ uptime_remainder = (unsigned long) do_div(uptime, HZ);
- /* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
- that would overflow about every five days at HZ == 100.
- Therefore the identity a = (a / b) * b + a % b is used so that it is
- calculated as (((t / HZ) * 100) + ((t % HZ) * 100) / HZ) % 100.
- The part in front of the '+' always evaluates as 0 (mod 100). All divisions
- in the above formulas are truncating. For HZ being a power of 10, the
- calculations simplify to the version in the #else part (if the printf
- format is adapted to the same number of digits as zeroes in HZ.
- */
#if HZ!=100
- len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
- uptime / HZ,
- (((uptime % HZ) * 100) / HZ) % 100,
- idle / HZ,
- (((idle % HZ) * 100) / HZ) % 100);
+ {
+ u64 idle = init_task.utime + init_task.stime;
+ unsigned long idle_remainder;
+
+ idle_remainder = (unsigned long) do_div(idle, HZ);
+ len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
+ (unsigned long) uptime,
+ (uptime_remainder * 100) / HZ,
+ (unsigned long) idle,
+ (idle_remainder * 100) / HZ);
+ }
#else
- len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
- uptime / HZ,
- uptime % HZ,
- idle / HZ,
- idle % HZ);
+ {
+ unsigned long idle = init_task.times.tms_utime
+ + init_task.times.tms_stime;
+
+ len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
+ (unsigned long) uptime,
+ uptime_remainder,
+ idle / HZ,
+ idle % HZ);
+ }
#endif
return proc_calc_metrics(page, start, off, count, eof, len);
}
@@ -320,6 +324,8 @@
};
#endif
+extern rwlock_t xtime_lock;
+
extern struct seq_operations slabinfo_op;
extern ssize_t slabinfo_write(struct file *, const char *, size_t, loff_t *);
static int slabinfo_open(struct inode *inode, struct file *file)
@@ -339,8 +345,9 @@
{
int i, len;
extern unsigned long total_forks;
- unsigned long jif = jiffies;
- unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0;
+ u64 jif = get_jiffies_64();
+ unsigned int sum = 0;
+ unsigned long user = 0, nice = 0, system = 0, idle = 0, iowait = 0;
int major, disk;
for (i = 0 ; i < NR_CPUS; i++) {
@@ -358,7 +365,7 @@
#endif
}
- len = sprintf(page, "cpu %u %u %u %u %u\n",
+ len = sprintf(page, "cpu %lu %lu %lu %lu %lu\n",
jiffies_to_clock_t(user),
jiffies_to_clock_t(nice),
jiffies_to_clock_t(system),
@@ -366,7 +373,7 @@
jiffies_to_clock_t(iowait));
for (i = 0 ; i < NR_CPUS; i++){
if (!cpu_online(i)) continue;
- len += sprintf(page + len, "cpu%d %u %u %u %u %u\n",
+ len += sprintf(page + len, "cpu%d %lu %lu %lu %lu %lu\n",
i,
jiffies_to_clock_t(kstat.per_cpu_user[i]),
jiffies_to_clock_t(kstat.per_cpu_nice[i]),
@@ -401,12 +408,13 @@
}
}
+ do_div(jif, HZ);
len += sprintf(page + len,
"\nctxt %lu\n"
"btime %lu\n"
"processes %lu\n",
nr_context_switches(),
- xtime.tv_sec - jif / HZ,
+ xtime.tv_sec - (unsigned long) jif,
total_forks);
return proc_calc_metrics(page, start, off, count, eof, len);
--- linux-2.5.44/include/linux/kernel_stat.h Sat Oct 19 06:01:50 2002
+++ linux-2.5.44-j64/include/linux/kernel_stat.h Sat Oct 26 13:19:09 2002
@@ -16,11 +16,11 @@
#define DK_MAX_DISK 16
struct kernel_stat {
- unsigned int per_cpu_user[NR_CPUS],
- per_cpu_nice[NR_CPUS],
- per_cpu_system[NR_CPUS],
- per_cpu_idle[NR_CPUS],
- per_cpu_iowait[NR_CPUS];
+ unsigned long per_cpu_user[NR_CPUS],
+ per_cpu_nice[NR_CPUS],
+ per_cpu_system[NR_CPUS],
+ per_cpu_idle[NR_CPUS],
+ per_cpu_iowait[NR_CPUS];
unsigned int dk_drive[DK_MAX_MAJOR][DK_MAX_DISK];
unsigned int dk_drive_rio[DK_MAX_MAJOR][DK_MAX_DISK];
unsigned int dk_drive_wio[DK_MAX_MAJOR][DK_MAX_DISK];
--- linux-2.5.44/include/linux/sched.h Sat Oct 19 06:01:11 2002
+++ linux-2.5.44-j64/include/linux/sched.h Sat Oct 26 13:00:11 2002
@@ -334,7 +334,7 @@
unsigned long it_real_incr, it_prof_incr, it_virt_incr;
struct timer_list real_timer;
unsigned long utime, stime, cutime, cstime;
- unsigned long start_time;
+ u64 start_time;
long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
--- linux-2.5.44/include/linux/times.h Sat Oct 19 06:01:09 2002
+++ linux-2.5.44-j64/include/linux/times.h Sat Oct 26 13:00:11 2002
@@ -2,7 +2,16 @@
#define _LINUX_TIMES_H
#ifdef __KERNEL__
+#include <asm/div64.h>
+#include <asm/types.h>
+
# define jiffies_to_clock_t(x) ((x) / (HZ / USER_HZ))
+
+static inline u64 jiffies_64_to_user_HZ(u64 x)
+{
+ do_div(x, HZ / USER_HZ);
+ return x;
+}
#endif
struct tms {
--- linux-2.5.44/kernel/acct.c Sat Oct 19 06:01:56 2002
+++ linux-2.5.44-j64/kernel/acct.c Sat Oct 26 13:00:11 2002
@@ -49,7 +49,9 @@
#include <linux/acct.h>
#include <linux/file.h>
#include <linux/tty.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
+#include <asm/div64.h>
/*
* These constants control the amount of freespace that suspend and
@@ -304,6 +306,7 @@
mm_segment_t fs;
unsigned long vsize;
unsigned long flim;
+ u64 elapsed;
/*
* First check to see if there is enough free_space to continue
@@ -321,9 +324,11 @@
strncpy(ac.ac_comm, current->comm, ACCT_COMM);
ac.ac_comm[ACCT_COMM - 1] = '\0';
- ac.ac_btime = CT_TO_SECS(current->start_time) +
- (xtime.tv_sec - (jiffies / HZ));
- ac.ac_etime = encode_comp_t(jiffies - current->start_time);
+ elapsed = get_jiffies_64() - current->start_time;
+ ac.ac_etime = encode_comp_t(elapsed < (unsigned long) -1l ?
+ (unsigned long) elapsed : (unsigned long) -1l);
+ do_div(elapsed, HZ);
+ ac.ac_btime = xtime.tv_sec - elapsed;
ac.ac_utime = encode_comp_t(current->utime);
ac.ac_stime = encode_comp_t(current->stime);
ac.ac_uid = current->uid;
--- linux-2.5.44/kernel/fork.c Sat Oct 19 06:01:11 2002
+++ linux-2.5.44-j64/kernel/fork.c Sat Oct 26 13:00:11 2002
@@ -26,6 +26,7 @@
#include <linux/mman.h>
#include <linux/fs.h>
#include <linux/security.h>
+#include <linux/jiffies.h>
#include <linux/futex.h>
#include <linux/ptrace.h>
@@ -766,7 +767,7 @@
#endif
p->array = NULL;
p->lock_depth = -1; /* -1 = no lock */
- p->start_time = jiffies;
+ p->start_time = get_jiffies_64();
p->security = NULL;
INIT_LIST_HEAD(&p->local_pages);
--- linux-2.5.44/mm/oom_kill.c Sat Oct 19 06:01:56 2002
+++ linux-2.5.44-j64/mm/oom_kill.c Sat Oct 26 13:00:11 2002
@@ -19,6 +19,7 @@
#include <linux/sched.h>
#include <linux/swap.h>
#include <linux/timex.h>
+#include <linux/jiffies.h>
/* #define DEBUG */
@@ -68,11 +69,10 @@
/*
* CPU time is in seconds and run time is in minutes. There is no
* particular reason for this other than that it turned out to work
- * very well in practice. This is not safe against jiffie wraps
- * but we don't care _that_ much...
+ * very well in practice.
*/
cpu_time = (p->utime + p->stime) >> (SHIFT_HZ + 3);
- run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);
+ run_time = (get_jiffies_64() - p->start_time) >> (SHIFT_HZ + 10);
points /= int_sqrt(cpu_time);
points /= int_sqrt(int_sqrt(run_time));
^ permalink raw reply
* Re: [LARTC] Problem with fw filters
From: Aigars Mahinovs @ 2002-10-26 16:44 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103563976509242@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Hello,
On 26 Oct 2002 18:06:17 +0200, Martin Josefsson <gandalf@wlug.westbo.se>
wrote:
> > iptables -t mangle -A OUTPUT -j MARK --set-mark 666
>
> This won't work the way you want it to.
> MARK doesn't terminate the rule-traversal... so all packets will be
> marked as 666 in the end.
Thanks, that worked.
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------#
| .''`. |
| : :' : Debian GNU/Linux |
| `. `' http://www.debian.org |
| `- |
#--------------------------------------------------#
[-- Attachment #2: Type: application/pgp-signature, Size: 831 bytes --]
^ permalink raw reply
* [parisc-linux] SQUID failled :(
From: Joel Soete @ 2002-10-26 17:50 UTC (permalink / raw)
To: parisc-linux
Hi all,
Is somebody reach to make squid running on a woody pa-box?
I install it (to replace a old pentium 100Mhz box).
Well it start some second(s) then stop without any message anywhere
(even if I start it with -X)?
The check of the config file is ok!
Thanks in advance for all adivise,
Joel
PS: the running kernel is the last 2.4.19-pa22 32bits dpkg released (for
the rest all is woody)
^ permalink raw reply
* Re: 2.5.44: Still has KVM + Mouse issues
From: Jon Grimm @ 2002-10-26 16:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <p738z0lu2dl.fsf@oldwotan.suse.de>
Thanks Andi,
The workaround sounds reasonable.
-jon
Andi Kleen wrote:
> Boot with psmouse_noext, that should fix it. It runs the intellimouse as a
> plain PS/2 mouse. You lose the additional mouse buttons and the scroll wheel,
> but they never worked through that KVM anyways.
>
> -Andi
>
^ permalink raw reply
* Re: [LARTC] can anyone help me to solve this problem?
From: Werner Almesberger @ 2002-10-26 16:37 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103555834517971@msgid-missing>
Folke Aeon wrote:
> can IMQ classify packets based on their RATE and BURST ?
> if it cannot , then it wouldn't do any help to me . :(
I haven't used IMQ myself, but I'd expect it to work with
policing, etc., like everywhere else, yes.
>>(Well, or fix MPLS to preserve skb->tc_index.)
>
> to be frank i am not quite familiar with this stuff.
> i just do everything according to the installation guide
> shipped with the mpls-patch downloaded at sf.net/mpls-linux/ :(
I suppose, on
http://lists.sourceforge.net/lists/listinfo/mpls-linux-general
they could help you, if you described the problem.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
From: Joel Soete @ 2002-10-26 17:39 UTC (permalink / raw)
To: jsoe0708; +Cc: Randolph Chung, Stefan Pfetzing, parisc-linux
In-Reply-To: <3DB5776100000C32@ocpmta8.be.tiscali.com>
Hmm question about "default:" uaccess.h implementation on different
platform:
i386 declare: "extern void __get_user_bad(void);"
ia64: "extern void __get_user_unknown (void);"
mips: "extern void __get_user_unknown(void);"
...
but not define elsewhere? (is it there so that the build of the kernel
failed if that case was requested to run properly?)
Thanks in advance for attention,
Joel
PS: afaik on i386 only put_user_u64 is define why not pending get_user?
jsoe0708@tiscali.be wrote:
> too bad:
>
> man ioctl advise that it would return -1 (not ENOTSUP which would be assign
> to errno) I will try to see how?
>
> Sorry to annoy,
> Joel
>
>
>>-- Original Message --
>>From: jsoe0708@tiscali.be
>>Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
>>To: "Randolph Chung" <randolph@tausq.org>,
>> "Stefan Pfetzing" <dreamind@dreamind.de>
>>Cc: parisc-linux@lists.parisc-linux.org
>>Date: Fri, 25 Oct 2002 14:58:42 +0200
>>
>>
>>Hi Randolph,
>>
>>It sure I found a bug in the two parts kernel and xfs.
>>
>>A. The kernel hppa: put_user and get_user does just a printk for BUG messages
>>but don't return error code as ENOTSUP (or what else) (what I assume the
>>other platforms does when they do not yet support BLKGETSIZE64?)
>>
>>Here is a small patch I suggest:
>>(I do not reach to implement an operational support of BLKGETSIZE64 [for
>>32bits kernel]; I do not find a easy way to manage code failure :-( )
>>
>>--- uaccess.h.orig 2002-10-22 15:14:54.000000000 +0200
>>+++ uaccess.h 2002-10-23 13:46:48.000000000 +0200
>>@@ -35,10 +35,10 @@
>>#define get_user __get_user
>>
>>#if BITS_PER_LONG == 32
>>-#define LDD_KERNEL(ptr) BUG()
>>-#define LDD_USER(ptr) BUG()
>>-#define STD_KERNEL(x, ptr) BUG()
>>-#define STD_USER(x, ptr) BUG()
>>+#define LDD_KERNEL(ptr) BUG(); __gu_err=ENOTSUP;
>>+#define LDD_USER(ptr) BUG(); __gu_err=ENOTSUP;
>>+#define STD_KERNEL(x, ptr) BUG(); __pu_err=ENOTSUP;
>>+#define STD_USER(x, ptr) BUG(); __pu_err=ENOTSUP;
>>#else
>>#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>>#define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>>@@ -75,7 +75,7 @@
>> case 2: __get_kernel_asm("ldh",ptr); break; \
>> case 4: __get_kernel_asm("ldw",ptr); break; \
>> case 8: LDD_KERNEL(ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __gu_err=ENOTSUP; break; \
>> } \
>> } \
>> else { \
>>@@ -84,7 +84,7 @@
>> case 2: __get_user_asm("ldh",ptr); break; \
>> case 4: __get_user_asm("ldw",ptr); break; \
>> case 8: LDD_USER(ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __gu_err=ENOTSUP; break; \
>> } \
>> } \
>> \
>>@@ -144,7 +144,7 @@
>> case 2: __put_kernel_asm("sth",x,ptr); break; \
>> case 4: __put_kernel_asm("stw",x,ptr); break; \
>> case 8: STD_KERNEL(x,ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __pu_err=ENOTSUP; break; \
>> } \
>> } \
>> else { \
>>@@ -153,7 +153,7 @@
>> case 2: __put_user_asm("sth",x,ptr); break; \
>> case 4: __put_user_asm("stw",x,ptr); break; \
>> case 8: STD_USER(x,ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __pu_err=ENOTSUP; break; \
>> } \
>> } \
>> \
>>
>>If all agreed, (awaiting better :?) can somebody ci it?
>>
>>
>>Thanks in advance for attention,
>> Joel
>>
>>PS:
>>B. in xfs:
>>
>> error = ioctl(fd, BLKGETSIZE64, &size);
>>- if (error >= 0) {
>>+ if (!error) {
>> /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>
>>AFAIK ioctl should return error=0 if success and error <>0 (>0?)
>>
>>here is the full patch I will suggest:
>>
>>--- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200
>>+++ cmd/xfsprogs/libxfs/init.c 2002-10-25 14:22:34.000000000 +0200
>>@@ -155,11 +155,14 @@
>> progname, path, strerror(errno));
>> exit(1);
>> }
>>+#if !defined(__hppa__) || defined(__LP64__)
>> error = ioctl(fd, BLKGETSIZE64, &size);
>>- if (error >= 0) {
>>+ if (!error) {
>> /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>> size = size >> 9;
>>- } else {
>>+ } else
>>+#endif
>>+ {
>> /* If BLKGETSIZE64 fails, try BLKGETSIZE */
>> unsigned long tmpsize;
>> error = ioctl(fd, BLKGETSIZE, &tmpsize);
>>
>>_______________________________________________
>>parisc-linux mailing list
>>parisc-linux@lists.parisc-linux.org
>>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
^ permalink raw reply
* Re: [PATCH 2/2] High-res-timers part 2 (x86 platform code) take 6
From: george anzinger @ 2002-10-26 16:19 UTC (permalink / raw)
To: Pavel Machek, Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <3DBAB90F.CEF29920@mvista.com>
george anzinger wrote:
>
> Pavel Machek wrote:
> >
> > Hi!
> >
> > > This patch, in conjunction with the "core" high-res-timers
> > > patch implements high resolution timers on the i386
> > > platforms. The high-res-timers use the periodic interrupt
> > > to "remind" the system to look at the clock. The clock
> >
> > This scares me:
> >
> > +#define fail_message \
> > +"High-res-timers:
> > >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"\
> > +"High-res-timers: >Failed to find the ACPI pm timer
> > <\n"\
> > +"High-res-timers: >-<--><-->-<-->-<-->-<-->Boot will fail in
> > Calibrate Delay <\n"\
> > +"High-res-timers: >Supply a valid default pm timer address
> > <\n"\
> > +"High-res-timers: >or get your BIOS to turn on ACPI support.
> > <\n"\
> > +"High-res-timers: >See CONFIGURE help for more information.
> > <\n"\
> > +"High-res-timers:
> > >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"
> >
> > Does that mean our boot has now so much junk in it that we start
> > adding ascii art for "important" messages?
>
> Well, Yes! It does. However, the problem here is that this
> is detected prior to enabling the console so, unless the
> boot can limp along until that happens, this message will
> not be seen. I have seen both conditions...
This, of course is the problem, the message appears buried
in the noise prior to the actual boot failure (assuming it
is printed at all).
>
> I am open to suggestions...
>
> Thanks for looking.
>
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* [PATCH]: linux-2.5.44uc1 (MMU-less support)
From: Greg Ungerer @ 2002-10-26 16:19 UTC (permalink / raw)
To: linux-kernel
Hi All,
An updated uClinux patch is available at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1.patch.gz
Changelog (alot :-)
1. v850 updates (Miles Bader)
2. mm cleanups (Christoph Hellwig)
3. cleanup of arch/m68knommu (me)
- common files moved to ~/arch/m68knomu/kernel
- arch Makefiles rewritten
- 68360 drivers moved to drivers directory
- lots of other miscelleneous changes
Smaller specific patches:
. FEC ColdFire 5272 and 68360 ethernet drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-fec.patch.gz
. m68k/ColdFire/v850 serial drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-serial.patch.gz
. 68328 frame buffer
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-fb.patch.gz
. binfmt_flat loader
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-binflat.patch.gz
. m68knommu architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-m68knommu.patch.gz
. v850 architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-v850.patch.gz
. mm (MMU-less) only patch
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-mm.patch.gz
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg@snapgear.com
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
^ permalink raw reply
* Re: [LARTC] Problem with fw filters
From: Martin Josefsson @ 2002-10-26 16:06 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103563976509242@msgid-missing>
On Sat, 2002-10-26 at 15:44, Aigars Mahinovs wrote:
> Hi all,
>
> I am trying to priorityse outgoing traffic basing on UID of the sender.
> Script follows:
>
> # First mark packets with their respective priority
>
> iptables -t mangle -F OUTPUT
>
> iptables -t mangle -A OUTPUT -m owner --uid-owner root -j MARK
> --set-mark 1
> iptables -t mangle -A OUTPUT -m owner --uid-owner aigarius -j MARK
> --set-mark 2
> iptables -t mangle -A OUTPUT -m owner --uid-owner bind -j MARK
> --set-mark 3
> iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK
> --set-mark 4
> iptables -t mangle -A OUTPUT -m owner --uid-owner nobody -j MARK
> --set-mark 5
> iptables -t mangle -A OUTPUT -m owner --uid-owner www-data -j MARK
> --set-mark 6
> iptables -t mangle -A OUTPUT -m owner --uid-owner ftp -j MARK --set-mark
> 7
> iptables -t mangle -A OUTPUT -m owner --uid-owner ivarix -j MARK
> --set-mark 8
> iptables -t mangle -A OUTPUT -m owner --uid-owner blacky -j MARK
> --set-mark 9
> iptables -t mangle -A OUTPUT -j MARK --set-mark 666
This won't work the way you want it to.
MARK doesn't terminate the rule-traversal... so all packets will be
marked as 666 in the end.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH] IPv6: Fix for Refine IPv6 Address Validation Timer
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2002-10-26 16:10 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: usagi
Hi,
We sent a patch to refine timing of IPv6 address validation timer.
However, timer was not recalculated on receipt of RA.
This patch fixes this bug.
Patch is for 2.4.20-pre11.
Thanks.
Index: net/ipv6/addrconf.c
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.26.1
diff -u -r1.1.1.2 -r1.1.1.2.26.1
--- net/ipv6/addrconf.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
+++ net/ipv6/addrconf.c 26 Oct 2002 15:55:14 -0000 1.1.1.2.26.1
@@ -947,6 +947,7 @@
ipv6_ifa_notify((flags&IFA_F_DEPRECATED) ?
0 : RTM_NEWADDR, ifp);
in6_ifa_put(ifp);
+ addrconf_verify(0);
}
}
in6_dev_put(in6_dev);
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: Wide negotiation fails with 80->68 LVD adapter?
From: Doug Ledford @ 2002-10-26 16:00 UTC (permalink / raw)
To: Alexy Khrabrov; +Cc: linux-scsi
In-Reply-To: <20021026145309.GA7695@angle.setup.org>
On Sat, Oct 26, 2002 at 10:53:09AM -0400, Alexy Khrabrov wrote:
>
> So I reread the drive manual, which says that
> Barracuda 50 drives support ANSI SCSI, SCSI-2 and SCSI-3
> (Fast-20 and Fast-40), which it says are the same
> as Ultra-1 and Ultra-2 for Fast-20/40, respectively.
> Mysteriously, Ultra2 is referred to as Ultra80 elsewhere,
> so looks like Fast-40 _is_ 80? If SCSI veterans could
> clarify this, I'd see how 40=80... Especially, given
> aic7xxx says something about 80 (40 MHz) in parentheses...
You aren't paying attention to the units of measure. The 40 in
Ultra2/Fast40 is 40MHz (aka, 40 million cycles per second). The SCSI bus
itself is either narrow (8 bits) or wide (16 bits). The speed rating you
are referring to is in Mega*BYTES* per second. So, to get the total
speed, you multiply the frequency of data transfer (the MHz part) times
how many bytes are transferred in each data transfer operation (aka, there
are 8 bits per byte, so a narrow bus transfers exactly one byte of
information in each transfer cycle, while a wide bus transfers 2 bytes of
information in each cycle). So, a Wide (16 bit, 2 byte) bus operating at
40MHz transfer frequency is actually transferring data at a rate of 80
MegaBytes of data per second.
> In all cases, seems that it's really the drive, Barracuda 50
> family is Ultra2 <=> Ultra80 (right?) but I was able to
> enable Wide Negotiation and set speed to 80, and aic7xxx v6.2.8
> showed them registered at 80. I'm just curious if I still could
> kinda spin them up to 160 anyways... :-)
No. A drive will *only* do what it is capable of doing, there is no
margin there for overclocking (and in fact the negotiation protocol won't
allow it, on most 80MByte/s drives if you set the Adaptec BIOS to
160MByte/s, the card and drive will still end up at 80MByte/s anyway
because the drive firmware and the controller driver have a message
protocol that they follow to negotiate the best possible speed that both
of them support and obviously if the drive only supports 80MByte/s
transfers, then that's the best that both of them support, but in your
case the drive appears to be locking up during the transfer speed
negotiation phase which could be the fault of the linux scsi driver you
are using or the fault of the drive firmware).
> Hence, so far, both SCA<->68 LVD adapters worked as advertised.
> I'm going to get a real 160 SCA drive and test it further.
> In the same vein, if I do end up getting an Ultra 320 card,
> and I will get an Adaptec one, what should I look for in the
> drive to see if it's capable of supporting 320?
The card and the drive *both* have to support 320 speeds, and you have to
have a driver for the 320 card. Justin Gibbs has a driver for the adaptec
320 cards, but it isn't in all the stock linux kernels yet (I think it's
in 2.4.19 and later, and should be in the 2.5 kernel series pretty soon).
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* Re: how do plugins work?
From: Hans Reiser @ 2002-10-26 15:46 UTC (permalink / raw)
To: Edward Shishkin; +Cc: gregor, reiserfs mailing list
In-Reply-To: <3DBAA71B.667E2EE8@namesys.com>
Edward Shishkin wrote:
>Hans Reiser wrote:
>
>
>>Edward Shishkin wrote:
>>
>>
>>
>>>Hans Reiser wrote:
>>>
>>>
>>>
>>>
>>>>Edward Shishkin wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Gregor Zeitlinger wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm new to this list. I'm wondering how the file plugins work. Are they
>>>>>>just a means of accessing the file contents or are they also designed to
>>>>>>save the file differently.
>>>>>>
>>>>>>For example, could you create a plugin that automatically zips each
>>>>>>text/plain file, which is totally transparent to the user?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Yeah, we could. Although transparentness means a bit worse compression..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>?
>>>>
>>>>You mean because of choosing to use compression atoms
>>>>
>>>>
>>>>
>>>>
>>>Yes, but it is not the only reason.
>>>
>>>
>>>
>>>
>>>
>>>>that are node sized?
>>>>
>>>>
>>>>
>>>>
>>>No, compression atoms are limited by common sense ;)
>>>Obviously, it doesn't make sense to choose it less then node size, if you
>>>want to compress a file presented by tails. On the other hand, I am not
>>>sure if you will be delighted from transparent compression supported by 256K
>>>clusters even for larger files.
>>>
>>>
>>>
>>>
>>>
>>>>Maybe it might be more precise to say that efficient random
>>>>access motivates small compression atoms which are less efficient?
>>>>(Assuming that I understood you.)
>>>>
>>>>
>>>>
>>>>
>>>There is one more obscured reason that makes transparent compression worser.
>>>I have to remind that its primary assignment is the same: to provide more
>>>efficient disk space usage. Let's take a look how transparent compression
>>>and the package using the same compression algorithm will provide it:
>>>Suppose we want to compress a 8S-byte file, and both transparent compression
>>>and package is supported by 4-blocks clusters, S - block size.
>>>
>>>File system:
>>>divides the file into 2 clusters, suppose each cluster was compressed up to
>>>(2S+1) bytes, so compressed file occupies 6 blocks.
>>>Package:
>>>makes compressed file which occupies 2*(2S+1) = 4S+2 bytes and passes it
>>>to the file system, which places it (aieee!) into 5 blocks..
>>>
>>> So we do have the actual compression ratio produced by the file system is
>>>6/8 = 25% against actual ones (5/8 = 37,5%) produced by the package. The user
>>>can observe this effect only by using "du" (when he does "df", he see that
>>>file system and package produce the same compression ratio 37,5%).
>>>This is another effect caused by the specific of packing policy (for the
>>>ext2 files, reiserfs files presented by indirect items, etc..) Obviously
>>>we can avoid this by using bigger cluster (8 blocks).
>>>
>>>Edward.
>>>
>>>
>>>
>>>
>>>
>>>
>>Or by not block aligning the clusters, which might be the right
>>solution,
>>
>>
>
>It is impossible for the files presented by indirect items, since
>it means you'll place dead space in memory per file.
>
We don't use indirect items. It is not impossible in any event, the
problem is with being efficient in reads while also ensuring that we
read whole compression atoms at a time.
>
>
>
>>and might allow for compression atoms larger than nodes.
>> Please consider that approach.
>>
>>Hans
>>
>>
>
>
>
>
^ permalink raw reply
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
From: Dipankar Sarma @ 2002-10-26 15:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rusty Russell, maneesh, linux-kernel
In-Reply-To: <20021025235222.A25786@in.ibm.com>
Well, my earlier find_first_bit() implementation was completely bogus.
My sanity has now returned and I coded this patch below that fixes
find_find_bit() to return "size" if all bits are zero. I have tested it
extensively in userspace and it boots 2.5.44-mm5 which crashed with the earlier
version of the bitops_fix patch. I have coded the assembly routine
as optimal as I could think of and without introducing any new
branches or memory loads.
Along with this patch, I applied the larger_cpu_mask patch to -mm5
and sanity tested both UP and SMP kernels for dcache leaks in a 4CPU P3 box.
An ls -lR and subsequent unmounting of that filesystems showed that
the dentries were correctly getting returned the dcache slab and
that indicates that the larger_cpu_mask patch no longer breaks RCU.
I will do some more testing with this combination later with
rcu_stats applied on this tree (just to be sure), but so far it looks good.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
bitops_fix.patch
-----------------
diff -urN linux-2.5.44-mm5/include/asm-i386/bitops.h linux-2.5.44-mm5-fix/include/asm-i386/bitops.h
--- linux-2.5.44-mm5/include/asm-i386/bitops.h Sat Oct 19 09:32:01 2002
+++ linux-2.5.44-mm5-fix/include/asm-i386/bitops.h Sat Oct 26 17:52:09 2002
@@ -311,12 +311,13 @@
"repe; scasl\n\t"
"jz 1f\n\t"
"leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
+ "bsfl (%%edi),%%edx\n"
+ "subl %%ebx,%%edi\n\t"
"shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
+ "addl %%edi,%%edx\n\t"
+ "1:\tmovl %%edx,%%eax\n\t"
:"=a" (res), "=&c" (d0), "=&D" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr));
+ :"1" ((size + 31) >> 5), "2" (addr), "b" (addr), "d" (size));
return res;
}
^ permalink raw reply
* Re: [PATCH 2/2] High-res-timers part 2 (x86 platform code) take 6
From: george anzinger @ 2002-10-26 15:47 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <20021023093815.GB3416@elf.ucw.cz>
Pavel Machek wrote:
>
> Hi!
>
> > This patch, in conjunction with the "core" high-res-timers
> > patch implements high resolution timers on the i386
> > platforms. The high-res-timers use the periodic interrupt
> > to "remind" the system to look at the clock. The clock
>
> This scares me:
>
> +#define fail_message \
> +"High-res-timers:
> >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"\
> +"High-res-timers: >Failed to find the ACPI pm timer
> <\n"\
> +"High-res-timers: >-<--><-->-<-->-<-->-<-->Boot will fail in
> Calibrate Delay <\n"\
> +"High-res-timers: >Supply a valid default pm timer address
> <\n"\
> +"High-res-timers: >or get your BIOS to turn on ACPI support.
> <\n"\
> +"High-res-timers: >See CONFIGURE help for more information.
> <\n"\
> +"High-res-timers:
> >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"
>
> Does that mean our boot has now so much junk in it that we start
> adding ascii art for "important" messages?
Well, Yes! It does. However, the problem here is that this
is detected prior to enabling the console so, unless the
boot can limp along until that happens, this message will
not be seen. I have seen both conditions...
I am open to suggestions...
Thanks for looking.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: [PATCH] hyper-threading information in /proc/cpuinfo
From: Eric W. Biederman @ 2002-10-26 15:45 UTC (permalink / raw)
To: Alan Cox
Cc: Nakajima, Jun, Robert Love, 'Dave Jones',
'akpm@digeo.com', 'linux-kernel@vger.kernel.org',
'chrisl@vmware.com', 'Martin J. Bligh'
In-Reply-To: <1035584076.13032.96.camel@irongate.swansea.linux.org.uk>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Sorry,
> >
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> > is already doing it:
>
> Could do
> >
> > +#ifdef CONFIG_SMP
> > + if (cpu_has_ht) {
> > + seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
> > + seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
> > + }
> > +#endif
>
>
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
How about using "SMT width" for the P4 case?
And if we needed to break it down per package for a Power4 and the
like we could talk about CMP something, or other.
Only SMT and CMP seem to be unambiguous prefixes. Though for CMP
we probably do not need to do anything because it really is 2 cpus, and we
only need to worry about locatity in the cache hierarchy not the fact that
if we schedule a cpu intensive job on 1 ``cpu'' the others are useless.
Eric
^ permalink raw reply
* Re: Pinging a IP , how to stop it bringing diald live
From: Mark Frey @ 2002-10-26 15:31 UTC (permalink / raw)
To: Sean Rima; +Cc: linux-diald
In-Reply-To: <MSGID_2=3a263=2f950=40fidonet_3db16275@fidonet.org>
Hi Sean,
Try putting this near the top of your standard.filter file, or the file
where you're defining your rules:
ignore icmp ip.daddr=ip.address.to.ignore
Mark.
Sean Rima wrote:
> Originally to: All
>
> Hi Folks,
>
> I am trying to get a BBS package working, it checks that the inet is
> live by
> pinging the net. Is there any way to tell diald not to dial if it
> receives a
> ping for a certain ip?
>
> Sean
>
>
> Gtx, Sean Rima
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* KT333, IO-APIC, Promise Fasttrak, Initrd [UPDATE]
From: freaky @ 2002-10-26 15:37 UTC (permalink / raw)
To: linux-kernel
Hey there,
in addition to my previous posts with this topic I would like to post the
kernel output.
Additional info:
kernel 2.4.20-pre11
gcc version 2.95.3 20010315 (release)
Kernel config: http://freaky.bananateam.nl/config
BIOS-e820:
#Stripped insignificant zeros
0-9FC00 (usable)
9FC00-A0000 (reserved)
F0000-100000 (reserved)
100000-1fff0000 (usable)
1FFF0000-1FFF8000 (ACPI DATA)
1FFF8000-20000000 (ACPI NVS)
FEC00000-FEC01000 (reserved)
FEE00000-FEE01000 (reserved)
FFF800000-100000000 (reserved)
511MB LOWMEM available
found SMP MP-table at 000FB940 # Is the uniprocessor IO-APIC causing this?
AFAIK I didn't include SMP....
hm, page 000FB000 reserved twice
hm, page 000FC000 reserved twice
hm, page 000F6000 reserved twice
hm, page 000F7000 reserved twice
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: VIA Product ID: VT5440B APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 3 at 0xFEC00000.
Processors: 1
Kernel command line: vmlinuz ramdisk_size=7000 root=/dev/fd0u1440 vga=normal
rw SLACK_KERNEL=new.i BOOT_IMAGE=vmlinuz root=/dev/fd0
Initializing CPU#0
Detected 1666.740 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3322.67 BogoMIPS
Memory: 516472k/524224k available (1041k kernel code, 7364k reserved, 311k
data, 100k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 2000+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-18, 2-20, 2-21, 2-23 not
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 18.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 001 01 0 0 0 0 0 1 1 51
07 001 01 0 0 0 0 0 1 1 59
08 001 01 0 0 0 0 0 1 1 61
09 001 01 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 001 01 0 0 0 0 0 1 1 71
0d 001 01 0 0 0 0 0 1 1 79
0e 001 01 0 0 0 0 0 1 1 81
0f 001 01 0 0 0 0 0 1 1 89
10 001 01 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 001 01 1 1 0 1 0 1 1 99
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 001 01 1 1 0 1 0 1 1 A1
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ19 -> 0:19
IRQ22 -> 0:22
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1666.7379 MHz.
..... host bus clock speed is 266.6780 MHz.
cpu: 0, clocks: 2666780, slice: 1333390
CPU0<T0:2666768,T1:1333376,D:2,S:1333390,C:2666780>
PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [1106/3177] at 00:11.0
PCI->APIC IRQ transform: (B0,I8,P0) -> 19
PCI->APIC IRQ transform: (B0,I12,P0) -> 19
PCI->APIC IRQ transform: (B0,I17,P0) -> 16
PCI->APIC IRQ transform: (B0,I17,P2) -> 22
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20276: IDE controller on PCI bus 00 dev 60
PDC20276: chipset revision 1
PDC20276: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: Unknown VIA SouthBridge, contact Vojtech Pavlik <vojtech@ucw.cz>
hda: Pioneer DVD-ROM ATAPIModel DVD-105S 013, ATAPI CD/DVD-ROM drive
hdc: LITE-ON LTR-12101B, ATAPI CD/DVD-ROM drive
hde: QUANTUM FIREBALLP AS30.0, ATA DISK drive
hdf: ST340810A, ATA DISK drive
hdg: IBM-DTLA-307020, ATA DISK drive
hdh: Maxtor 91741U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide0: probed IRQ 14 failed, using default.
ide1 at 0x170-0x177,0x376 on irq 15
ide1: probed IRQ 15 failed, using default.
ide2 at 0xec00-0xec07,0xe802 on irq 19
ide3 at 0xe400-0xe407,0xe002 on irq 19
hde: 58633344 sectors (30020 MB) w/1902KiB Cache, CHS=58168/16/63
hdf: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63
hdg: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63
hdh: 34004880 sectors (17410 MB) w/512KiB Cache, CHS=33735/16/63
hda: ATAPI 40X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache
Partition check:
hde: [PTBL] [3649/255/63] hde1 hde2 < hde5 >
hdf: [PTBL] [4865/255/63] hdf1
hdg: [PTBL] [2501/255/63] hdg1
hdh: [PTBL] [2116/255/63] hdh1 hdh2 hdh3 hdh4 < hdh5 hdh6 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 7000K size 1024 blocksize
loop: loaded (max 8 devices)
8139too Fast Ethernet driver 0.9.26
eth0: RealTek RTL8139 Fast Ethernet at 0xe0800f00, 00:40:f4:55:38:a7, IRQ 19
eth0: Identified 8139 chip type 'RTL-8139C'
ataraid/d0: ataraid/d0p1 ataraid/d0p2 < ataraid/d0p5 >
Drive 0 is 28629 Mb (33 / 0)
Raid0 array consists of 1 drives.
ataraid/d1: ataraid/d1p1
Drive 0 is 38166 Mb (33 / 64)
Raid0 array consists of 1 drives.
ataraid/d2: ataraid/d2p1
Drive 0 is 19623 Mb (34 / 0)
Raid0 array consists of 1 drives.
ataraid/d3: ataraid/d3p1 ataraid/d3p2 ataraid/d3p3 ataraid/d3p4 <
ataraid/d3p5 ataraid/d3p6 >
Drive 0 is 16603 Mb (34 / 64)
Raid0 array consists of 1 drives.
Promise Fasttrak(tm) Softwareraid driver for linux version 0.03beta
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 100k freed
That was the rescuedisk (compressed 1 disk image)
with the 5 install disks (wget
ftp://ftp.slackware.org/slackware/slackware-current/rootdisks/install.[1-5])
It gives:
RAMDISK: ext2 fs found at block 0
Loading 6464 blocks [5 disks] into ram disk
VFS: Insert disk #2 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #3 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #4 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #5 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
Then it boots and comes up with ext2 filesystem errors on directory #41.
Sometimes it starts actually reading at disk 3 or 4, but it never actually
reads disk 2... Most of the time it doesn't actually read any disk but 1
though (the floppy read LED does go on tho'). Since disk 2 is never loaded
it always comes up with the directory #41 ext2 fs errors.
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Alan Cox @ 2002-10-26 15:46 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Alan Cox, Dave Jones, Linux Kernel Mailing List
In-Reply-To: <3007712682.1035619204@[10.10.2.3]>
On Sat, 2002-10-26 at 16:00, Martin J. Bligh wrote:
> >> Isn't this always the case on x86 ?
> >> /me waits to hear gory details of some IBM monster.
> >
> > It isnt. The boot CPU may be any number. In addition you can strap dual
> > pentium boxes to arbitrate for who is boot cpu (this is used for fault
> > tolerance).
>
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?
Ok its a logical ID - so yes
^ 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.