* Re: New NUMA scheduler and hotplug CPU
From: Andrew Theurer @ 2004-01-27 2:19 UTC (permalink / raw)
To: Martin J. Bligh, Nick Piggin; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <35060000.1075162177@flay>
On Monday 26 January 2004 18:09, Martin J. Bligh wrote:
> > For example, you boot on just the boot cpu, which by default is in the
> > first node on the first runqueue. All other cpus, whether being "booted"
> > for the for the first time or hotplugged (maybe now there's really no
> > difference), the hotplugging tells where the cpu should be, in what node
> > and what runqueue. HT cpus work even better, because you can hotplug
> > siblings, once at a time if you wanted, to the same runqueue. Or you
> > have cpus sharing a die, same thing, lots of choices here. This removes
> > any per-arch updates to the kernel for things like scheduler topology,
> > and lets them go somewhere else more easily changes, like userspace.
>
> Ummm ... but *none* of that is dictated as policy stuff - it's all just
> the hardware layout of the machine. You cannot "decide" as the sysadmin
> which node a CPU is in, or which HT sibling it has. It's just there ;-)
> The only thing you could possibly dictate is the CPU number you want
> assigned to the new CPU, which frankly, I think is pointless - they're
> arbitrary tags, and always have been.
How many cpus share a runqueue IMO could be a policy thing. Some HT cpus may
be better sharing a runqueue where others (lots and lots of siblings in one
core) may not.
^ permalink raw reply
* udev dri directory rule
From: Jon Smirl @ 2004-01-27 2:16 UTC (permalink / raw)
To: linux-hotplug
Would this line:
KERNEL="card*", NAME="dri/card%n"
be better written as:
KERNEL="card*", NAME="dri/%k"
I noticed everything else is using %k
==Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
-------------------------------------------------------
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
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [linux-lvm] Re: LVM2 + Linux 2.6.1 questions
From: Dale Gallagher @ 2004-01-27 2:15 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20040127001252.A21930@cs.mcgill.ca>
> Måns Rullgård <mru@kth.se> wrote:
> > I see the /dev/vg/link name.
> Navindra Umanee <navindra@cs.mcgill.ca> wrote:
> Mine shows /dev/mapper/vg-link too. I would definitely
> prefer
> /dev/vg/link because at least it's not implementation
> dependent... but
> I guess it's mostly an aesthetic thing.
>
> Any idea why yours is different? Different version of
> mount maybe?
> Using mount-2.11z here...
I have mount-2.12 and and df (coreutils) 5.0
Dale
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: Linus Torvalds @ 2004-01-27 2:09 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: gotom, akpm, linux-kernel
In-Reply-To: <UTC200401270156.i0R1uiR06609.aeb@smtp.cwi.nl>
On Tue, 27 Jan 2004 Andries.Brouwer@cwi.nl wrote:
>
> But you see, it wasn't the user at all, and it wasn't a ufs filesystem.
> It is kernel probing that causes error messages. That is unwanted.
> So, your version is wrong.
Yes.
However, I think the _real_ bug is that we have reiserfs near the tail of
filesystems to try.
The filesystems in fs/Makefile are listed in order of being probed, so I
really thing the real fix is to ignore the whole verbose thing entirely,
and just move reiserfs upwards.
Because if you actually get far enough that you try to mount UFS as your
root filesystem, you have other problems, and verbosity at boot is not
your real issue.
Can you test that alternate patch instead?
Linus
^ permalink raw reply
* Re: Firewall four nics, two separate routes
From: Alexis @ 2004-01-27 2:08 UTC (permalink / raw)
To: netfilter
In-Reply-To: <KMS-272302109-548@mail.espgroup.net>
think lan1 lan2 wan1 wan2
the firewall box, must have NO defaul route
ip rule add from lan1 lookup table 5
ip rule add from lan2 lookup table 6
ip route add default via wan1 table 5
ip route add default via wan1 table 6
thats it.
----- Original Message -----
From: "Ryan Johnson" <rjohnson@espgroup.net>
To: <netfilter@lists.netfilter.org>
Sent: Monday, January 26, 2004 2:49 PM
Subject: Firewall four nics, two separate routes
Hi all,
I have a firewall with four nics, two external nics with two public ips and
two internal nics with private ips (two different networks). What I would
like to do is force all traffic from each internal network to its
corresponding external nic. I believe the only solution to this is to use
iproute2, but I have had to luck. So traffic from internal net1 will be
routed out external nic1, then the other side, internal net2 will be routed
out the external nic2. Internal net1 traffic should never go out external
nic2 and internal net2 traffic should never go out external nic1.
Thank you in advance,
Ryan
Ryan Johnson
Security Architect
ESP Group
^ permalink raw reply
* [LARTC] connbytes and connmark
From: Roy @ 2004-01-27 2:03 UTC (permalink / raw)
To: lartc
I need them both but POM fefuses to include them in kennes saying that they
are incompatible
what is that nonsense?
anybody have them both at once?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: PPTP connection tracking and Poptop on same box
From: Harald Welte @ 2004-01-27 2:00 UTC (permalink / raw)
To: Antony Stone; +Cc: netfilter, Carl Farrington
In-Reply-To: <200401190003.32170.Antony@Soft-Solutions.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On Mon, Jan 19, 2004 at 12:03:32AM +0000, Antony Stone wrote:
> On Sunday 18 January 2004 11:47 pm, Carl Farrington wrote:
>
> > From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
> >
> > > On Sunday 18 January 2004 11:00 pm, Carl Farrington wrote:
> > > > Does anybody know if there is a workaround for this problem? As soon
> > > > as I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
> > > > connections.
> >
> > > Why do you want to use both of these on the same box?
>
> > Well, I want to do both. I am putting together a router/gateway box. It
> > performs NAT for all the workstations on the private side of the box
> > (hence the need for ip_nat_pptp since some workstations need to contact
> > outside pptp servers), and also allows access from the outside when
> > users are roaming (hence the need for poptop).
> >
> > Astaro Security Linux (www.astaro.com) is one product which achieves
> > this without problem using poptop, as is win2k rras.
>
> In that case your simplest solution might be to ask Astaro how they've done
> it. Their products are based on Linux / netfilter etc, so should be fully
> GPL.
If you read the PPTP helper sourcecode, you will find that I wrote it
for astaro. There's no black magic in ASL, they're using the same code
that is in patch-o-matic.
Carl: Are you sure you are running the latest pptp helper from
patch-o-matic (20031219) ?
> Antony
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: Andries.Brouwer @ 2004-01-27 1:56 UTC (permalink / raw)
To: Andries.Brouwer, gotom; +Cc: akpm, linux-kernel, torvalds
From gotom@debian.or.jp Tue Jan 27 02:44:00 2004
I wonder this modification is really ok because user can't find why he
can't mount his ufs if he does not specify ufstype=. Putting only
one line is not acceptable for you?
But you see, it wasn't the user at all, and it wasn't a ufs filesystem.
It is kernel probing that causes error messages. That is unwanted.
So, your version is wrong.
If it is really very desirable to warn the user the condition if(!silent)
should be added.
But in my opinion such a warning is not desirable at all.
mount(8) and Documentation/filesystems/ufs.txt explain the details.
Andries
^ permalink raw reply
* Re: per-connection byte counts
From: Harald Welte @ 2004-01-27 1:56 UTC (permalink / raw)
To: wysiwyg, netfilter
In-Reply-To: <20040120221259.GA4354@glympton.airtime.co.uk>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Tue, Jan 20, 2004 at 10:12:59PM +0000, Adam Rice wrote:
> Quoting Nuno Miguel Pais Fernandes (npf@eurotux.com):
> > Try http://luxik.cdi.cz/~devik/connbytes/
> >
> > It works very well....
>
> Thanks, that's exactly what I wanted! Pity it seems to be unmaintained. Still,
> it's simple enough that that shouldn't matter for the time being.
erm, connbytes is even in patch-o-matic...
> Adam
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.2-rc1-mm1 pppd: page allocation failure (fwd)
From: haiquy @ 2004-01-27 14:56 UTC (permalink / raw)
To: linux-kernel
Hi,
Sorry for the delay but I have still unable to reproduce the bug when
when compiling use standard CFLAGS in the kernel Makefile.
Best regard,
Steve Kieu
---------- Forwarded message ----------
Date: Sat, 24 Jan 2004 12:38:41 +0000 (UTC)
From: haiquy@yahoo.com
Reply-To: s_kieu@hotmail.com
To: linux-kernel@vger.kernel.org
Subject: 2.6.2-rc1-mm1 pppd: page allocation failure
Hi,
This did not happen with 2.6.1-mm4 . The system is still running fine
at the moment but I find several message in the dmesg output
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
If some one need further testing or information pls cc me.
Steve Kieu
^ permalink raw reply
* Re: PPTP - more connections from a NATed LAN to LAN behind PPTP Linux box doesn't work
From: Harald Welte @ 2004-01-27 1:54 UTC (permalink / raw)
To: Unzeitig Lumir; +Cc: netfilter
In-Reply-To: <0807917940AEF54F9A0C3096A0ED03AB40EDD0@gatc-ex1.gatc.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Wed, Jan 21, 2004 at 03:47:25PM +0100, Unzeitig Lumir wrote:
> Hi,
> I applied the PPTP patch and it solved what I needed. (=more connections
> from NATed LAN behind Linux box to a PPTP server) - it's OK.
> But oposit direction (=more connections from NATed LAN behind a PPTP
> server to theLAN which is behind PPTP Linux box) works only for 1 PPTP
> client. It stays in verification process and ends by error.
Sorry, I have no idea what you are talking about. Please describe more
detailed what exactly you want to do. Please try to use more precise
terms (no idea what 'theLAN' and your 'pptp linux box' should mean).
> Thanks
> Lumir Unzeitig
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is source in CVS broken, or is it just me?
From: Justin Turner Arthur @ 2004-01-27 1:56 UTC (permalink / raw)
To: ALSA Development
In-Reply-To: <Pine.LNX.4.58.0401262010410.2959@pnote.perex-int.cz>
Jaroslav Kysela wrote:
>Use latest 2.6.2-rc kernels.
>
>
>
Thanks for the tip, Mr. Kysela. Upon patching to the 2.6.2rcX kernel,
and re-application of the ALSA cvs checkout, I'm up and running with a
working ice1712 driver and no compile errors. Hot-diggity!
Thanks again,
Justin Arthur
-------------------------------------------------------
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: two eth devices ...
From: Ray Olszewski @ 2004-01-27 1:53 UTC (permalink / raw)
To: rgomez, linux-newbie
In-Reply-To: <4011C87400000C1A@mail-bcm02.alestra.net.mx>
At 06:46 PM 1/26/2004 -0600, rgomez@bancomer.com wrote:
>I have 2 interfaces, but i don't know what to do with
First, let's keep this discussion on the list, not private. So I've added
the list back in with this reply.
Second, as I look at the interface data, the packet counts make it clear
that both are being used ... about equally for incoming traffic, but
heavily favoring eth0 for outgoing packets. A look at your routing table
("netstat -nr" is one way to view it) will probably explain the TX imbalance.
Without knowing more about your setup ... for example, why the two
interfaces are on different Ip networks (do they connect to the same or to
different physical networks?), what services the host is running, what mix
of LAN and Internet services the host accesses and how (what the routing
table looks like is most of the "how" part) ... it is hard to recommend
anything.
Really, from the standpoint of Linux, the system seems to be working. If
you want to disable an interface temporarily, you *probably* want to use
the command
ifdown eth0
or
ifdown eth1
But the question of *whether* you should be running one or two interfaces
really is better posed to the sysadmin at your site ... it is not
particularly a Linux question. If his or her answer poses any issues that
seem specific to Linux, then that would be a good time to come back here.
For example, I think I saw another message from you, earlier today, asking
about controlling how the host accesses squid. It was too vague for me to
reply to, but now that I see you have interfaces on different networks, the
system's routing table should control which interface handles squid traffic
(assuming the squid server is local, on one or the other network).
># if config -a
>eth0 Link encap:Ethernet HWaddr 00:C0:4F:97:2D:8D
> inet addr:150.100.106.24 Bcast:150.100.106.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:301002 errors:3 dropped:0 overruns:0 frame:3
> TX packets:13656 errors:0 dropped:0 overruns:0 carrier:14
> collisions:791 txqueuelen:100
> RX bytes:97659433 (93.1 Mb) TX bytes:1976281 (1.8 Mb)
> Interrupt:11 Base address:0xec80
>
>eth1 Link encap:Ethernet HWaddr 00:A0:24:0B:56:3C
> inet
> addr:150.100.107.199 Bcast:150.100.107.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:290096 errors:3 dropped:0 overruns:0 frame:3
> TX packets:1163 errors:0 dropped:0 overruns:0 carrier:0
> collisions:62 txqueuelen:100
> RX bytes:94395209 (90.0 Mb) TX bytes:112613 (109.9 Kb)
> Interrupt:10 Base address:0x230
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:297 errors:0 dropped:0 overruns:0 frame:0
> TX packets:297 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:32918 (32.1 Kb) TX bytes:32918 (32.1 Kb)
>
># ip link show
>1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:c0:4f:97:2d:8d brd ff:ff:ff:ff:ff:ff
>3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:a0:24:0b:56:3c brd ff:ff:ff:ff:ff:ff
>
># uname -a
>Linux naboo 2.4.20-8 #1 Thu Mar 13 16:42:56 EST 2003 i586 i586 i386 GNU/Linux
>
>::::::::::::::
>/etc/sysconfig/networking/profiles/default/ifcfg-eth0
>::::::::::::::
>DEVICE=eth0
>ONBOOT=yes
>BOOTPROTO=dhcp
>TYPE=Ethernet
>USERCTL=no
>PEERDNS=no
>::::::::::::::
>/etc/sysconfig/networking/profiles/default/ifcfg-eth1
>::::::::::::::
>DEVICE=eth1
>ONBOOT=yes
>BOOTPROTO=dhcp
>TYPE=Ethernet
>USERCTL=no
>PEERDNS=no
[old stuff deleted]
-
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: [PATCH] cpqarray update
From: Jeff Garzik @ 2004-01-27 1:51 UTC (permalink / raw)
To: Wiran, Francis; +Cc: Linux Kernel Mailing List
In-Reply-To: <CBD6B29E2DA6954FABAC137771769D6504E15965@cceexc19.americas.cpqcorp.net>
Wiran, Francis wrote:
>>You need to check the return value of pci_module_init() for errors.
>
> No, because the return value is determined from number of ctrls found,
> and not from function return.
>
> int __init cpqarray_init(void)
> {
> ...
> pci_module_init(&cpqarray_pci_driver);
> cpqarray_eisa_detect();
>
> for(i=0;i<MAX_CTLR;i++) {
> if(hba[i] != NULL)
> num_ctlrs_reg++
> }
>
> return (num_ctlrs_reg);
> }
>
> int __init cpqarray_init_module(void)
> {
> if (cpqarray_init() == 0)
> return -ENODEV;
> return 0;
> }
Nope, this needs to be turned inside out. The proper PCI driver looks like
static int __init cp_init (void)
{
return pci_module_init (&cp_driver);
}
static void __exit cp_exit (void)
{
pci_unregister_driver (&cp_driver);
}
We already handle the cases you describe. The cpqarray code -breaks-
the API design by doing it this way.
cpqarray does not fully support the pci_ids features and hotplug without
this.
Jeff
^ permalink raw reply
* Re: Problem using fwmarks as routing key: "MASQUERADE: Route sent us somewhere else."
From: Harald Welte @ 2004-01-27 1:51 UTC (permalink / raw)
To: Thhoep; +Cc: netfilter, netdev, Netfilter Development Mailinglist
In-Reply-To: <001c01c3e043$93583cd0$1684188d@Kiste>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On Wed, Jan 21, 2004 at 06:25:22PM +0100, Thhoep wrote:
> hi,
>
> my aim: to divide 100 hosts upon 6 masqueraded adsl connections to the
> internet using a linux router runnig a debian woody.
>
> the problem: really strange behaviour of the routing/masquerading combo,
> that changes with every tried kernel version. (described below)
>
> presumption: some version mismatch or a bug in the kernel routing code,
> which needs a bugfix that till now is unknown to me
Please read the recent archives of the netdev list with regard to
"Rusty's brain broke". Also see
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=144
Alexey heavily argued against us reverting that change, however :(
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: iptables NAT with "policy routing?"
From: Harald Welte @ 2004-01-27 1:47 UTC (permalink / raw)
To: Brian Capouch; +Cc: netfilter
In-Reply-To: <400F7264.1080201@palaver.net>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Thu, Jan 22, 2004 at 01:49:08AM -0500, Brian Capouch wrote:
> I have had to temporarily use a table-based route for one of my networks
> for administrative reasons, e.g.
this should work just fine.
> I suspect though, that this mode of routing (as opposed to using the
> "regular" table via "route add default") is somehow hosing my iptables NAT?
>
> At least sniffing the egress interface now shows the traffic heading out
> with its NATted address of 192.168.1.10.
did you try that with a connection that was established before you
inserted the new NAT rule (also, if you test with a ping, you need to
stop it to be recognized as new connection).
LARTC mailinglist might give you some better feedback.
> Thx.
> B.
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: GOTO Masanori @ 2004-01-27 1:43 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: akpm, torvalds, linux-kernel
In-Reply-To: <UTC200401250017.i0P0Hlc09374.aeb@smtp.cwi.nl>
At Sun, 25 Jan 2004 01:17:47 +0100 (MET),
Andries.Brouwer@cwi.nl wrote:
> Installed some machine with a reiserfs rootfs.
> The boot messages contain a lot of garbage spouted by Intermezzo
> and ufs_read_super caused by the fact that the kernel tried lots
> of other filesystems before hitting on reiserfs.
>
> On the one hand this is solved by "rootfstype=reiserfs".
>
> But on the other hand, the kernel should not complain about the
> guessing it does itself. There is a parameter "silent" for this
> purpose, but in this case I think it cleaner just to remove the
> complaint and tighten the requirement.
I wonder this modification is really ok because user can't find why he
can't mount his ufs if he does not specify ufstype=. Putting only
one line is not acceptable for you?
Regards,
-- gotom
--- fs/ufs/super.c 2003-10-20 12:50:24.000000000 +0900
+++ fs/ufs/super.c.new 2004-01-27 10:18:22.000000000 +0900
@@ -517,11 +517,8 @@
goto failed;
}
if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE)) {
- printk("You didn't specify the type of your ufs filesystem\n\n"
- "mount -t ufs -o ufstype="
- "sun|sunx86|44bsd|old|hp|nextstep|netxstep-cd|openstep ...\n\n"
- ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, "
- "default is ufstype=old\n");
+ printk("to mount ufs, specify -o ufstype="
+ "sun|sunx86|44bsd|old(default)|hp|nextstep|netxstep-cd|openstep\n");
ufs_set_opt (sbi->s_mount_opt, UFSTYPE_OLD);
}
^ permalink raw reply
* Re: Encrypted Filesystem
From: Andy Isaacson @ 2004-01-27 1:42 UTC (permalink / raw)
To: Adam Sampson; +Cc: linux-kernel
In-Reply-To: <y2ar7xmkyqe.fsf@cartman.at.fivegeeks.net>
On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> Michael A Halcrow <mahalcro@us.ibm.com> writes:
> > - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
>
> Going off on a tangent...
>
> There are all sorts of potentially-interesting things that could be
> done if Linux had a userspace filesystem mechanism included in the
> standard kernel -- as well as encryption, there's also network
> filesystems, various sorts of specialised caching (such as Zero
> Install), automounter-like systems, prototyping and so on.
>
> Is there a technical reason that none of the userspace filesystem
> layers have been included in the stock kernel, or is it just that
> nobody's submitted any of them for inclusion yet?
There are a lot of subtle and not-so-subtle problems in this space.
For example, I really liked the paging example given in section 3.1 of
[Mazi2001].
[Mazi2001] "A toolkit for user-level file systems", David Mazieres,
Proceedings of the 2001 USENIX Technical Conference
available at http://www.fs.net/sfswww/pubs.html
-andy
^ permalink raw reply
* Re: ip_nat_ftp module and freeswan IPSEC module don't work together?
From: Harald Welte @ 2004-01-27 1:41 UTC (permalink / raw)
To: Rodre Ghorashi-Zadeh; +Cc: netfilter
In-Reply-To: <BAY10-F42llTdrrcwv1000519cf@hotmail.com>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Fri, Jan 23, 2004 at 02:41:46AM +0000, Rodre Ghorashi-Zadeh wrote:
> Hello,
> Any help regarding this matter would be greatly appreciated. Thanks in
> advance.
I have no idea how this could be caused. But it seems to me at the
first glance, that this is not a netfilter/iptables issue. It works
with a stock kernel... Maybe you should talk to the freeswan guys and
ask if somebody is able to come up with an explanation.
Also, please submit bug reports via bugzilla.netfilter.org instead of
posting to the mainlintlist, please.
thanks.
> ?odre
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Undelivered Mail Returned to Sender
From: Mail Delivery System @ 2004-01-27 1:40 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 563 bytes --]
This is the Postfix program at host miracle.advantest.co.jp.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<sam-/dgdK3Mrev6N8HZe81QOs0v2NXO6HgA6@public.gmane.org>: host setech.mei7.advantest.co.jp[10.57.11.86]
said: 550 <sam-/dgdK3Mrev6N8HZe81QOs0v2NXO6HgA6@public.gmane.org>... User unknown
[-- Attachment #2: Delivery error report --]
[-- Type: message/delivery-status, Size: 365 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 1725 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 83 bytes --]
The message contains Unicode characters and has been sent as a binary attachment.
[-- Attachment #3.1.2: Type: text/plain, Size: 193 bytes --]
------------------ Virus Warning Message (on miracle.advantest.co.jp)
message.pif is removed from here because it contains a virus.
---------------------------------------------------------
^ permalink raw reply
* Re: NVidia and 2.6.1
From: Christian Unger @ 2004-01-27 1:39 UTC (permalink / raw)
To: Max Valdez; +Cc: Linux Kernel List
In-Reply-To: <1075158281.4775.13.camel@garaged.homeip.net>
On Tuesday 27 January 2004 10:04, you wrote:
> Did you changed anything on your bios ??
>
No actually.
Dropped in the Slackware 9.1 CDs (official ones, last ones were of the net),
typed reboot,
typed setup,
formated the disk (mountpoints, swap etc)
told it to install everything,
hit ctrl+alt+delete,
extracted the kernel sources,
told it to use my previous (backed up) config file,
compiled and installed everything,
typed reboot,
made the nvidia drivers of the pre-patched stuff.
In there was some minor arguments with XFree86's config regarding my mouse.
but the drivers worked straight up this time.
--
with kind regards,
Christian Unger
- < > - < > - < > - < > - < > - < > - < > - < > -
Alt. Email: chakkerz_dev@optusnet.com.au
ICQ: 204184156
Mobile: 0402 268904
Web: http://naiv.sourceforge.net
^ permalink raw reply
* RE: [PATCH] cpqarray update
From: Wiran, Francis @ 2004-01-26 22:32 UTC (permalink / raw)
To: Jeff Garzik, Linux Kernel Mailing List
> You need to check the return value of pci_module_init() for errors.
No, because the return value is determined from number of ctrls found,
and not from function return.
int __init cpqarray_init(void)
{
...
pci_module_init(&cpqarray_pci_driver);
cpqarray_eisa_detect();
for(i=0;i<MAX_CTLR;i++) {
if(hba[i] != NULL)
num_ctlrs_reg++
}
return (num_ctlrs_reg);
}
int __init cpqarray_init_module(void)
{
if (cpqarray_init() == 0)
return -ENODEV;
return 0;
}
regards,
-francis-
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Monday, January 26, 2004 2:15 PM
> To: Linux Kernel Mailing List; Wiran, Francis
> Subject: Re: [PATCH] cpqarray update
>
>
> Linux Kernel Mailing List wrote:
> > ChangeSet 1.1288, 2004/01/26 16:58:21-02:00, francis.wiran@hp.com
> >
> > [PATCH] cpqarray update
> >
> > Yes, we should. I usually ask Mike Miller in our group
> to send my
> > patches since he's been doing that and more known in
> the community, but
> > since you already got a hold of it ...yes, please :)
> >
> > CHANGELOG:
> >
> > * Fix for eisa card not detecting partitions properly
> > * Use pci_module_init instead of pci_register_device
> to handle hotplug
> > scenario and unregister if the driver can't find
> pci controller
> > * Add BLKSSZGET ioctl
> [...]
> > @@ -616,7 +623,7 @@
> >
> > /* detect controllers */
> > printk(DRIVER_NAME "\n");
> > - pci_register_driver(&cpqarray_pci_driver);
> > + pci_module_init(&cpqarray_pci_driver);
> > cpqarray_eisa_detect();
> >
> > for(i=0; i< MAX_CTLR; i++) {
>
> You need to check the return value of pci_module_init() for errors.
>
> Jeff
>
>
>
>
^ permalink raw reply
* Re: Translators of howto in french
From: Harald Welte @ 2004-01-27 1:37 UTC (permalink / raw)
To: Guillaume Audirac; +Cc: netfilter
In-Reply-To: <1074931376.1817.9.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
On Sat, Jan 24, 2004 at 09:02:57AM +0100, Guillaume Audirac wrote:
> Hello,
>
> Some howtos in french (at www.netfilter.org) need revision and/or
> update. Previous translators don't seem to do this work.
> Thanks to tell me if you know some translations are already underway. If
> not, I could take some time to do so.
> For information, a french site (www.traduc.org) is well organized to
> follow general linux translations.
The old translations were done by Fabrice Marie, IIRC. Please contact
him and discuss how to proceed.
We'd certainly love ot have up-to-date translations.
> Bye.
> Guillaume
> guillaume(dot)audirac(at)netpratique(dot)fr
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* bk pull on ia64 linux tree
From: David Mosberger @ 2004-01-27 1:37 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401121658240.14305@evo.osdl.org>
Hi Linus,
please do a
bk pull http://lia64.bkbits.net/to-linus-2.5
This will update the files shown below (only ia64-specific files are
touched).
Thanks!
--david
include/asm-ia64/machvec_sn1.h | 85 -----------------
arch/ia64/Kconfig | 149 +++++++++++++-----------------
arch/ia64/hp/common/sba_iommu.c | 17 +++
arch/ia64/kernel/entry.S | 53 ++++++++--
arch/ia64/kernel/ia64_ksyms.c | 8 +
arch/ia64/kernel/irq_lsapic.c | 5 -
arch/ia64/kernel/smpboot.c | 8 -
arch/ia64/kernel/time.c | 3
arch/ia64/sn/io/sn2/xbow.c | 2
arch/ia64/sn/kernel/sn2/Makefile | 2
arch/ia64/sn/kernel/sn2/sn2_smp.c | 5 -
arch/ia64/sn/kernel/sn2/timer_interrupt.c | 64 ++++++++++++
include/asm-ia64/a.out.h | 4
include/asm-ia64/bugs.h | 6 -
include/asm-ia64/byteorder.h | 4
include/asm-ia64/checksum.h | 4
include/asm-ia64/current.h | 4
include/asm-ia64/errno.h | 12 --
include/asm-ia64/fcntl.h | 6 -
include/asm-ia64/ioctl.h | 6 -
include/asm-ia64/ioctls.h | 6 -
include/asm-ia64/machvec.h | 7 +
include/asm-ia64/machvec_sn2.h | 2
include/asm-ia64/mman.h | 6 -
include/asm-ia64/namei.h | 4
include/asm-ia64/numa.h | 4
include/asm-ia64/param.h | 6 -
include/asm-ia64/poll.h | 6 -
include/asm-ia64/posix_types.h | 8 +
include/asm-ia64/processor.h | 6 -
include/asm-ia64/resource.h | 6 -
include/asm-ia64/scatterlist.h | 4
include/asm-ia64/siginfo.h | 6 -
include/asm-ia64/signal.h | 4
include/asm-ia64/socket.h | 8 +
include/asm-ia64/sockios.h | 9 +
include/asm-ia64/stat.h | 4
include/asm-ia64/statfs.h | 6 -
include/asm-ia64/termbits.h | 6 -
include/asm-ia64/termios.h | 4
include/asm-ia64/tlb.h | 4
include/asm-ia64/types.h | 6 -
include/asm-ia64/uaccess.h | 2
include/asm-ia64/unaligned.h | 5 -
include/asm-ia64/user.h | 4
45 files changed, 310 insertions(+), 270 deletions(-)
through these ChangeSets:
<eranian@hpl.hp.com> (04/01/26 1.1525)
[PATCH] ia64: fix icc compilation
<iod00d@hp.com> (04/01/26 1.1524)
[PATCH] ia64: enable PIOW/DMAR relaxed ordering on ZX1
<schwab@suse.de> (04/01/26 1.1523)
[PATCH] ia64: Fix xbow.c compilation
This fixes a conflicting declaration in xbow.c.
<matthewc@cse.unsw.edu.au> (04/01/26 1.1522)
ia64: Fix ptrace infrastructure some more so that strace'd sigreturn()
works without trashing any registers.
<mort@wildopensource.com> (04/01/23 1.1498.1.3)
ia64: remove old sn1 machvec header file
<davidm@tiger.hpl.hp.com> (04/01/23 1.1498.1.2)
ia64: Fix merge error: remove duplicate NR_CPUS.
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.11)
ia64: Patch by Jesse Barnes: remove unnecessary set_affinity handler.
<bjorn.helgaas@hp.com> (04/01/23 1.1474.119.10)
[PATCH] ia64: remove MCA (MicroChannel) cruft
MCA_bus is now referenced only when CONFIG_MCA is set,
so we should be able to remove the definition from ia64.
<mort@wildopensource.com> (04/01/23 1.1474.119.9)
[PATCH] ia64: add platform_timer_interrupt() hook
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.8)
ia64: Fix typo in comment in asm-ia64/posix_types.h.
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.7)
ia64: Drop copyright notices on header files which are either entirely trivial
or ended up being trivial variations of another file. Fix some
missing attributions and rephrase existing attributions for specifity.
<suresh.b.siddha@intel.com> (04/01/22 1.1474.119.6)
[PATCH] ia64: replace inline assembly in sn2 code
<akpm@osdl.org> (04/01/21 1.1474.119.5)
[PATCH] ia64: i2c config fix
ia64 needs to include i2c by hand
<bjorn_helgaas@hp.com> (04/01/21 1.1474.119.4)
[PATCH] ia64: Kconfig cleanup, part 1
<davidm@tiger.hpl.hp.com> (04/01/19 1.1474.119.3)
ia64: arch/ia64/Kconfig URL update: www.linux-on-laptops.com
<jbarnes@sgi.com> (04/01/16 1.1474.119.2)
[PATCH] ia64: kill some more warnings
Kills a warning and a false sense of safety by removing the volatile
qualifier on cpu_to_node_map[] and node_to_cpu_mask[]. Also fix the
printk for total processors since num_online_cpus() can return an int or
a long depending on the value of NR_CPUS.
<jbarnes@sgi.com> (04/01/16 1.1474.119.1)
[PATCH] ia64: fix cast in irq_lsapic.c
This patch just updates the cast in irq_lsapic.c to use the cpumask_t
type for the noop cast assignment to smp_affinity.
^ permalink raw reply
* Re: TFTP crashes the linux system...
From: Harald Welte @ 2004-01-27 1:35 UTC (permalink / raw)
To: Gautham Thavva; +Cc: netfilter
In-Reply-To: <BBKGNGAPNMGCAKAA@mailcity.com>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Mon, Jan 26, 2004 at 06:20:20PM -0500, Gautham Thavva wrote:
>
> I have enforced a firewall, using iptables-1.2.6a, on a target board running TimeSys Linux Kernel(Kernel version is 2.4.7-10).
>
> I have applied the *tftp* patch available in the patch-o-matic.
i strongly doubt that you will get this wokring with such an incredibly
old kernel... You'd basically need to backport more than two years of
netfilter/iptables development on top of 2.4.7...
The patch-o-matic README doesn indicate that it only supports 2.4.18 and
later.
> With regards,
> Gautham Thavva
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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.