* Re: problems connecting to kernel.bkbits.net
From: Larry McVoy @ 2004-01-26 15:41 UTC (permalink / raw)
To: linux-kernel
Eric forwarded me this mail (thanks).
The BK->CVS gateway is still going strong but the CVS server part of it has
been shut down because of security problems. Nobody wants to run it because
of the security problems that CVS has. If someone wants to do that they
can mirror it from kernel.org, it's there under /pub/scm/linux/kernel/bkcvs
and if you grab that you can start up a CVS server.
----- Forwarded message from Stas Sergeev <stsp@aknet.ru> -----
From: Stas Sergeev <stsp@aknet.ru>
To: linux-kernel@vger.kernel.org
Subject: problems connecting to kernel.bkbits.net
Date: Sun, 25 Jan 2004 20:11:35 +0300
Hello.
I used a BK->CVS gateway on kernel.bkbits.net
for some time, but it is already several
month that I can't connect to it any more.
Is it still alive?
Here is what I have:
$ cvs update
cvs [update aborted]: connect to kernel.bkbits.net(192.132.92.14):2401
failed: No route to host
$ traceroute kernel.bkbits.net
1 gate (192.168.3.1) 5.823 ms 16.544 ms 8.973 ms
2 RINNet-MSU.iitp.ru (194.220.14.45) 12.531 ms 143.000 ms 69.300 ms
3 RINNet-IITP.iitp.ru (194.220.14.129) 134.844 ms 212.712 ms
190.928 ms
[.....]
20 svl-edge-09.inet.qwest.net (205.171.14.98) 312.245 ms * 204.768 ms
21 63.150.59.90 (63.150.59.90) 268.390 ms 217.756 ms 218.520 ms
22 216.240.36.206 (216.240.36.206) 218.669 ms 248.692 ms 218.659 ms
23 kernel.bkbits.net (192.132.92.14) 214.393 ms !<10> 243.426 ms
!<10> *
$ ping kernel.bkbits.net
PING kernel.bkbits.net (192.132.92.14) from 192.168.3.28 : 56(84)
bytes of data.64 bytes from kernel.bkbits.net (192.132.92.14):
icmp_seq=0 ttl=44 time=239.295 msec
64 bytes from kernel.bkbits.net (192.132.92.14): icmp_seq=1 ttl=44
time=230.619 msec
--- kernel.bkbits.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 230.619/234.957/239.295/4.338 ms
Now I am lost. ping is fine, but traceroute
shows code 10, which is "Host prohibited".
Any ideas what can that be?
I have googled a lot, but I have found
nothing that looks even nearly similar to the
problem I am having.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ permalink raw reply
* RE: [LARTC] Re: Problems with netfilter
From: Nikhil Jogia @ 2004-01-26 15:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <ACEEJABKCELIHBFMPFOMCEKHCBAA.lartc@nikhiljogia.com>
PROBLEM SOLVED!
I didn't have to bind the output to the mail server.
The problem was that I didn't have a SNAT rule for eth0 (the network
interface attached to the ADSL modem).
Thank god for that!
> iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 25
> ip rule add fwmark 25 lookup mail
> ip route add default via xxx.xxx.xxx.xxx dev ppp0 table mail
>
> Running tcpdump it appears that port 25 traffic is be routed through the
> ADSL connection. However, the source IP address appears to be the cable IP
Correct routing is kinda odd in this case, as IPTABLES OUTPUT happens
after OUTPUT ROUTING, according to KPTD
(http://www.docum.org/stef.coene/qos/kptd).
> address (cable is the default gateway). I have put SNAT rules in place,
> however they don't seem to work.
>
> The SNAT rules I used were:
>
> iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to yyy.yyy.yyy.yyy
> and the same thing with the cable connection.
>
> Rememeber, the packets are being generated locally through the mail server
> (qmail).
IPTABLES POSTROUTING happens for both locally originated and forwarded
traffic (see KPTD); it should have worked.
Anyway, binding the mail server to the intended IP address (by adding it
to the tcpserver call) should also do this part of the job.
Rubens
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: kernel BUG under 2.6.1-mm5
From: Andrey Borzenkov @ 2004-01-26 15:30 UTC (permalink / raw)
To: Andrew Morton, Jim Faulkner; +Cc: linux-kernel
In-Reply-To: <20040121144804.598c2998.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
On Thursday 22 January 2004 01:48, Andrew Morton wrote:
> Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
> > Hello,
> >
> > I am seeing some scary looking kernel bug entries in my dmesg under
> > 2.6.1-mm5.
> > ...
> >
> > kernel BUG at fs/dcache.c:760!
> > invalid operand: 0000 [#1]
> > PREEMPT SMP
> > CPU: 0
> > EIP: 0060:[<c0179627>] Not tainted VLI
> > EFLAGS: 00010287
> > EIP is at d_instantiate+0x17/0x90
> > eax: f7baf200 ebx: c1b8bac0 ecx: 000021a4 edx: 00000000
> > esi: f7a4f868 edi: f7baf200 ebp: f7a4f840 esp: f7a79e3c
> > ds: 007b es: 007b ss: 0068
> > Process hotplug (pid: 24, threadinfo=f7a78000 task=c1b06d00)
> > Stack: 00000000 f7a992e4 c1b8bac0 c1b35940 f7a78000 f7a4f840 c01ad6de
> > f7a4f840
> > f7baf200 f7a4f840 f7a41e1c c1bbeb40 00000000 c1b06d00 c011f5b0
> > 00000000
> > 00000000 f7a96d00 c1b06d00 c011bb7d 00000000 c1b06d00 c011f5b0
> > 00000000
> > Call Trace:
> > [<c01ad6de>] devfs_d_revalidate_wait+0xbe/0x1b0
> > [<c011f5b0>] default_wake_function+0x0/0x20
> > [<c011bb7d>] do_page_fault+0x32d/0x512
> > [<c011f5b0>] default_wake_function+0x0/0x20
> > [<c016e868>] do_lookup+0x68/0xb0
> > [<c016ede8>] link_path_walk+0x538/0xa30
> > [<c016fd03>] open_namei+0x83/0x420
> > [<c011b850>] do_page_fault+0x0/0x512
> > [<c040d4cb>] error_code+0x2f/0x38
> > [<c015e61e>] filp_open+0x3e/0x70
> > [<c015eb9b>] sys_open+0x5b/0x90
> > [<c040c992>] sysenter_past_esp+0x43/0x65
>
> hmm. There was a patch in that area which I have subsequently dropped
> because it was really fixing devfs problems in the wrong place.
>
hmm ...
> Perhaps Andrey can ask you to test a subsequent patch if he takes another
> look at this.
please try this one. This basically does the same inside of devfs. It passed
usual sanity checks here; I cannot reproduce oops you have (do you have SMP
system?)
I appreciate if someone with more intimate knowledge of fs/namei.c comments if
conditions in devfs_d_revalidate_wait make sense.
-andrey
[-- Attachment #2: 2.6.2-rc2-devfs-d_revalidate-2.patch --]
[-- Type: text/x-diff, Size: 3939 bytes --]
--- linux-2.6.2-rc2/fs/devfs/base.c.nd 2004-01-26 13:25:38.000000000 +0300
+++ linux-2.6.2-rc2/fs/devfs/base.c 2004-01-26 15:52:11.000000000 +0300
@@ -676,6 +676,7 @@
#include <linux/smp.h>
#include <linux/rwsem.h>
#include <linux/sched.h>
+#include <linux/namei.h>
#include <asm/uaccess.h>
#include <asm/io.h>
@@ -2223,6 +2224,34 @@ static int devfs_d_revalidate_wait (stru
devfs_handle_t parent = get_devfs_entry_from_vfs_inode (dir);
struct devfs_lookup_struct *lookup_info = dentry->d_fsdata;
DECLARE_WAITQUEUE (wait, current);
+ int need_lock;
+
+ /*
+ * FIXME HACK
+ *
+ * make sure that
+ * d_instantiate always runs under lock
+ * we release i_sem lock before going to sleep
+ *
+ * unfortunately sometimes d_revalidate is called with
+ * and sometimes without i_sem lock held. The following checks
+ * attempt to deduce when we need to add (and drop resp.) lock
+ * here. This relies on current (2.6.2) calling coventions:
+ *
+ * lookup_hash is always run under i_sem and is passing NULL
+ * as nd
+ *
+ * open(...,O_CREATE,...) calls _lookup_hash under i_sem
+ * and sets flags to LOOKUP_OPEN|LOOKUP_CREATE
+ *
+ * all other invocations of ->d_revalidate seem to happen
+ * outside of i_sem
+ */
+ need_lock = nd &&
+ (!(nd->flags & LOOKUP_CREATE) || (nd->flags & LOOKUP_PARENT));
+
+ if (need_lock)
+ down(&dir->i_sem);
if ( is_devfsd_or_child (fs_info) )
{
@@ -2233,33 +2262,40 @@ static int devfs_d_revalidate_wait (stru
"(%s): dentry: %p inode: %p de: %p by: \"%s\"\n",
dentry->d_name.name, dentry, dentry->d_inode, de,
current->comm);
- if (dentry->d_inode) return 1;
+ if (dentry->d_inode)
+ goto out;
if (de == NULL)
{
read_lock (&parent->u.dir.lock);
de = _devfs_search_dir (parent, dentry->d_name.name,
dentry->d_name.len);
read_unlock (&parent->u.dir.lock);
- if (de == NULL) return 1;
+ if (de == NULL)
+ goto out;
lookup_info->de = de;
}
/* Create an inode, now that the driver information is available */
inode = _devfs_get_vfs_inode (dir->i_sb, de, dentry);
- if (!inode) return 1;
+ if (!inode)
+ goto out;
DPRINTK (DEBUG_I_LOOKUP,
"(%s): new VFS inode(%u): %p de: %p by: \"%s\"\n",
de->name, de->inode.ino, inode, de, current->comm);
d_instantiate (dentry, inode);
- return 1;
+ goto out;
}
- if (lookup_info == NULL) return 1; /* Early termination */
+ if (lookup_info == NULL)
+ goto out; /* Early termination */
read_lock (&parent->u.dir.lock);
if (dentry->d_fsdata)
{
set_current_state (TASK_UNINTERRUPTIBLE);
add_wait_queue (&lookup_info->wait_queue, &wait);
read_unlock (&parent->u.dir.lock);
+ /* at this point it is always (hopefully) locked */
+ up(&dir->i_sem);
schedule ();
+ down(&dir->i_sem);
/*
* This does not need nor should remove wait from wait_queue.
* Wait queue head is never reused - nothing is ever added to it
@@ -2271,6 +2307,10 @@ static int devfs_d_revalidate_wait (stru
}
else read_unlock (&parent->u.dir.lock);
+
+out:
+ if (need_lock)
+ up(&dir->i_sem);
return 1;
} /* End Function devfs_d_revalidate_wait */
@@ -2320,6 +2360,7 @@ static struct dentry *devfs_lookup (stru
revalidation */
up (&dir->i_sem);
wait_for_devfsd_finished (fs_info); /* If I'm not devfsd, must wait */
+ down (&dir->i_sem); /* Grab it again because them's the rules */
de = lookup_info.de;
/* If someone else has been so kind as to make the inode, we go home
early */
@@ -2349,7 +2390,6 @@ out:
dentry->d_fsdata = NULL;
wake_up (&lookup_info.wait_queue);
write_unlock (&parent->u.dir.lock);
- down (&dir->i_sem); /* Grab it again because them's the rules */
devfs_put (de);
return retval;
} /* End Function devfs_lookup */
^ permalink raw reply
* Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
From: Adam Kropelin @ 2004-01-26 15:50 UTC (permalink / raw)
To: Linux Kernel List; +Cc: Steve Youngs
In-Reply-To: <microsoft-free.87hdyjs3h3.fsf@eicq.dnsalias.org>
On Mon, Jan 26, 2004 at 03:06:48PM +1000, Steve Youngs wrote:
> * Adam Kropelin <akropel1@rochester.rr.com> writes:
>
> > On Mon, Jan 26, 2004 at 09:12:58AM +1000, Steve Youngs wrote:
> >> * Linus Torvalds <torvalds@osdl.org> writes:
> >>
> >> > - doing proper refcounting of modules is _really_ really
> >> > hard. The reason is that proper refcounting is a "local"
> >>
> >> Please understand that I coming from an _extremely_ naive perspective,
> >> but why do refcounting at all? Couldn't the refcount be a simple
> >> boolean?
>
> > A boolean is just a one-bit reference count. If the maximum number of
> > simultaneous 'users' for a given module is one, then a boolean will work.
> > If there is potential for more than one simultaneous user then you need
> > more bits.
>
> Why? A module is either being used or it isn't, the number of uses
> shouldn't even come into it.
I think others in the thread have adequately explained the details
you're missing.
> I'm suggesting that the responsibility for determining when it is safe
> to unload a particular module should lay with the module itself and
> not with the kernel.
That does not change anything at all. The same problems apply and the
same pool of solutions is still available. The easy cases are still easy
and the hard cases are still *really* hard.
> >> > - lack of testing.
> >>
> >> A moot point once the kernel can safely and efficiently do module
> >> unloading.
>
> > I don't follow your logic. Once it works we don't have to test it so
> > therefore we never need to test it?
>
> Possibly a poor choice of words on my part. What I meant was that
> once the functionality goes into the kernel testing will happen on
> every single Linux box in the land that has this future kernel. Some
> of those users will report bugs if there are any. And some of those
> users may even help to fix those bugs.
Hello? 2.4, etc. support removing modules. Linus was speaking from
experience. One of the reasons module removal is perpetually broken in
subtle ways on those kernels is that it simply does not receive enough
testing. Having some new implementation on 2.6 doesn't change that.
> Also what I meant is that you can't test something that doesn't
> exist.
As I pointed out above, it does exist.
> >> We get an awful lot of blue moons here.
>
> > This moon's not worth barking at.
>
> There are an awful lot of users out there who would disagree with you
> on that. _One_ of the reasons that I believe that this moon is worth
> barking at is:
>
> If a module should never, in the normal course of events, be unloaded,
> then there isn't _any_ point to being able to load them in the first
> place. Not being able to unload them _totally_ defeats the purpose of
> modules.
Think a little harder and you'll see why that's a ridiculous conclusion.
Hint #1: Distributions. Hint #2: SILO.
> Tell me that this problem is _impossible_ to solve and providing you
> can show me _why_ it is impossible I'll speak no more on this
> matter.
No one yet has claimed this is "impossible" to solve, only that it's not
worth solving. Clearly it's important to you, so have at it. Further
discussion of how you "see the answer so clearly" and the rest of us are
"not trying hard enough" should come in the form of patches.
--Adam
^ permalink raw reply
* Re: kernel 2.6.1 and cdrecord on ATAPI bus
From: Ken Moffat @ 2004-01-26 15:38 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Charles Shannon Hendrix, Linux Kernel
In-Reply-To: <4014789F.2000202@tmr.com>
On Sun, 25 Jan 2004, Bill Davidsen wrote:
> Charles Shannon Hendrix wrote:
> >
> > Is CD burning supposed to work with kernel 2.6.1 using the ATAPI
> > interface, or are bugs still being worked out?
> >
> > I have run cdrecord under kernel 2.4.2x and it worked great using the
> > ATAPI interface like this:
> >
> > % cdrecord dev=ATAPI:bus,drive,lun
> >
Did a bit of that recently with 2.4, everything was ok except that
fixation, at least for audio CDs under xcdroast, took a _very_ long
time. That box is now running 2.6.1 and using -dev=/dev/hdc : I tested
xcdroast on audio the other day - writing was ok, but it insisted on
reading from 0,0,0 and claimed there was nothing in /dev/hdc. I've just
tested writing a data cd from /dev/hdc and it works fine for me.
I got the impression that under 2.4 dev=ATAPI was not the best way to
go. For 2.6 it seems happy to use the regular device name. Burns at
16x, which is all the drive supports, reads fine on what I've tested.
Suggest you (Charles) try it as -dev=/dev/hdc (or wherever it is).
>
> I believe that you will find that you have to compile for 2.6 on a
> machine with /usr/src/linux pointing to the 2.6 kernel source. This is
> being discussed elsewhere, but is what got things working for me.
>
Surely not! The basic system on that box of mine was put together in
October 2002 (although X, the graphical stuff, and cdrecord were only
compiled two or three months back - 2.6.1 is my first try with 2.6 on
it). I'm a good boy, I don't have /usr/src/linux:
GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.3 20010315 (release).
Compiled on a Linux 2.4.19 system on 2002-10-10.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.9 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
ls: /usr/src/linux: No such file or directory
Ken
--
This is a job for Riviera Kid!
^ permalink raw reply
* 2.6.2-rc1-mm3: SCSI TARGET RESET on boot with no indication of why
From: Jonathan Kamens @ 2004-01-26 15:37 UTC (permalink / raw)
To: linux-kernel
With my AIC7XXX controller and my rather old Microtek ScanMaker E6
SCSI scanner, 2.6.2-rc1-mm3 for some reason feels compelled to attempt
to reset the scanner immediately after identifying it during the boot
sequence. When I see "immediately" I mean that there doesn't seem to
be any delay between when it prints out the "Attached scsi generic"
message in the transcript below and when it prints out the subsequent
messages about the TARGET RESET message.
Despite these messages, the scanner appears to work when booting is
finished.
This does not occur with 2.4.22-ac4.
My question is -- do these messages indicate that something is wrong,
what could it be, and what should I do about it?
I tried to find a maintainer for the AIC7XXX code to contact about
this, but I didn't see one in MAINTAINERS.
Thanks,
jik
Boot log excerpt:
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7890/91 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
hub 1-0:1.0: new USB device on port 2, assigned address 3
Vendor: Model: Scanner 600 Rev: 1.91
Type: Scanner ANSI SCSI revision: 03
Attached scsi generic sg0 at scsi0, channel 0, id 4, lun 0, type 6
scsi0:0:4:0: Attempting to queue a TARGET RESET message
CDB: 0xa0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0x8 0x0 0x0
scsi0:0:4:0: Command not found
aic7xxx_dev_reset returns 0x2002
scsi0:0:4:0: Attempting to queue a TARGET RESET message
CDB: 0xa0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0x8 0x0 0x0
scsi0:0:4:0: Command not found
aic7xxx_dev_reset returns 0x2002
scsi0:0:4:0: Attempting to queue a TARGET RESET message
CDB: 0xa0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0x8 0x0 0x0
scsi0:0:4:0: Command not found
aic7xxx_dev_reset returns 0x2002
^ permalink raw reply
* Re: snd_pcm_unlink -> EINVAL?
From: Jaroslav Kysela @ 2004-01-26 15:37 UTC (permalink / raw)
To: Tim Goetze; +Cc: alsa-devel
In-Reply-To: <Pine.LNX.4.58.0401261529240.562@autumn>
On Mon, 26 Jan 2004, Tim Goetze wrote:
> when calling snd_pcm_unlink (stream) after an xrun occurred, it
> returns EINVAL (hw: device, duplex, mmap'd IO, stop_threshold = ~0),
> even though 'stream' is a valid PCM stream handle.
>
> the snd_pcm_unlink code path seems to return EINVAL only if the stream
> isn't linked to another.
>
> but EINVAL misses the point, since the stream handle is valid.
> if one tries to unlink a stream that isn't linked to another, EALREADY
> is correct imo.
Yes, changed.
> and my question for today: does the kernel layer unlink PCM streams
> when an xrun occurs?
No. The unlinking is done manually (unlink ioctl) or at close() of
a PCM handle.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Is there a grand plan for FC failover?
From: James Bottomley @ 2004-01-26 15:37 UTC (permalink / raw)
To: Simon Kelley; +Cc: SCSI Mailing List
In-Reply-To: <401521A7.5030808@thekelleys.org.uk>
On Mon, 2004-01-26 at 08:18, Simon Kelley wrote:
> I see that 2.6.x kernels now have the qla2xxx driver in the mainline,
> but without the failover code.
>
> What is the reason for that? Is there a plan provide failover facilities
> at a higher level which will be usable with all suitable low-level
> drivers and hardware?
>
> I'm very much in favour of using drivers which are developed in the
> kernel mainline but I have an application which needs failover so I
> might be forced back to the qlogic-distributed code.
Yes, the direction coming out of KS/OLS last year was to use the dm or
md multi-path code to sit the failover driver on top of sd (or any other
block driver).
The idea being that the Volume Manager layer is the most stack generic
place to do this type of thing. The thread on this is here:
http://marc.theaimsgroup.com/?t=106005575400003
James
^ permalink raw reply
* RE: [Qemu-devel] QEMU 0.5.2
From: Yelich, Scott D. @ 2004-01-26 15:07 UTC (permalink / raw)
To: qemu-devel
Has anyone attempted to compile this puppy on the ipaq cluster at handhelds.org?
Scott
-----Original Message-----
From: Fabrice Bellard [mailto:fabrice.bellard@free.fr]
Sent: Sunday, January 25, 2004 11:16 AM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] QEMU 0.5.2
Hi,
QEMU 0.5.2 is out. A statically linked binary distribution for i386 is
also available. There are still many known problems (see the TODO list
!), but more OSes are working.
version 0.5.2:
- improved soft MMU speed (assembly functions and specializing)
- improved multitasking speed by avoiding flushing TBs when
switching tasks
- improved qemu-fast speed
- improved self modifying code handling (big performance gain in
softmmu mode).
- fixed IO checking
- fixed CD-ROM detection (win98 install CD)
- fixed addseg real mode bug (GRUB boot fix)
- added ROM memory support (win98 boot)
- fixed 'call Ev' in case of paging exception
- updated the script 'qemu-binfmt-conf.sh' to use QEMU automagically
when launching executables for the supported target CPUs.
- PowerPC system emulation update (Jocelyn Mayer)
- PC floppy emulation and DMA fixes (Jocelyn Mayer)
- polled mode for PIC (Jocelyn Mayer)
- fixed PTE dirty bit handling
- fixed xadd same reg bug
- fixed cmpxchg exception safeness
- access to virtual memory in gdb stub
- task gate and NT flag fixes
- eflags optimisation fix for string operations
Fabrice.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://mail.nongnu.org/mailman/listinfo/qemu-devel
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email Security System.
________________________________________________________________________
This mail message originated outside Commerzbank via the Internet. As a result, the sender's address is not verifiable.
**********************************************************************
This communication is confidential and is intended only for the person to whom it is addressed. If you are not that person you are not permitted to make use of the information and you are requested to notify Commerzbank Aktiengesellschaft, New York Branch immediately that you have received it and then to destroy the copy in your possession. Views expressed in this e-mail do not necessarily reflect the views of Commerzbank AG.
**********************************************************************
^ permalink raw reply
* Patch for autofs-4.1.0
From: HOSAKA Eiichi @ 2004-01-26 15:36 UTC (permalink / raw)
To: autofs
Patch for autofs-4.1.0
to port the file samples/rc.autofs for the Slackware Linux.
diff -ru autofs-4.1.0/samples/Makefile autofs-4.1.0slack1.4/samples/Makefile
--- autofs-4.1.0/samples/Makefile 2003-09-29 17:22:35.000000000 +0900
+++ autofs-4.1.0slack1.4/samples/Makefile
@@ -10,7 +10,11 @@
CFLAGS += -I../include
LIBS = -lldap -llber
+ifeq ($(LDAP),1)
all: autofs-ldap-auto-master rc.autofs
+else
+all: rc.autofs
+endif
autofs-ldap-auto-master: $(OBJS)
$(CC) $(LDFLAGS) -o autofs-ldap-auto-master $(OBJS) $(LIBS)
@@ -28,10 +32,18 @@
-mv -f $(INSTALLROOT)/etc/auto.misc $(INSTALLROOT)/etc/auto.misc.old
install -c auto.misc -m 644 $(INSTALLROOT)/etc
install -c auto.net -m 755 $(INSTALLROOT)/etc
+ifneq ($(initdir),)
install -d -m 755 $(INSTALLROOT)/$(initdir)
install -c rc.autofs -m 755 $(INSTALLROOT)$(initdir)/autofs
+else
+ if test -d $(INSTALLROOT)/etc/rc.d ; then \
+ install -c rc.autofs -m 755 $(INSTALLROOT)/etc/rc.d ; \
+ fi
+endif
+ifeq ($(LDAP),1)
install -d -m 755 $(INSTALLROOT)$(autofslibdir)
install -c autofs-ldap-auto-master -m 755 $(INSTALLROOT)$(autofslibdir)
+endif
clean:
rm -f *.o *.s autofs-ldap-auto-master rc.autofs
diff -ru autofs-4.1.0/samples/rc.autofs.in autofs-4.1.0slack1.4/samples/rc.autofs.in
--- autofs-4.1.0/samples/rc.autofs.in 2003-11-24 23:36:51.000000000 +0900
+++ autofs-4.1.0slack1.4/samples/rc.autofs.in
@@ -7,7 +7,7 @@
# map with that name
#
# On most distributions, this file should be called:
-# /etc/rc.d/init.d/autofs or /etc/init.d/autofs
+# /etc/rc.d/init.d/autofs, /etc/init.d/autofs or /etc/rc.d/rc.autofs
#
# For Redhat-ish systems
@@ -41,6 +41,8 @@
system=debian
elif [ -f /etc/redhat-release ]; then
system=redhat
+elif [ -f /etc/slackware-version ]; then
+ system=slackware
else
echo "$0: Unknown system, please port and contact autofs@linux.kernel.org" 1>&2
exit 1
@@ -169,12 +171,12 @@
: echo DAEMONOPTIONS OPTIONS $daemonoptions $options
startupoptions=
if echo "$daemonoptions" | grep -q -- '-t' ; then
- startupoptions="--timeout=$(echo $daemonoptions $options | \
+ startupoptions="--timeout=$(echo $daemonoptions | \
sed 's/.*--*t\(imeout\)*[ \t=]*\([0-9][0-9]*\).*$/\2/g')"
fi
# Override timeout in $daemonoptions with map $options
if echo "$options" | grep -q -- '-t' ; then
- startupoptions="--timeout=$(echo $daemonoptions $options | \
+ startupoptions="--timeout=$(echo $options | \
sed 's/.*--*t\(imeout\)*[ \t=]*\([0-9][0-9]*\).*$/\2/g')"
fi
if echo "$daemonoptions $options" | grep -q -- '-g' ; then
@@ -402,11 +404,74 @@
esac
}
+#
+# Slackware start/stop function.
+#
+function slackware()
+{
+ local lock=/var/lock/$prog
+ case "$1" in
+ (start)
+ if ! ln -s /dev/null $lock 2>/dev/null ; then
+ echo "$prog is now running or already killed abnormally" >&2
+ exit 1
+ fi
+ echo "Starting $prog:"
+ getmounts | while read line ; do echo " $line" ; $line ; sleep 1 ; done
+ ;;
+ (stop)
+ echo -n "Stopping $prog "
+ local count
+ (( count = 0 ))
+ while [ -n "$( ps axw | grep "[0-9]:[0-9][0-9] $DAEMON " )" ] ; do
+ (( count++ >= 10 )) &&
+ { echo -n ' give up' ; killall -TERM $DAEMON ; break ; }
+ echo -n .
+ killall -USR2 $DAEMON
+ sleep 3
+ done
+ echo
+ umount -a -f -t autofs
+ rm -f $lock
+ ;;
+ (reload|restart)
+ test -e $lock || { echo "Maybe $prog is not running" >&2 ; exit 1 ; }
+ echo "Checking for changes to /etc/auto.master:"
+ local nline new[] pid tt stat time oline old[]
+ while read nline ; do new[${#new[@]}]="$nline" ; done <<__EOF__
+$( getmounts )
+__EOF__
+ while read pid tt stat time oline ; do
+ old[${#old[@]}]="$oline"
+ for nline in "${new[@]}" ; do
+ test "$oline" = "$nline" && { oline= ; break ; }
+ done
+ test -n "$oline" &&
+ { echo " stop: $oline" ; kill -USR2 $pid ; sleep 1 ; }
+ done <<__EOF__
+$( ps axw | grep "[0-9]:[0-9][0-9] $DAEMON " )
+__EOF__
+ for nline in "${new[@]}" ; do
+ for oline in "${old[@]}" ; do
+ test "$nline" = "$oline" && { nline= ; break ; }
+ done
+ test -n "$nline" &&
+ { echo " start: $nline" ; $nline ; sleep 1 ; }
+ done
+ killall -HUP $DAEMON
+ sleep 1
+ ;;
+ (status)
+ status
+ ;;
+ (*)
+ echo "Usage: $0 {start|stop|reload|restart|status}" >&2
+ exit 1
+ ;;
+ esac
+}
+
RETVAL=0
-if [ $system = debian ]; then
- debian "$@"
-elif [ $system = redhat ]; then
- redhat "$@"
-fi
+$system "$@"
exit $RETVAL
^ permalink raw reply
* [Bridge] Re: [VLAN] newbie problems
From: Dante @ 2004-01-26 15:36 UTC (permalink / raw)
To: Justin Cormack; +Cc: vlan, bridge
In-Reply-To: <1074770372.9625.146.camel@lotte.street-vision.com>
Thanks for the reply.
You are quite right about the routing, and i've advanced to the bridging
part.
But it will not work. I've finaly gotten access to the switch it's
connected to and from the logs i've got this output:
Jan 26 16:49:56: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with
inconsistent peer vlan id 4 on GigabitEthernet0/1 VLAN40.
Jan 26 16:49:56: %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet0/1
on VLAN0004. Inconsistent peer vlan.
Jan 26 16:49:56: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet0/1
on VLAN0040. Inconsistent local vlan.
As the logs show, it's getting blocked.
It happens when i add the second vlan interface to the bridge (br0)
interface. The physical interface is still connected to the cisco switch
with a single cable to a trunked port.
I'm pasting the configuration of this port:
interface GigabitEthernet0/1
switchport trunk native vlan 10
switchport mode trunk
no ip address
duplex full
Pasting bridgeinfo:
root@testbridge:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000103bdb23b no eth0.4
eth0.40
(stp on/off have no diff)
Anyone got any good ideas? (design flaws?)
Posting this also to the bridging list
-Dante
> If you look at the output of route you will see that your default route
> for x.x.x.x.0/24 is eth0.4 as you set it up first. You can see hosts on
> eth0.40 if you set manual routes for them say. But just turn on bridging
> and it should work.
>
>
> On Thu, 2004-01-22 at 10:27, Dante wrote:
>> Hi.
>> I'm trying to get VLAN to work in a system i've already set up running
>> on
>> several NIC's.
>> It's basicly a bridge between two VLAN's. One is the "external" part,
>> and
>> one for "internal". The bridge is designed to make the the internal
>> clients log into it, authenticating the users, before leting them reach
>> the Internet. Its running "fine" with several NIC's and it's bridging
>> between two VLAN's, although it doesnt see them. (Non-trunked ports).
>>
>> |---------| |-------------| |-----------|
>> Inet | gw | VLAN 4 | bridge | vlan40 | clients |
>> <----| x.x.x.1 |--------| interface1 |--------| x.x.x.13+ |
>> | | ext | interface2 | int | |
>> |---------| |-------------| |-----------|
>>
>> interface1 = eth0 = x.x.x.11/24
>> interface2 = eth1 = x.x.x.12/24
>>
>> However, I'm trying to get it running on VLAN's, on trunked ports, and
>> bridge between those.
>> So far I'm having problem with the VLAN setup. (Not yet reached the
>> bridging part)
>>
>> I set the host running with one NIC, add it, add first virtual interface
>> (eth0.4), give it ip. And it's running smoothly. It's reaching the gw
>> and
>> hosts on the VLAN 4.
>> BUT, as I add second virtual interface (eth0.40), give it ip. It cannot
>> reach any of the hosts on VLAN 40.
>> I see with tcpdump and similar tools that it is sending it's packets
>> over
>> the first interface/VLAN 4 (eth0.4).
>>
>> |---------| |-------------| |-----------|
>> Inet | gw | VLAN 4 | bridge | vlan40 | clients |
>> <----| x.x.x.1 |--------| interface1 |--------| x.x.x.13+ |
>> | | ext | interface2 | int | |
>> |---------| |-------------| |-----------|
>>
>> interface1 = eth0.4 = x.x.x.11/24
>> interface2 = eth0.40 = x.x.x.12/24
>>
>> The bridge-host is a Slackware 9.1, with 2.4.24 kernel, vlan.1.8 (and
>> bridge-utils-0.9.6)
>>
>> I'm then wondering if i've got a design flaw in this setup? (I really
>> dont
>> want to subnet it. Since it's already working with 2 physical
>> interfaces)
>> I think it's probably a fairly easy solution here.. somewhere. But i'm
>> getting blind on this now.
>>
>> Cheers,
>> Dante
>> --
>> Not even the sun can banish the phantoms of our land.
>> Nevertheless, we huddle in the darkness and pray for dawn...
>>
>>
>> _______________________________________________
>> VLAN mailing list - VLAN@wanfear.com
>> http://www.WANfear.com/mailman/listinfo/vlan
>> VLAN Page: http://scry.wanfear.com/~greear/vlan.html
>
>
>
^ permalink raw reply
* linux-2.4.24 / promise supertrak100 / udma
From: Mike Gabriel @ 2004-01-26 15:34 UTC (permalink / raw)
To: linux-kernel; +Cc: gurus
hi there,
i am using a promise supertrak100 ide controller unter 2.4.24 on i386 on our
backupserver. the drives have been found and the md-driver is synchronizing
the raid. however, i cannot kick it into udma mode. when using hdparm, it
tells me:
galileo:/# hdparm /dev/i2o/hda
/dev/i2o/hda not supported by hdparm
what can i do, to enable udma (at least udma33 or udma66) on the controller?
mike
--
netzwerkteam - oekologiezentrum
Mike Gabriel
FA Geobotanik
Christian-Albrecht Universität zu Kiel
Abt. Prof. Dr. K. Dierßen
Olshausenstr. 75
24118 kiel
fon-oezk: +49 431 880 1186
fon-home: +49 431 64 74 196
mail: mgabriel@ecology.uni-kiel.de
http://www.ecology.uni-kiel.de
^ permalink raw reply
* Re: Q: Filesystem choice..
From: Jörn Engel @ 2004-01-26 15:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, Eric W. Biederman
In-Reply-To: <1075102799.17157.209.camel@lapdancer.baythorne.internal>
On Mon, 26 January 2004 07:40:00 +0000, David Woodhouse wrote:
>
> You want resv_blocks_write to be larger than resv_blocks_deletion, and I
> suspect you could get away with values of 2 and 1.5 respectively, if we
> were counting bytes rather than whole eraseblocks.
Hmm. Any special reason, why you don't always count in bytes? That
would even remove code, such as this line:
> size += c->sector_size - 1; /* ... and round up */
Jörn
--
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface.
-- Doug MacIlroy
^ permalink raw reply
* Re: [PATCH] Big powermac update
From: Tom Rini @ 2004-01-26 15:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, Linux Kernel list
In-Reply-To: <1075075758.848.34.camel@gaston>
On Mon, Jan 26, 2004 at 11:09:18AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2004-01-26 at 05:55, Tom Rini wrote:
> > On Sat, Jan 24, 2004 at 11:58:33AM +1100, Benjamin Herrenschmidt wrote:
> >
> > >
> > > >
> > > > Can you please put the 970 register definitions into
> > > > include/asm-ppc/reg_970.h or something along those lines?
> > >
> > > I won't create a file for 3 registers :) Also, HID2/3 are defined
> > > on other CPUs, as HIOR, none of these are strictly 970 specific
> > > in fact though we only use them on it (coment may need fixing, bu
> > > that's ok at this point).
> >
> > Are they found on regular, classic PPCs or just on others in the
> > 64bit family? The problem is we don't want to let <asm/reg.h> get to be
> > as bad as it used to be.
>
> HID2 exist on some 750FX afaik, HID3 and upper probably only on
> POWER4/GPUL at this point and HIOR is specific to HV capable CPUs,
> but then, afgain, it's only 3 registers :)
But that's how it starts out... :) If it turns out that you need to add
more regs in later, can you please move all of the POWER4/GPUL
definitions into their own file? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [Kernel-janitors] New guy here,
From: Arnd Bergmann @ 2004-01-26 15:28 UTC (permalink / raw)
To: kernel-janitors
On Sunday 25 January 2004 13:38, JOUANNE Mickael wrote:> I forget the patch :)
As a side note, you should insert patches directly instead ofattaching them for easier quoting.
> --- kj.pl 2004-01-05 21:04:37.000000000 +0100> +++ kj-new.pl 2004-01-25 11:38:08.000000000 +0100> @@ -109,7 +109,7 @@> print "$filename:$linenr:$line\n\n";> }> > - if ($line=~/MOD_{INC,DEC}_USE_COUNT/) {> + if ($line=~/MOD_(INC|DEC)_USE_COUNT/) {> print "Net drivers should call SET_MODULE_OWNER> instead of MOD_{INC,DEC}_USE_COUNT\n"; print "$filename:$linenr:$line\n\n";> }
You forgot to change the message as well. Note that SET_MODULE_OWNERhas become pointless as well, so at least it should not be advocatedany more.
Arnd <><
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: NFSv4 & /etc/exportfs
From: J. Bruce Fields @ 2004-01-26 15:27 UTC (permalink / raw)
To: Vincent ROQUETA; +Cc: nfs
In-Reply-To: <200401261544.07589.vincent.roqueta@ext.bull.net>
On Mon, Jan 26, 2004 at 03:44:07PM +0100, Vincent ROQUETA wrote:
> I tried to mount a directory using the old nfs conf. format (as indicated in
> the man) and using the new one, as described here :
> http://www.citi.umich.edu/projects/nfsv4/june_2002_rel/exports.html
That's very out of date; the format described there was for a much older
version of the code and will probably never be used. See
http://www.citi.umich.edu/projects/nfsv4/linux/ for instructions on
exporting to nfsv4. The idea is to use the fsid=0 option to mark one
export as the nfsv4 "pseudofilesystem root" (the filesystem clients will
get if they mount yourserver:/) and then attach other exports underneath
it using mount --bind.
--Bruce Fields
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: MD Oops on boot with 2.6.2-rc1-mm3
From: Jonathan Kamens @ 2004-01-26 15:26 UTC (permalink / raw)
To: Walt H; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <40146B68.6070007@comcast.net>
Yes, backing out md-06-allow-partitioning.patch fixed the MD Oops on
boot for me as well. Thanks, Andrew and Walt, for the quick response!
jik
^ permalink raw reply
* Re: REISER4 corruptions errors
From: Alex Zarochentsev @ 2004-01-26 15:26 UTC (permalink / raw)
To: Paolo Correnti; +Cc: Nikita Danilov, REISER LIST
In-Reply-To: <20040126142528.22476.qmail@web21509.mail.yahoo.com>
On Mon, Jan 26, 2004 at 06:25:28AM -0800, Paolo Correnti wrote:
>
> --- Nikita Danilov <Nikita@Namesys.COM> wrote:
>
> > Well, for all I know, this very well may be a bug in
> > the fsck, rather than corruption of the on-disk data
> > structures. Are
> > you experiencing any
> > problems when _using_ this partition (error messages
> > in the kernel log,
> > crashes, deadlocks, etc.)?
> >
>
> I have problems using the "20040119-fixed" partition
> with 2.6.1 (after writing many MB of data, almost
> always I obtain a file corrupted so that Oracle
> doesn't start). With 2.6.0 and 20031223 snapshot I
> have no problems using the "20031223" partition.
>
> But in both tests I saw that fsck.reiser4 gave me
> from 5 to 35 and more corruptions errors, all of type
>
> Error: Node (210326), item (7): StatData of the file
> [10001:1616662635f5445:10002] has the wrong bytes
> (3625472), Should be
> (3629056). Plugin (stat40).
>
> So I was thinking (perhaps strangely ...) that this
> kind of corruption was more dangerous with 2.6.1 +
> 20040119-fixed (I'm speaking about Oracle logfile
I guess it is not a dangerous corruption. Probaply Oracle does too strong
checks for its log files. The file content and size should be OK, except
i_blocks and i_bytes fields.
I think the source of that curruption is in the reiser4 deletion optimization
performed by the cut_tree() routine (inode_sub_bytes() is not called in some
cases).
this patch should help (! not tested):
===== tree.c 1.562 vs edited =====
--- 1.562/tree.c Wed Jan 14 11:46:20 2004
+++ edited/tree.c Mon Jan 26 18:24:39 2004
@@ -1468,7 +1468,7 @@
if ((result != 0) && (result != -E_NO_NEIGHBOR))
break;
/* Check can we delete the node as a whole. */
- if (iterations && znode_get_level(node) == LEAF_LEVEL &&
+ if (0 && iterations && znode_get_level(node) == LEAF_LEVEL &&
UNDER_RW(dk, current_tree, read,
keyle(from_key, znode_get_ld_key(node)))) {
result = delete_node(next_node_lock.node,
> corrupted after 5 million rows written) than with
> 2.6.0 + 20030123 (which never gave me an Oracle file
> corrupted, also after 10 million rows written).
>
> I made the same test on 2 different disks so I'm
> almost sure this is not an hardware problem.
>
> Best regards
>
> Paolo
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
--
Alex.
^ permalink raw reply
* Re: [RFC/PATCH] IMQ port to 2.6
From: Tomas Szepe @ 2004-01-26 15:24 UTC (permalink / raw)
To: Vladimir B. Savkin; +Cc: jamal, linux-kernel, netdev
In-Reply-To: <20040126135545.GA19497@usr.lcm.msu.ru>
On Jan-26 2004, Mon, 16:55 +0300
Vladimir B. Savkin <master@sectorb.msk.ru> wrote:
> +---------+ +-ppp0- ... - client0
> | +-eth1-<+-ppp1- ... - client1
> Internet ----- eth0-+ router | . . . . . . . .
> | +-eth2-< . . . . . .
> +---------+ +-pppN- ... - clientN
Actually, this is very much like what we're using IMQ for:
+-----------+ eth1 --- \
| shaper + eth2 ---
Internet --- eth0 + in bridge + . --- ... WAN (10 C's of customer IPs)
| setup + . ---
+-----------+ ethN --- /
We're shaping single IPs and groups of IPs, applying tariff rates
on the sum of inbound and outbound flow (this last point, I'm told,
is the primary reason for our use of IMQ). The machine also does
IP accounting (through custom userland software based on libpcap)
and has to be an ethernet bridge so that it can be replaced by
a piece of wire should it fail and there was no backup hardware left.
At this moment we're on sfq/u32/htb/IMQ/mangle. We've figured out
that unless we mess with iptable_nat, IMQ-enabled kernels will work
perfectly reliably (SNAT in particular seems deadly). We don't
insist on IMQ. In fact, we would be very grateful if somebody
could point us to an alternative mechanism to IMQ that would allow
us to effectively shape by the sum of both traffic directions of
a given IP, as we'd like to deploy "shaping firewalls" that would
also do SNAT.
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Karim Yaghmour @ 2004-01-26 15:20 UTC (permalink / raw)
To: Rik van Riel; +Cc: Nuno Silva, JustFillBug, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401260633280.26321-100000@chimarrao.boston.redhat.com>
Rik van Riel wrote:
>>So, for example, Xen assumes that all OSes are going to use the same
>>devices for I/O: same disk, same NIC, etc. It therefore implements lots
>>of virtual devices for these.
>
>
> Consolidation means more efficient hardware use ...
In the case of a UP system, it may ... depending on what you're
trying to do. On an SMP system or an SMP-cluster, however,
consilidation is likely to mean loss of performance.
>>Wouldn't it be just better to reuse the existing work on the hotplug
>>hardware (hotplug CPU, hotplug memory, etc.) to have the kernels
>>get/return hardware resources to the nanokernel?
>
>
> That means a loss of flexibility.
It depends on your setup. In the case of an SMP-cluster where all
OS instances are launched at startup, where runtime setup
modification can be costly because of global table changes, and
where centralization is to be avoided in as much as possible, then
the hotplug capabilities are probably the best way to go. If there's
a desire to have both capabilities (fine-grain allocation and
gross-grain allocation) in whatever is finally adopted, then that's
something to keep in mind. I guess I'm just saying that there are pros
and cons, depending on your setup.
> Furthermore, these hotplug
> patches don't seem ready yet.
Yes, I'm aware of this. There are other components of a truely
generic virtualization interface which are missing. Does that mean
we shouldn't think ahead?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* NFSv4 & /etc/exportfs
From: Vincent ROQUETA @ 2004-01-26 14:44 UTC (permalink / raw)
To: nfs
I tried to mount a directory using the old nfs conf. format (as indicated in
the man) and using the new one, as described here :
http://www.citi.umich.edu/projects/nfsv4/june_2002_rel/exports.html
I used nfs-util 1.0.6 (tarball version)
Well...
Using old format
1/ I can't mount the directory for rw... I tried approximatly all.
Using the new one:
It seem the program exportfs 1.0.6 don't understand the new datas formats
(that's confirmed by source code where I can't see the keyword "pseudo" for
example)
So, is the new format supported by a version of exports, and where can I
download the code?
If this new format is not supported at all, howto configure nfsv4 with the old
one?
Thank you
Vincent ROQUETA
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: nforce2 ethernet driver
From: Carl-Daniel Hailfinger @ 2004-01-26 15:12 UTC (permalink / raw)
To: cityhunter; +Cc: netdev
In-Reply-To: <40152E10.6040901@gmx.net>
Carl-Daniel Hailfinger wrote:
> cityhunter wrote:
>
>>hello,
>>I found that you writed a kernel module for nvdia nforce ethenet.
>>your site have a lot of kernel patch for the "forcedeth.c" file that I
>>can't find in my 2.6.1 kernel archive....
>>can you tell me where to get it?
>
>
> You need at least 2.6.1-rc1 for the latest forcedeth patch.
Sorry, that should have been 2.6.2-rc1
>
> HTH,
> Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: nforce2 ethernet driver
From: Carl-Daniel Hailfinger @ 2004-01-26 15:11 UTC (permalink / raw)
To: cityhunter; +Cc: netdev
In-Reply-To: <40151D7D.5030600@laposte.net>
cityhunter wrote:
> hello,
> I found that you writed a kernel module for nvdia nforce ethenet.
> your site have a lot of kernel patch for the "forcedeth.c" file that I
> can't find in my 2.6.1 kernel archive....
> can you tell me where to get it?
You need at least 2.6.1-rc1 for the latest forcedeth patch.
HTH,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [PATCH] possible fix for misbehaving hdsp
From: Takashi Iwai @ 2004-01-26 15:09 UTC (permalink / raw)
To: Thomas Charbonnel; +Cc: alsa-devel
In-Reply-To: <40152A0E.3020206@undata.org>
At Mon, 26 Jan 2004 15:54:06 +0100,
Thomas Charbonnel wrote:
>
> Takashi Iwai a écrit :
> > At Mon, 26 Jan 2004 14:54:42 +0100,
> > Thomas Charbonnel wrote:
> >
> >>[1 <text/plain; us-ascii (7bit)>]
> >>Hi,
> >>
> >>Could people experiencing problems with their hdsp (namely Tim and Paul)
> >>try the attached patch ?
> >
> >
> > it includes a non-ASCII letter
> >
> >
> >>+ /* From Martin Bj?en :
> >
> >
> > can it be replaced with oe or something else?
> >
> >
> > Takashi
> >
> >
>
> Of course -> Martin Bjoernsen.
ok, i applied the patch to cvs.
> IIRC, there is another occurence of this in the driver code, if you want
> to fix it also.
yep, there it is. but i don't think it's necessary to remove it
unless someone complains :)
i asked it because i'm using UTF-8 as default now.
the handling of non-ASCII via cvs/bk is very sensitive.
thanks,
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [LARTC] IMQ Runtime error
From: Andy Furniss @ 2004-01-26 15:09 UTC (permalink / raw)
To: lartc
In-Reply-To: <1075073625.40145259a53ea@mail.psnet.gov.ng>
Roy wrote:
> even if imq is quite useless right now
I thought it was OK for inbound traffic.
What sort of load/traffic do you see crashes with.
I have an old P200 as a gateway and can run bittorrents on it, with IMQ
doing outbound for locally generated traffic (not that I really need
to) and can do > a gig/day without ever crashing. I do close down at
night though, and only have 256/512 bandwidth. Is this way below what
you need to do to crash?
> this eeror is caused probably by other loaded modules for userspace queue
> nf_queue probably
> since imq uses the same function
Yea this is a pain, I would like to run a userspace for up and IMQ for down,
but can't use lib_ipq at the same time as IMQ.
It has been suggested that I can work round this, but I haven't tried yet.
Do you think it's possible?
Andy.
> ----- Original Message -----
> From: "tc" <tc@me.net.ng>
> To: <lartc@mailman.ds9a.nl>
> Sent: Monday, January 26, 2004 1:33 AM
> Subject: [LARTC] IMQ Runtime error
>
>
>
>>hi all, i have applied all patches and compiled the kernel
>>(2.4.21), iptables
>>(1.2.9) and iproute2 (2.4.7-now-ss020116) however when i run '"'modprobe
>
> imq
>
>>numdevs=1'"', the system returns - imq.o: init_module: Device or resource
>
> busy
>
>>the transcript is below -
>>
>>[root@vmlinux project]# modprobe imq numdevs=1
>>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: init_module: Device or
>
> resource
>
>>busy
>>Hint: insmod errors can be caused by incorrect module parameters,
>
> including
>
>>invalid IO or IRQ parameters.
>> You may find more information in syslog or the output from dmesg
>>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod
>>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o failed
>>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod imq failed
>>
>>what could be wrong? thanks all,
>>bye
>>joseph
>>_______________________________________________
>>LARTC mailing list / LARTC@mailman.ds9a.nl
>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ 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.