* [uml-devel] Kernel idles in loop after loading IPv4
From: Phil Nadeau @ 2004-01-27 20:54 UTC (permalink / raw)
To: user-mode-linux-devel
Hello UML developers,
I'm trying to use UML to set up a simulator for a high-availability
cluster. I encounter the following unexpected behavior -
On any kernel that I compile with IPv4 support, the kernel will stop
intializing drivers after loading IPv4 support. The last message I see
from the kernel is:
NET: Registered protocol family 2
Compiling with debug allows me to single-step through the kernel. I've
traced execution from inet_init(), to synchronize_net(), to
synchronize_kernel(), to a call to wait_for_completion(), to
switch_to_tt(), after which the kernel spends all its time in the idle
loop. This happens whether I'm using SKAS or TT mode.
Host kernel is 2.6.1 with Stephen William's 2.6.1 SKAS patch (thanks
Stephen). Guest kernel is 2.6.1 with the latest patch from Sourceforge
(January 15th), without modules, and with nearly everything disabled at
compile except core functionality and IPv4.
I've tried to find similar cases in the FAQ's and the list archives, but
I'm not seeing anything. It seems like the kernel is waiting for an
event related to IPv4 initialization that it never gets, but I'm not
familiar enough with the kernel proper to know what that might be. Does
anyone have any ideas?
Thanks in advance.
--
Phil Nadeau
Software Services Manager
phil.nadeau@innercite.com
(916)932-3200, (800)921-5513
-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: BitKeeper repo for KGDB
From: Tom Rini @ 2004-01-27 21:02 UTC (permalink / raw)
To: Chris Wright
Cc: akpm, george, amitkale, Andi Kleen, jim.houston,
Kernel Mailing List
In-Reply-To: <20040127120744.A11525@osdlab.pdx.osdl.net>
On Tue, Jan 27, 2004 at 12:07:44PM -0800, Chris Wright wrote:
> * Tom Rini (trini@kernel.crashing.org) wrote:
> > Hello everybody. Since I've been talking with George off-list about
> > trying to merge the various versions of KGDB around, and I just read the
> > thread between Andy and Jim about conflicting on KGDB work, I've put up
> > a BitKeeper repository[1] to try and coordinate things.
> <snip>
> > [1]: If anyone here won't / can't use BitKeeper, I'll happily move over
> > to a repo someone else sets up in something else.
>
> seems I missed where the repo is.
> thanks,
> -chris
Der, whoops.
bk://ppc.bkbits.net/linux-2.6-kgdb
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [ALSA - driver 0000005]: alsa-driver-1.0.2: unresolved symbols in snd.o
From: noreply @ 2004-01-27 21:08 UTC (permalink / raw)
To: alsa-devel
A BUGNOTE has been added to this bug.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000005
======================================================================
Reporter: ZlatkO
Handler:
======================================================================
Project: ALSA - driver
Bug ID: 5
Category: CORE - control
Reproducibility: always
Severity: block
Priority: normal
Status: new
Distribution: Slackware 8.1
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:31 CET
Last Modified: 01-27-2004 22:08 CET
======================================================================
Summary: alsa-driver-1.0.2: unresolved symbols in snd.o
Description:
snd.o fails to load due to an unresolved symbol ("sound_class") on a
Slackware 8.1 system, kernel 2.4.24 (plain vanilla from kernel.org),
modutils-2.4.16.
There is no "sound_class" in the kernel's own
/usr/src/linux-2.4.24/drivers/sound/sound_core.c - am I supposed to
replace it with alsa-kernel/sound_core.c? This was not necessary in
previous ALSA versions.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 22:08 CET
----------------------------------------------------------------------
I cannot reproduce this bug, but it might be possible that removing
of line 'extern struct class_simple *sound_class;' in
alsa-driver/alsa-kernel/core/sound.c solves this bug.
Can you confirm?
I've recreated new alsa-driver package with date:
Jan 27 22:02 alsa-driver-1.0.2.tar.bz2
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:31 ZlatkO New Bug
01-27-04 22:08 perex Bugnote Added: 0000005
======================================================================
-------------------------------------------------------
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
* [ALSA - driver 0000005]: alsa-driver-1.0.2: unresolved symbols in snd.o
From: noreply @ 2004-01-27 21:08 UTC (permalink / raw)
To: alsa-devel
The following bug has been ASSIGNED.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000005
======================================================================
Reporter: ZlatkO
Handler: perex
======================================================================
Project: ALSA - driver
Bug ID: 5
Category: CORE - control
Reproducibility: always
Severity: block
Priority: normal
Status: assigned
Distribution: Slackware 8.1
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:31 CET
Last Modified: 01-27-2004 22:08 CET
======================================================================
Summary: alsa-driver-1.0.2: unresolved symbols in snd.o
Description:
snd.o fails to load due to an unresolved symbol ("sound_class") on a
Slackware 8.1 system, kernel 2.4.24 (plain vanilla from kernel.org),
modutils-2.4.16.
There is no "sound_class" in the kernel's own
/usr/src/linux-2.4.24/drivers/sound/sound_core.c - am I supposed to
replace it with alsa-kernel/sound_core.c? This was not necessary in
previous ALSA versions.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 22:08 CET
----------------------------------------------------------------------
I cannot reproduce this bug, but it might be possible that removing
of line 'extern struct class_simple *sound_class;' in
alsa-driver/alsa-kernel/core/sound.c solves this bug.
Can you confirm?
I've recreated new alsa-driver package with date:
Jan 27 22:02 alsa-driver-1.0.2.tar.bz2
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:31 ZlatkO New Bug
01-27-04 22:08 perex Bugnote Added: 0000005
01-27-04 22:08 perex Assigned To => perex
01-27-04 22:08 perex Status new => assigned
======================================================================
-------------------------------------------------------
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
* [ALSA - driver 0000004]: snd.o misses undefined symbol sound_class
From: noreply @ 2004-01-27 21:10 UTC (permalink / raw)
To: alsa-devel
The following bug has been ASSIGNED.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000004
======================================================================
Reporter: khali
Handler: perex
======================================================================
Project: ALSA - driver
Bug ID: 4
Category: OTHERS
Reproducibility: always
Severity: block
Priority: normal
Status: assigned
Distribution: Slackware 8.0
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:15 CET
Last Modified: 01-27-2004 22:10 CET
======================================================================
Summary: snd.o misses undefined symbol sound_class
Description:
After installing the alsa drivers, I am unable to load snd.o. See the
output of "depmod -ae":
depmod: *** Unresolved symbols in
/lib/modules/2.4.24-1/kernel/sound/acore/snd.o
depmod: sound_class
Configure options: --with-oss=yes --with-cards=intel8x0
Compilation successful.
======================================================================
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:15 khali New Bug
01-27-04 21:43 ZlatkO Bug Monitored: ZlatkO
01-27-04 22:10 perex Assigned To => perex
01-27-04 22:10 perex Status new => assigned
======================================================================
-------------------------------------------------------
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
* [ALSA - driver 0000004]: snd.o misses undefined symbol sound_class
From: noreply @ 2004-01-27 21:11 UTC (permalink / raw)
To: alsa-devel
The following bug has been CLOSED
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000004
======================================================================
Reporter: khali
Handler: perex
======================================================================
Project: ALSA - driver
Bug ID: 4
Category: OTHERS
Reproducibility: always
Severity: block
Priority: normal
Status: closed
Distribution: Slackware 8.0
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:15 CET
Last Modified: 01-27-2004 22:11 CET
======================================================================
Summary: snd.o misses undefined symbol sound_class
Description:
After installing the alsa drivers, I am unable to load snd.o. See the
output of "depmod -ae":
depmod: *** Unresolved symbols in
/lib/modules/2.4.24-1/kernel/sound/acore/snd.o
depmod: sound_class
Configure options: --with-oss=yes --with-cards=intel8x0
Compilation successful.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 22:11 CET
----------------------------------------------------------------------
This report is same as report http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000005, so please, monitor this report.
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:15 khali New Bug
01-27-04 21:43 ZlatkO Bug Monitored: ZlatkO
01-27-04 22:10 perex Assigned To => perex
01-27-04 22:10 perex Status new => assigned
01-27-04 22:11 perex Bugnote Added: 0000006
01-27-04 22:11 perex Status assigned => closed
======================================================================
-------------------------------------------------------
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: [PATCH|RFC] IPv6: have a proxy discard link-local traffic
From: Ville Nuorvala @ 2004-01-27 21:11 UTC (permalink / raw)
To: davem, yoshfuji; +Cc: Pekka Savola, usagi-core, netdev
In-Reply-To: <Pine.LNX.4.44.0401170906160.9907-100000@netcore.fi>
On Sat, 17 Jan 2004, Pekka Savola wrote:
> > Since the Thaler proxy clearly needs some other forwarding function than
> > ip6_forward(), my proposed patch doesn't affect its behavior in any way.
>
> Ok, if your modification is in ip6_forward() (I didn't check), I guess
> it would OK, with a sufficient comment to bring up that a future
> implementation might treat link-local proxying differently.
Dave, since even Pekka is now convinced this patch doesn't break anything,
would you consider applying it? :)
Slightly (cleaned up version of) patch below.
Thanks,
Ville
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1521 -> 1.1522
# net/ipv6/ip6_output.c 1.49 -> 1.50
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/01/27 vnuorval@dsl-hkigw1o3c.dial.inet.fi 1.1522
# The MIPv6 specification requires we send an ICMPv6 Destination Unreachable,
# Address Unreachable, message in response to traffic to a proxied link-local address
# --------------------------------------------
#
diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
--- a/net/ipv6/ip6_output.c Tue Jan 27 22:05:56 2004
+++ b/net/ipv6/ip6_output.c Tue Jan 27 22:05:56 2004
@@ -385,6 +385,15 @@
if (!xfrm6_route_forward(skb))
goto drop;
+ /* The proxying router can't forward traffic sent to a link-local
+ address, so signal the sender and discard the packet. This
+ behavior is required by the MIPv6 specification. */
+
+ if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL &&
+ skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) {
+ dst_link_failure(skb);
+ goto drop;
+ }
/* IPv6 specs say nothing about it, but it is clear that we cannot
send redirects to source routed frames.
*/
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - REALLY SOLVED
From: Fabio Coatti @ 2004-01-27 21:09 UTC (permalink / raw)
To: Andi Kleen
Cc: Eric, Andrew Morton, stoffel, Valdis.Kletnieks, bunk,
linux-kernel
In-Reply-To: <20040127181554.GA41917@colin2.muc.de>
Alle Tuesday 27 January 2004 19:15, Andi Kleen ha scritto:
> Ok, found it. This patch should fix it. The top level asm in process.c
> assumed that the section was .text, but that is not guaranteed in a
> funit-at-a-time compiler. It ended up in the setup section and messed up
> the argument parsing. This bug could have hit with any compiler,
> it was just plain luck that it worked with newer gcc 3.3 and 3.4.
Confirmed here. 2.6.2-rc1-mm3 boots just fine with this patch; without patch
it hangs just as described before.
(-funit-at-a-time enabled, of course).
Many thanks to all.
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
^ permalink raw reply
* Re: [PATCH] crypto/sha256.c crypto/sha512.c
From: David S. Miller @ 2004-01-27 21:05 UTC (permalink / raw)
To: Jean-Luc Cooke; +Cc: linux-kernel
In-Reply-To: <20040127202225.GA15808@certainkey.com>
On Tue, 27 Jan 2004 15:22:25 -0500
Jean-Luc Cooke <jlcooke@certainkey.com> wrote:
> The Ch() and Maj() operations are used a lot in sha256/512.
Your analysis is great, but James was really asking for numbers :-)
^ permalink raw reply
* Re: udevinfo output broken
From: Kay Sievers @ 2004-01-27 21:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040127200651.GA7974@suse.de>
On Tue, Jan 27, 2004 at 09:06:51PM +0100, Olaf Hering wrote:
> udevinfo writes to fd 0, all the output is lost somehow.
>
> olaf@ibook:~> i="`/sbin/udevinfo -r 2>&1`"
> /dev/
Seems like a klibc feature :)
libc works as expected.
Greg, any idea?
kay@pim:~$ i=`/sbin/udevinfo -r`; echo -$i-
-/udev/-
Kay
-------------------------------------------------------
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: [PATCH][2.6] PCI Scan all functions
From: Greg KH @ 2004-01-27 21:12 UTC (permalink / raw)
To: Jake Moilanen, johnrose; +Cc: Andrew Morton, lkml, torvalds
In-Reply-To: <1075222501.1030.45.camel@magik>
On Tue, Jan 27, 2004 at 10:55:01AM -0600, Jake Moilanen wrote:
> There are some arch, like PPC64, that need to be able to scan all the
> PCI functions. The problem comes in on a logically partitioned system
> where function 0 on a PCI-PCI bridge is assigned to one partition and
> say function 2 is assiged to another partition. On the second
> partition, it would appear that function 0 does not exist, but function
> 2 does. If all the functions are not scanned, everything under function
> 2 would not be detected.
Heh, I think the PPC64 people need to get together and all talk about
this, as I just got a different patch, that solves much the same problem
from John Rose (it's on the linuxppc64 mailing list.)
Can you two get together and not patch the same section of code to do
the same thing in different ways?
thanks,
greg k-h
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Andreas Jellinghaus @ 2004-01-27 21:13 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20040127132725.GA14685@openoffice.nl>
On Tue, 27 Jan 2004 14:27:25 +0100, Valentijn Sessink wrote:
> Hello,
>
> At Tue, Jan 27, 2004 at 11:39:18AM +0100, Harald Welte wrote:
>> I also disagree that an ESP packet should be trated as locally
>> generated (and thus iterate over OUTPUT).
>
> This is what happens with incoming packets: they hit INPUT twice.
yes, but once before and once after decryption. use either fwmark
or an ipip tunnel interface to destinguish between already decrypted
and was-never-encrypted packets.
> On output, however, things are not so transparant. A packet hits OUTPUT,
> then gets encrypted. A totally different packet hits POSTROUTING. This makes
> no sense.
use an interface, and you will see the packet twice, plus the interface
does the route lookup on the encrypted packet. so no ugly hacks in the
routing table are necessary.
(ugly hacks scenario: consider a road warrior.
he is 192.168.3.2 and his vpn gateway is 192.168.3.1. he wants to put
the company net on that GW address. But without a GW he doesn't know
on which interface to put it. it could be either wlan (if the tunnel
is established with his wireless lan card), or the eth0 interface
(if he is using ethernet cable to connect to the net).
sure, the ipsec software could manipulate the routing table after
altering local and remote tunnel endpoints, but that is an ugly hack
and a bad design.)
[symetry]
that does not work:
netfilter wants NAT to be the first thing for incoming packets
and the last thing for outgoing packets. thats symetry.
but you want ipsec encryption and decryption as soon as possible:
both before looking at the routing table.
mixing those two will never result in symetry. if you try it
(routing before encapsulation), the result has problems.
Andreas
^ permalink raw reply
* sysctl variable to force IGMP version [PATCH]
From: David Stevens @ 2004-01-27 21:13 UTC (permalink / raw)
To: davem, netdev
[-- Attachment #1.1: Type: text/plain, Size: 3740 bytes --]
Below is a patch that allows forcing of the IGMP version. The primary
use would be with an IGMP-snooping switch that doesn't grok IGMPv3
packet formats and when there are no IGMPv2 or IGMPv1 multicast
routers on the network. By forcing the IGMP reports to version 2 (or
version 1, for really old switches), Linux would send reports that the
switch can understand for multicast forwarding to the port.
+-DLS
in-line and attached, for whitespace issues.
diff -ruN linux-2.6.2-rc1/include/linux/inetdevice.h linux-2.6.2-rc1F2/include/linux/inetdevice.h
--- linux-2.6.2-rc1/include/linux/inetdevice.h 2004-01-08 22:59:45.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/inetdevice.h 2004-01-23 14:55:52.000000000 -0800
@@ -21,6 +21,7 @@
int medium_id;
int no_xfrm;
int no_policy;
+ int force_igmp_version;
void *sysctl;
};
diff -ruN linux-2.6.2-rc1/include/linux/sysctl.h linux-2.6.2-rc1F2/include/linux/sysctl.h
--- linux-2.6.2-rc1/include/linux/sysctl.h 2004-01-21 14:03:34.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/sysctl.h 2004-01-23 14:55:52.000000000 -0800
@@ -360,6 +360,7 @@
NET_IPV4_CONF_MEDIUM_ID=14,
NET_IPV4_CONF_NOXFRM=15,
NET_IPV4_CONF_NOPOLICY=16,
+ NET_IPV4_CONF_FORCE_IGMP_VERSION=17,
};
/* /proc/sys/net/ipv4/netfilter */
diff -ruN linux-2.6.2-rc1/net/ipv4/devinet.c linux-2.6.2-rc1F2/net/ipv4/devinet.c
--- linux-2.6.2-rc1/net/ipv4/devinet.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/devinet.c 2004-01-26 16:34:31.000000000 -0800
@@ -1132,7 +1132,7 @@
static struct devinet_sysctl_table {
struct ctl_table_header *sysctl_header;
- ctl_table devinet_vars[17];
+ ctl_table devinet_vars[18];
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
@@ -1269,6 +1269,15 @@
.proc_handler = &ipv4_doint_and_flush,
.strategy = &ipv4_doint_and_flush_strategy,
},
+ {
+ .ctl_name = NET_IPV4_CONF_FORCE_IGMP_VERSION,
+ .procname = "force_igmp_version",
+ .data = &ipv4_devconf.force_igmp_version,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
},
.devinet_dev = {
{
diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F2/net/ipv4/igmp.c
--- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/igmp.c 2004-01-26 17:18:28.000000000 -0800
@@ -126,10 +126,14 @@
* contradict to specs provided this delay is small enough.
*/
-#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \
- time_before(jiffies, (in_dev)->mr_v1_seen))
-#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \
- time_before(jiffies, (in_dev)->mr_v2_seen))
+#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \
+ (in_dev)->cnf.force_igmp_version == 1 || \
+ ((in_dev)->mr_v1_seen && \
+ time_before(jiffies, (in_dev)->mr_v1_seen)))
+#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \
+ (in_dev)->cnf.force_igmp_version == 2 || \
+ ((in_dev)->mr_v2_seen && \
+ time_before(jiffies, (in_dev)->mr_v2_seen)))
static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im);
static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr);
(See attached file: igmpsysctl.patch)
[-- Attachment #1.2: Type: text/html, Size: 3789 bytes --]
[-- Attachment #2: igmpsysctl.patch --]
[-- Type: application/octet-stream, Size: 2821 bytes --]
diff -ruN linux-2.6.2-rc1/include/linux/inetdevice.h linux-2.6.2-rc1F2/include/linux/inetdevice.h
--- linux-2.6.2-rc1/include/linux/inetdevice.h 2004-01-08 22:59:45.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/inetdevice.h 2004-01-23 14:55:52.000000000 -0800
@@ -21,6 +21,7 @@
int medium_id;
int no_xfrm;
int no_policy;
+ int force_igmp_version;
void *sysctl;
};
diff -ruN linux-2.6.2-rc1/include/linux/sysctl.h linux-2.6.2-rc1F2/include/linux/sysctl.h
--- linux-2.6.2-rc1/include/linux/sysctl.h 2004-01-21 14:03:34.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/sysctl.h 2004-01-23 14:55:52.000000000 -0800
@@ -360,6 +360,7 @@
NET_IPV4_CONF_MEDIUM_ID=14,
NET_IPV4_CONF_NOXFRM=15,
NET_IPV4_CONF_NOPOLICY=16,
+ NET_IPV4_CONF_FORCE_IGMP_VERSION=17,
};
/* /proc/sys/net/ipv4/netfilter */
diff -ruN linux-2.6.2-rc1/net/ipv4/devinet.c linux-2.6.2-rc1F2/net/ipv4/devinet.c
--- linux-2.6.2-rc1/net/ipv4/devinet.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/devinet.c 2004-01-26 16:34:31.000000000 -0800
@@ -1132,7 +1132,7 @@
static struct devinet_sysctl_table {
struct ctl_table_header *sysctl_header;
- ctl_table devinet_vars[17];
+ ctl_table devinet_vars[18];
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
@@ -1269,6 +1269,15 @@
.proc_handler = &ipv4_doint_and_flush,
.strategy = &ipv4_doint_and_flush_strategy,
},
+ {
+ .ctl_name = NET_IPV4_CONF_FORCE_IGMP_VERSION,
+ .procname = "force_igmp_version",
+ .data = &ipv4_devconf.force_igmp_version,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
},
.devinet_dev = {
{
diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F2/net/ipv4/igmp.c
--- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/igmp.c 2004-01-26 17:18:28.000000000 -0800
@@ -126,10 +126,14 @@
* contradict to specs provided this delay is small enough.
*/
-#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \
- time_before(jiffies, (in_dev)->mr_v1_seen))
-#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \
- time_before(jiffies, (in_dev)->mr_v2_seen))
+#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \
+ (in_dev)->cnf.force_igmp_version == 1 || \
+ ((in_dev)->mr_v1_seen && \
+ time_before(jiffies, (in_dev)->mr_v1_seen)))
+#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \
+ (in_dev)->cnf.force_igmp_version == 2 || \
+ ((in_dev)->mr_v2_seen && \
+ time_before(jiffies, (in_dev)->mr_v2_seen)))
static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im);
static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr);
^ permalink raw reply
* [ALSA - driver 0000005]: alsa-driver-1.0.2: unresolved symbols in snd.o
From: noreply @ 2004-01-27 21:18 UTC (permalink / raw)
To: alsa-devel
A BUGNOTE has been added to this bug.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000005
======================================================================
Reporter: ZlatkO
Handler: perex
======================================================================
Project: ALSA - driver
Bug ID: 5
Category: 0_compilation problem_!!!
Reproducibility: always
Severity: block
Priority: immediate
Status: assigned
Distribution: Slackware 8.1
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:31 CET
Last Modified: 01-27-2004 22:18 CET
======================================================================
Summary: alsa-driver-1.0.2: unresolved symbols in snd.o
Description:
snd.o fails to load due to an unresolved symbol ("sound_class") on a
Slackware 8.1 system, kernel 2.4.24 (plain vanilla from kernel.org),
modutils-2.4.16.
There is no "sound_class" in the kernel's own
/usr/src/linux-2.4.24/drivers/sound/sound_core.c - am I supposed to
replace it with alsa-kernel/sound_core.c? This was not necessary in
previous ALSA versions.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 22:08 CET
----------------------------------------------------------------------
I cannot reproduce this bug, but it might be possible that removing
of line 'extern struct class_simple *sound_class;' in
alsa-driver/alsa-kernel/core/sound.c solves this bug.
Can you confirm?
I've recreated new alsa-driver package with date:
Jan 27 22:02 alsa-driver-1.0.2.tar.bz2
----------------------------------------------------------------------
khali - 01-27-2004 22:18 CET
----------------------------------------------------------------------
Doesn't work for me. Even worse, alsa-driver doesn't compile anymore after
I commented the line out:
sound.c: In function `snd_register_device_R1f4c5f07':
sound.c:239: `sound_class' undeclared (first use in this function)
sound.c:239: (Each undeclared identifier is reported only once
sound.c:239: for each function it appears in.)
sound.c: In function `alsa_sound_init':
sound.c:376: `sound_class' undeclared (first use in this function)
sound.c: At top level:
sound.c:41: warning: `device_mode' defined but not used
make[1]: *** [sound.o] Error 1
make[1]: Leaving directory `/usr/src/alsa-driver-1.0.2/acore'
make: *** [compile] Error 1
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:31 ZlatkO New Bug
01-27-04 22:08 perex Bugnote Added: 0000005
01-27-04 22:08 perex Assigned To => perex
01-27-04 22:08 perex Status new => assigned
01-27-04 22:08 perex Priority normal => immediate
01-27-04 22:15 perex Category CORE - control => 0_compilation problem_!!!
01-27-04 22:18 khali Bugnote Added: 0000007
======================================================================
-------------------------------------------------------
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: udevinfo output broken
From: Olaf Hering @ 2004-01-27 21:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040127200651.GA7974@suse.de>
On Tue, Jan 27, Kay Sievers wrote:
> On Tue, Jan 27, 2004 at 09:06:51PM +0100, Olaf Hering wrote:
> > udevinfo writes to fd 0, all the output is lost somehow.
> >
> > olaf@ibook:~> i="`/sbin/udevinfo -r 2>&1`"
> > /dev/
>
> Seems like a klibc feature :)
> libc works as expected.
_fwrite gets 0x1 as f, calls fileno() which decrements it and passes it
to write().
--
USB is for mice, FireWire is for men!
sUse lINUX ag, n√úRNBERG
-------------------------------------------------------
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: [Jfs-discussion] md raid + jfs + jfs_fsck
From: Florian Huber @ 2004-01-27 21:19 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: JFS-Discussion, Linux-Kernel
In-Reply-To: <20040127205324.A19913@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Tue, 2004-01-27 at 21:53, Christoph Hellwig wrote:
> On Tue, Jan 27, 2004 at 02:43:05PM -0600, Dave Kleikamp wrote:
> Yes, it does. But JFS should get the right size from the gendisk anyway.
> Or did you create the raid with the filesystem already existant?
Yes, i did so.
> While that appears to work for a non-full ext2/ext3 filesystem it's not something you
> should do because it makes the filesystem internal bookkeeping wrong and
> you'll run into trouble with any filesystem sooner or later.
So, remove the raid, create a new raid "1" with one partiton and create
a jfs fs on top of it, copy all files and add the other disk to the
raid?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Jfs-discussion] md raid + jfs + jfs_fsck
From: Christoph Hellwig @ 2004-01-27 21:22 UTC (permalink / raw)
To: Florian Huber; +Cc: JFS-Discussion, Linux-Kernel
In-Reply-To: <1075238385.14214.3.camel@suprafluid>
On Tue, Jan 27, 2004 at 10:19:45PM +0100, Florian Huber wrote:
> So, remove the raid, create a new raid "1" with one partiton and create
> a jfs fs on top of it, copy all files and add the other disk to the
> raid?
You can't partition md devices (yet), but otherwise yes. I think you can
also create md device without the persistant superblock still, but it
always was a pain to maintain those.
^ permalink raw reply
* ip_conntrack CLOSE_WAIT issue.
From: Dirk Morris @ 2004-01-27 21:23 UTC (permalink / raw)
To: netfilter-devel
my conntrack table on machines are building up with tons of connections
in the CLOSE_WAIT state.
Because the timeout is so long, they stick around until the table fills up.
Why are these connections not transitioning to the full closed state?
tcpdump shows that the full Fin/Fin-Ack/Ack takes place at the end of
these connections, but they still stick around.
In the following example, timmy is running an echo server on port 7000.
~ # cat /proc/net/ip_conntrack| grep 7000 [dmorris @
timmy]
<nothing>
~ # s tcpdump "host bebe" [dmorris @ timmy]
...
13:10:15.436354 bebe.43035 > timmy.7000: . ack 10 win 5840
<nop,nop,timestamp 164347449 1498713> (DF)
13:10:17.702593 bebe.43035 > timmy.7000: F 10:10(0) ack 10 win 5840
<nop,nop,timestamp 164347675 1498713> (DF)
13:10:17.702841 timmy.7000 > bebe.43035: F 10:10(0) ack 11 win 5792
<nop,nop,timestamp 1500980 164347675> (DF)
13:10:17.703086 bebe.43035 > timmy.7000: . ack 11 win 5840
<nop,nop,timestamp 164347675 1500980> (DF)
now on bebe I did:
~ # netcat timmy 7000 [dmorris
@ bebe]
aoesutnh
aoesutnh
Ctrl-C
~#
This causes the connection opening (not shown) and closing you see in
the tcpdump above.
But the connection never leaves the conntrack table.
~ # cat /proc/net/ip_conntrack| grep 7000 [dmorris @
timmy]
tcp 6 257147 CLOSE_WAIT src=10.0.0.44 dst=10.0.0.187 sport=43035
dport=7000 src=10.0.0.187 dst=10.0.0.44 sport=7000 dport=43035 [ASSURED]
use=1
I realize I could just turn
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait, is
that the fix or is this not supposed to happen?
This happens on two similar machines, in both 2.4.18 and 2.6.0-test8
info on timmy:
~
#
[dmorris @ timmy]
~ # uname
-a
[dmorris @ timmy]
Linux timmy 2.6.0-test8 #4 SMP Tue Dec 16 15:55:23 PST 2003 i686 unknown
~ # ifconfig
eth0
[dmorris @ timmy]
eth0 Link encap:Ethernet HWaddr 00:40:05:A0:20:07
inet addr:10.0.0.187 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6487 errors:1 dropped:0 overruns:0 frame:0
TX packets:5717 errors:24 dropped:0 overruns:0 carrier:24
collisions:0 txqueuelen:1000
RX bytes:793932 (775.3 KiB) TX bytes:1599858 (1.5 MiB)
Interrupt:11 Base address:0xac00
~ # netstat
-rn
[dmorris @ timmy]
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0
eth0
~ # netstat | grep CLOSE_WAIT | wc
-l [dmorris @ timmy]
0
~ # cat /proc/net/ip_conntrack| grep CLOSE_WAIT | wc
-l [dmorris @ timmy]
10
Thanks,
-Dirk
^ permalink raw reply
* Re: [Kernel-janitors] [PATCH] swim3.c - convert cli to spinlock
From: Randy.Dunlap @ 2004-01-27 21:26 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20040124035312.GA6136@masterofpi.org>
On Fri, 23 Jan 2004 19:53:12 -0800 Timmy Yee <shoujun@masterofpi.org> wrote:
| Hi,
|
| This patch replaces the cli function calls with the spinlock function calls
| for the swim3 driver.
Timmy,
I'm not going to use this. I checked with the powermac people
and much more is needed to make swim3 work and they have patched
code already.
Thanks,
--
~Randy
kernel-janitors project: http://janitor.kernelnewbies.org/
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [patch] remove null-ifiers
From: Karol Kozimor @ 2004-01-27 21:29 UTC (permalink / raw)
To: Jes Sorensen
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
len.brown-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <16406.32889.922823.45313-4mDQ13Tdud8Jw5R7aSpS0dP8p4LwMBBS@public.gmane.org>
Thus wrote Jes Sorensen:
> Karol> Len, I'll prepare a 0.27 patch against bk, so you might want to
> Karol> wait for that instead of reverting the change.
> Don't reverse this change.
As I've said earlier, I'm fine with the patch. I should definitely get
some sleep though.
Best regards,
--
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
-------------------------------------------------------
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: Encrypted Filesystem
From: Michael Halcrow @ 2004-01-27 21:25 UTC (permalink / raw)
To: LKML, Hans Reiser
In-Reply-To: <4016B444.A816C980@namesys.com>
[-- Attachment #1: Type: text/plain, Size: 4587 bytes --]
On Tue, Jan 27, 2004 at 09:56:04PM +0300, Edward Shishkin wrote:
> > > - Unencrypted pass-through mode with minimal overhead
> Would you comment this?
Allow me to clarify. A transparent encryption layer like CFS will
encrypt anything written out to a CFS mount and decrypt anything read
from a CFS mount, using the metadata associated with the source
directory. One potential modification to something like CFS would be
to make the encryption optional; a file behind a CFS mount may or may
not be encrypted, depending on an EA set in the file in the source
directory. If this were to apply to an entire root filesystem, then
one would want to minimize the overhead imposed by the CFS layer when
dealing with files that are not flagged as encrypted.
I have had a discussion with Steve French[1] on this topic, who has
given me some interesting insights. In general, one of my design
goals in an encrypted filesystem is to minimize overhead for the
default (unencrypted) case. In fs/jfs/file.c:106, the fileop read
pointer is set to generic_file_read. This is passed the file struct,
which can contain the encrypted status of file. If the file is marked
as encrypted, then the block can be assumed to be encrypted. The
pages in the blocks that are read can then be placed in a scatterlist
and decrypted with the crypto code in the kernel, according to further
metadata pointed to by the file struct (cipher id, key, etc.) and
according to the credentials in the task structure. Perhaps this
logic can be placed in a new jfs_file_read and the fileop read pointer
can point there instead; the jfs_file_read will check
filp->f_encryption->encrypted, and if it is set (unlikely()), then it
will continue with a read-and-decrypt, else it will just call
generic_file_read. This pointer will need to get set for each
relevant function in each filesystem that supports file encryption in
this manner.
> Also cryptcompress file has the following extended attributes (I think
> it will be useful to resolve some listed issues):
> - digest plugin id (which represents digest algorithm supported by
> reiser4: md5, sha1, etc..)
> - key id (fingerprint of special randomly generated string, this string
> is a part of a secret key, and this 'public' fingerprint is created
> by appropriate digest plugin. 'Public' means that all EA should be
> stored in disk stat-data. This key id allows to check authorization
> every time when file is opened. Authorization is granted only by a
> secret key (not by root password)
> ...
> Reiser4 allows to support any compression algorithm of Ziv-Lempel
> family, and any (symmetric or asymmetric) crypto algorithm (of course,
> asymmetric ones are very slowly and may inflate data, but enabling of
> short files encrypted by public/private keys can be useful for various
> management purposes.
Hans has been doing some very interesting work in this area. I am
aware of reiser4; Hans may remember having lunch with me at the
DISCEX-III conference in Washington, D.C. last year. My booth (the
BYU Internet Security Research Lab; Trust Negotiation) was right
across from his:
http://csdl.computer.org/comp/proceedings/discex/2003/1897/02/1897toc.htm
He had a lengthy discussion with Jason Holt[2] on the implementation
of crypto in reiser4.
While I appreciate the security features that are part of reiser4, my
efforts toward filesystem encryption are aimed at a more general
level, to provide an encryption layer that will work across several
filesystems. Perhaps we can look into unifying and abstracting the
key management, authentication, and other aspects involved in a
comprehensive filesystem encryption system, extending and using kernel
structures (struct file, kobject/sysfs, etc.) to maintain that data,
so whether someone is using reiser4, Security Enhanced ext3 (SEext3),
or Security Enhanced jfs (SEjfs)[3], the interface to userland will be
the same.
Mike
[1] Steve works on the Samba team down the hall from me; he's working
on CFIS at the moment
[2] Hans: Jason was a co-worker of mine in the ISRL, skinny and tall
with curly red hair (he's hard to forget once you've met him:
<http://isrl.cs.byu.edu/images/Dcp02290.jpg>)
[3] That was meant to be funny...
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: 2.6.1 "clock preempt"?
From: markus reichelt @ 2004-01-27 21:30 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <20040123203835.GA518@h00a0cca1a6cf.ne.client2.attbi.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
timothy parkinson <t@timothyparkinson.com> wrote:
> * Running with SpeedStep (this is a cpu thing i assume?) could cause this.
> * Not having DMA enabled on your hard disk(s) could cause this. See the hdparm
> utility to enable it.
> * Incorrect TSC synchronization on SMP systems could cause this.
> * Anything else?
Yepp:
Jan 27 20:12:12 tatooine kernel: Losing too many ticks!
I had to set "CONFIG_IDE_TASK_IOCTL=y" in my .config in order to get
it working.
- --
Bastard Administrator in $hell
GPG-Key at http://lists.notified.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAFthyLMyTO8Kj/uQRAojoAJ9ZIdhKEij8DW/QdkO1ZG9ksi1hqwCeMGQA
jjROcxpIDSJgirm931LKl0c=
=v37i
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH][2.6] PCI Scan all functions
From: Andrew Morton @ 2004-01-27 21:33 UTC (permalink / raw)
To: Greg KH; +Cc: moilanen, johnrose, linux-kernel, torvalds, Anton Blanchard
In-Reply-To: <20040127211253.GA27583@kroah.com>
Greg KH <greg@kroah.com> wrote:
>
> On Tue, Jan 27, 2004 at 10:55:01AM -0600, Jake Moilanen wrote:
> > There are some arch, like PPC64, that need to be able to scan all the
> > PCI functions. The problem comes in on a logically partitioned system
> > where function 0 on a PCI-PCI bridge is assigned to one partition and
> > say function 2 is assiged to another partition. On the second
> > partition, it would appear that function 0 does not exist, but function
> > 2 does. If all the functions are not scanned, everything under function
> > 2 would not be detected.
>
> Heh, I think the PPC64 people need to get together and all talk about
> this, as I just got a different patch, that solves much the same problem
> from John Rose (it's on the linuxppc64 mailing list.)
>
> Can you two get together and not patch the same section of code to do
> the same thing in different ways?
While we're on the topic, what's with the below patch? I've had it in -mm
for ages but apparently there's some disagreement over it.
From: Anton Blanchard <anton@samba.org>
We have IO BARs on ppc64 machines that begin at address 0. The current
pci probe code will ignore anything that starts at 0. Remove these checks.
---
drivers/pci/probe.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/pci/probe.c~ppc64-bar-0-fix drivers/pci/probe.c
--- 25/drivers/pci/probe.c~ppc64-bar-0-fix 2004-01-13 23:23:18.000000000 -0800
+++ 25-akpm/drivers/pci/probe.c 2004-01-13 23:23:18.000000000 -0800
@@ -176,7 +176,7 @@ void __devinit pci_read_bridge_bases(str
limit |= (io_limit_hi << 16);
}
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
@@ -187,7 +187,7 @@ void __devinit pci_read_bridge_bases(str
pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
limit = (mem_limit_lo & PCI_MEMORY_RANGE_MASK) << 16;
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
@@ -213,7 +213,7 @@ void __devinit pci_read_bridge_bases(str
}
#endif
}
- if (base && base <= limit) {
+ if (base <= limit) {
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xfffff;
_
^ permalink raw reply
* Re: Debian libc6 upgrade
From: caszonyi @ 2004-01-27 21:34 UTC (permalink / raw)
To: Michael Scondo; +Cc: linux-newbie
In-Reply-To: <200401272140.53742.michael.scondo@arcor.de>
On Tue, 27 Jan 2004, Michael Scondo wrote:
> Hi to all,
> I'm running a mixed Debian Woody, with a few backports and libc6 2.3.1-16.
> Now I would like to upgrade to libc6 2.3.2.ds1-10.
> Anything runs fine - until I try to compile a program :
>
> e.g.
> ____
> #include <stdio.h>
>
> int main()
> {
> printf("Hallo !\n");
> }
> ____
>
> cpp -o hallo hallo.cpp
> micha@betageuze:~/prog/test/t2$ ./hallo
> bash: ./hallo: Permission denied
> micha@betageuze:~/prog/test/t2$ chmod a+x ./hallo
> micha@betageuze:~/prog/test/t2$ ./hallo
> ./hallo: extern: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: typedef: command not found
> ./hallo: line 972: syntax error near unexpected token `;'
> ./hallo: line 972: `} __quad_t;'
> micha@betageuze:~/prog/test/t2$
>
> ?:-(
>
cpp is the c preprocessor :-)
to compile a c program use gcc
> gcc -o hallo hallo.cpp
> /usr/lib/crt1.o: In function `_start':
> ../sysdeps/i386/elf/start.S:92: undefined reference to `__libc_csu_fini'
> ../sysdeps/i386/elf/start.S:93: undefined reference to `__libc_csu_init'
> collect2: ld returned 1 exit status
>
installing libc is a very tricky task.
You could make your system unusable if something goes wrong.
Did you use optimisation flags when compiling glibc ?
How did you installed glibc ? make install ? wasn't any error when you
installed glibc ?
> I don't have any idea, what is going wrong.
> Maybe I should say, before the upgrade this example program compiled fine.
>
> Thanks for any help..
> Micha
>
> -
> 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
>
--
"A mouse is a device used to point at
the xterm you want to type in".
Kim Alm on a.s.r.
-
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
* [Kernel-janitors] [PATCH] drivers/video/fbcmap.c kmalloc audit
From: Leann Ogasawara @ 2004-01-27 21:37 UTC (permalink / raw)
To: kernel-janitors
Hi All,
Patch to audit kmalloc()'s and handle errors accordingly. Thanks,
Leann
diffed against 2.6.2-rc2
=== drivers/video/fbcmap.c 1.9 vs edited ==--- 1.9/drivers/video/fbcmap.c Mon Mar 31 13:51:12 2003
+++ edited/drivers/video/fbcmap.c Mon Jan 26 17:38:53 2004
@@ -98,14 +98,14 @@
if (!len)
return 0;
if (!(cmap->red = kmalloc(size, GFP_ATOMIC)))
- return -1;
+ goto err_red;
if (!(cmap->green = kmalloc(size, GFP_ATOMIC)))
- return -1;
+ goto err_green;
if (!(cmap->blue = kmalloc(size, GFP_ATOMIC)))
- return -1;
+ goto err_blue;
if (transp) {
if (!(cmap->transp = kmalloc(size, GFP_ATOMIC)))
- return -1;
+ goto err_transp;
} else
cmap->transp = NULL;
}
@@ -113,6 +113,17 @@
cmap->len = len;
fb_copy_cmap(fb_default_cmap(len), cmap, 0);
return 0;
+
+ err_transp:
+ kfree(cmap->blue);
+ err_blue:
+ kfree(cmap->green);
+ err_green:
+ kfree(cmap->red);
+ err_red:
+ cmap->red = cmap->green = cmap->blue = cmap->transp = NULL;
+ cmap->len = 0;
+ return -1;
}
/**
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ 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.