* Re: [LARTC] Shaping traffic to local users ?
From: Patrick McHardy @ 2002-12-19 16:03 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104030478706921@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi Dimitris,
You could try this patch to the owner match. Its working fine for me,
but i've seen it crash for unknown reasons
on other boxes. anyway its not very important to me so i won't try to
fix it, but if you're brave you could give
it a shot ;)
Bye,
Patrick
Dimitris Kotsonis wrote:
>
> Hello
>
> Is it possible to shape incoming traffic for local linux users ?
>
> Iptables can mark packets created from certain pid/uid/gid. Is
> there a way to do the same for packets _destined_ for some pid/uid/gid
> so that I can later shape them with IMQ ?
>
>
> Thanks in advance
>
> Dimitris Kotsonis
>
>
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[-- Attachment #2: owner-v4-pom.diff --]
[-- Type: text/plain, Size: 7380 bytes --]
diff -urN patch-o-matic-clean/extra/owner-socketlookup.patch patch-o-matic/extra/owner-socketlookup.patch
--- patch-o-matic-clean/extra/owner-socketlookup.patch 1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic/extra/owner-socketlookup.patch 2002-08-30 01:38:02.000000000 +0200
@@ -0,0 +1,182 @@
+diff -urN ../kernel/linux-2.4.20-pre4/include/net/tcp.h linux-2.4.20-pre4/include/net/tcp.h
+--- ../kernel/linux-2.4.20-pre4/include/net/tcp.h 2002-08-29 01:56:12.000000000 +0200
++++ linux-2.4.20-pre4/include/net/tcp.h 2002-08-30 00:16:56.000000000 +0200
+@@ -140,6 +140,7 @@
+ extern void tcp_bucket_unlock(struct sock *sk);
+ extern int tcp_port_rover;
+ extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif);
++extern struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 hnum, int dif);
+
+ /* These are AF independent. */
+ static __inline__ int tcp_bhashfn(__u16 lport)
+diff -urN ../kernel/linux-2.4.20-pre4/include/net/udp.h linux-2.4.20-pre4/include/net/udp.h
+--- ../kernel/linux-2.4.20-pre4/include/net/udp.h 2001-11-22 20:47:15.000000000 +0100
++++ linux-2.4.20-pre4/include/net/udp.h 2002-08-30 00:22:24.000000000 +0200
+@@ -69,6 +69,8 @@
+ extern int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ extern int udp_disconnect(struct sock *sk, int flags);
+
++extern struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif);
++
+ extern struct udp_mib udp_statistics[NR_CPUS*2];
+ #define UDP_INC_STATS(field) SNMP_INC_STATS(udp_statistics, field)
+ #define UDP_INC_STATS_BH(field) SNMP_INC_STATS_BH(udp_statistics, field)
+diff -urN ../kernel/linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c
+--- ../kernel/linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c 2002-08-29 01:56:13.000000000 +0200
++++ linux-2.4.20-pre4/net/ipv4/netfilter/ipt_owner.c 2002-08-28 22:19:39.000000000 +0200
+@@ -2,17 +2,26 @@
+ locally generated outgoing packets.
+
+ Copyright (C) 2000 Marc Boucher
++
++ 08/28/2002 Patrick McHardy <kaber@trash.net>
++ - Modified to also match properties of receiving sockets
+ */
+ #include <linux/module.h>
+ #include <linux/skbuff.h>
+ #include <linux/file.h>
++#include <linux/ip.h>
++#include <linux/tcp.h>
++#include <linux/udp.h>
+ #include <net/sock.h>
++#include <net/tcp.h>
++#include <net/udp.h>
++#include <net/route.h>
+
+ #include <linux/netfilter_ipv4/ipt_owner.h>
+ #include <linux/netfilter_ipv4/ip_tables.h>
+
+ static int
+-match_comm(const struct sk_buff *skb, const char *comm)
++match_comm(const struct sock *sk, const char *comm)
+ {
+ struct task_struct *p;
+ struct files_struct *files;
+@@ -28,7 +38,7 @@
+ if(files) {
+ read_lock(&files->file_lock);
+ for (i=0; i < files->max_fds; i++) {
+- if (fcheck_files(files, i) == skb->sk->socket->file) {
++ if (fcheck_files(files, i) == sk->socket->file) {
+ read_unlock(&files->file_lock);
+ task_unlock(p);
+ read_unlock(&tasklist_lock);
+@@ -44,7 +54,7 @@
+ }
+
+ static int
+-match_pid(const struct sk_buff *skb, pid_t pid)
++match_pid(const struct sock *sk, pid_t pid)
+ {
+ struct task_struct *p;
+ struct files_struct *files;
+@@ -59,7 +69,7 @@
+ if(files) {
+ read_lock(&files->file_lock);
+ for (i=0; i < files->max_fds; i++) {
+- if (fcheck_files(files, i) == skb->sk->socket->file) {
++ if (fcheck_files(files, i) == sk->socket->file) {
+ read_unlock(&files->file_lock);
+ task_unlock(p);
+ read_unlock(&tasklist_lock);
+@@ -75,10 +85,10 @@
+ }
+
+ static int
+-match_sid(const struct sk_buff *skb, pid_t sid)
++match_sid(const struct sock *sk, pid_t sid)
+ {
+ struct task_struct *p;
+- struct file *file = skb->sk->socket->file;
++ struct file *file = sk->socket->file;
+ int i, found=0;
+
+ read_lock(&tasklist_lock);
+@@ -119,36 +129,55 @@
+ int *hotdrop)
+ {
+ const struct ipt_owner_info *info = matchinfo;
++ struct sock *sk = NULL;
+
+- if (!skb->sk || !skb->sk->socket || !skb->sk->socket->file)
++ if (out) {
++ sk = skb->sk;
++ } else {
++ struct iphdr *iph = skb->nh.iph;
++ if (iph->protocol == IPPROTO_TCP) {
++ struct tcphdr *tcph =
++ (struct tcphdr*)((u_int32_t*)iph + iph->ihl);
++ sk = tcp_v4_lookup(iph->saddr, tcph->source,
++ iph->daddr, tcph->dest,
++ ((struct rtable*)skb->dst)->rt_iif);
++ } else if (iph->protocol == IPPROTO_UDP) {
++ struct udphdr *udph =
++ (struct udphdr*)((u_int32_t*)iph + iph->ihl);
++ sk = udp_v4_lookup(iph->daddr, udph->dest, iph->saddr,
++ udph->source, skb->dev->ifindex);
++ }
++ }
++
++ if (!sk || !sk->socket || !sk->socket->file)
+ return 0;
+
+ if(info->match & IPT_OWNER_UID) {
+- if((skb->sk->socket->file->f_uid != info->uid) ^
++ if((sk->socket->file->f_uid != info->uid) ^
+ !!(info->invert & IPT_OWNER_UID))
+ return 0;
+ }
+
+ if(info->match & IPT_OWNER_GID) {
+- if((skb->sk->socket->file->f_gid != info->gid) ^
++ if((sk->socket->file->f_gid != info->gid) ^
+ !!(info->invert & IPT_OWNER_GID))
+ return 0;
+ }
+
+ if(info->match & IPT_OWNER_PID) {
+- if (!match_pid(skb, info->pid) ^
++ if (!match_pid(sk, info->pid) ^
+ !!(info->invert & IPT_OWNER_PID))
+ return 0;
+ }
+
+ if(info->match & IPT_OWNER_SID) {
+- if (!match_sid(skb, info->sid) ^
++ if (!match_sid(sk, info->sid) ^
+ !!(info->invert & IPT_OWNER_SID))
+ return 0;
+ }
+
+ if(info->match & IPT_OWNER_COMM) {
+- if (!match_comm(skb, info->comm) ^
++ if (!match_comm(sk, info->comm) ^
+ !!(info->invert & IPT_OWNER_COMM))
+ return 0;
+ }
+@@ -164,8 +193,10 @@
+ unsigned int hook_mask)
+ {
+ if (hook_mask
+- & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING))) {
+- printk("ipt_owner: only valid for LOCAL_OUT or POST_ROUTING.\n");
++ & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING) |
++ (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_PRE_ROUTING))) {
++ printk("ipt_owner: only valid for LOCAL_OUT, LOCAL_IN, "
++ "POST_ROUTING or PRE_ROUTING.\n");
+ return 0;
+ }
+
+diff -urN ../kernel/linux-2.4.20-pre4/net/netsyms.c linux-2.4.20-pre4/net/netsyms.c
+--- ../kernel/linux-2.4.20-pre4/net/netsyms.c 2002-08-29 01:56:13.000000000 +0200
++++ linux-2.4.20-pre4/net/netsyms.c 2002-08-28 22:19:39.000000000 +0200
+@@ -597,4 +597,9 @@
+ EXPORT_SYMBOL(wireless_send_event);
+ #endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */
+
++#if defined(CONFIG_IP_NF_MATCH_OWNER)||defined(CONFIG_IP_NF_MATCH_OWNER_MODULE)
++EXPORT_SYMBOL(tcp_v4_lookup);
++EXPORT_SYMBOL(udp_v4_lookup);
++#endif /* CONFIG_IP_NF_MATCH_OWNER */
++
+ #endif /* CONFIG_NET */
diff -urN patch-o-matic-clean/extra/owner-socketlookup.patch.help patch-o-matic/extra/owner-socketlookup.patch.help
--- patch-o-matic-clean/extra/owner-socketlookup.patch.help 1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic/extra/owner-socketlookup.patch.help 2002-08-30 01:37:47.000000000 +0200
@@ -0,0 +1,13 @@
+Author: Patrick McHardy <kaber@trash.net>
+Status: working
+
+The patch allows you to use the owner match in the INPUT/PREROUTING chains to
+match properties of the receiving socket.
+
+Example:
+
+ # Allow packets coming in on eth0 to sockets owned be local user
+ # kaber
+
+ iptables -A INPUT -i eth0 -m owner --uid-owner kaber -j ACCEPT
+
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: billyrose @ 2002-12-19 16:10 UTC (permalink / raw)
To: root; +Cc: linux-kernel
Richard B. Johnson wrote:
> Because the number pushed onto the stack is a displacement, not
> an address, i.e., -4095. To have the address act as an address,
> you need to load a full-pointer, i.e. SEG:OFFSET (like the old
> 16-bit days). The offset is 32-bits and the segment is whatever
> the kernel has set up for __USER_CS (0x23). All the 'near' calls
> are calls to a signed displacement, same for jumps.
call's and jmp's use displacement, ret's are _always_ absolute.
^ permalink raw reply
* Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: Oleg Drokin @ 2002-12-19 15:58 UTC (permalink / raw)
To: darren; +Cc: reiserfs-list
In-Reply-To: <001301c2a776$d2ac9360$0101a8c0@bummer>
Hello!
On Thu, Dec 19, 2002 at 11:53:49PM +0800, darren wrote:
> I want to run TUX2 to serve files off my ReiserFS partition.
> But I cannot seem to get TUX2 on kernel 2.4.19, which I would like to
> run my reiserfs partition on.
We cannot tell you anything about Tux2 because we do not know anything
about it ;)
> Should I just stick to 2.4.18 and somehow patch the reiserfs there??
If you plan to run not current 2.4 kernels, you might want to
get patches from ftp://ftp.namesys.com/pub/reiserfs-for-2.4/<version>.pending
Where <version> next kernel version. (repeat that until you reach latest
kernel).
But actually 2.4.18 is pretty stable and you may not want to patch it if you
want.
Bye,
Oleg
^ permalink raw reply
* reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: darren @ 2002-12-19 15:53 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <3DFDD5B5.7050000@dsvr.net>
Hi all,
I want to run TUX2 to serve files off my ReiserFS partition.
But I cannot seem to get TUX2 on kernel 2.4.19, which I would like to
run my reiserfs partition on.
Should I just stick to 2.4.18 and somehow patch the reiserfs there??
^ permalink raw reply
* Re: MVME5100 boot from flash
From: Tom Rini @ 2002-12-19 15:49 UTC (permalink / raw)
To: Stefano Coluccini; +Cc: Linuxppc-Embedded
In-Reply-To: <NDBBIFIMCKPOADMAJOKMKEOJEOAA.s.coluccini@caen.it>
On Thu, Dec 19, 2002 at 10:03:03AM +0100, Stefano Coluccini wrote:
> I have a MVME5100 and i can use Linux on it booting from the network, now
> I'm trrying to boot from flash but without success. I have thought to simply
> put the image that is good for the network boot in the flash bank with
> pflash, but it doesn't work. Anyone knows what i have to do or where i can
> found documentation about this topic ?
What .config are you using to generate a working kernel for this
machine? IIRC, CONFIG_ALL_PPC won't generate a flash-bootable image by
default (look at arch/ppc/boot/simple/Makefile if you need to use this,
and not CONFIG_MVME5100), but CONFIG_MVME5100 will generate a
'zImage.bugboot' which can be put into flash and booted.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Tom Rini @ 2002-12-19 15:46 UTC (permalink / raw)
To: Prakash kanthi; +Cc: LinuxPPC
In-Reply-To: <20021219001423.47019.qmail@web41207.mail.yahoo.com>
On Wed, Dec 18, 2002 at 04:14:23PM -0800, Prakash kanthi wrote:
> I was trying to load linuxppc_2_4_devel onto my board.
> It goes through the board info read, UART init and
> Uncompressing the linux kernel. But after that, i do
> not see any messages and board hangs.
>
> Here is the UART output:
> ------------------------------------
> OS Booting...
>
> loaded at: 00400000 0060D1CC
> board data at: 00000030 00000044
> relocated to: 00405C24 00405C38
> zimage at: 00406290 004A08FF
> initrd at: 004A1000 006097CA
> avail ram: 0060E000 007F8000
>
> Linux/PPC load: console=ttyS0,9600 console=tty1 ip=on
> root=/dev/xsysace/disc0/pa
> rt3 rw
> Uncompressing Linux...done.
> Now booting the kernel
[snip]
> 2. How big a space this uncompressing process needs?
> And also how much overall memory is required for
> running linux. I just have 8MB SDRAM.
"Not too much". And the zlib uncompress code will error out if there
are any problems (corruption, lack of memory, etc). So if you got that
far, uncompression worked.
> 3. What is the next step in the booting process? Which
> Device (eth, pci, ide, ???) Initialization?
'???'. Try enabling CONFIG_SERIAL_TEXT_DEBUG, as that will print out
some information prior to printk being usable.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 823 Video Controller Driver - where ?
From: Wolfgang Denk @ 2002-12-19 15:44 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: 'Embedded Linux PPC List'
In-Reply-To: <D73A25AA6E54D511AD74009027B1110F3C0500@ORION>
In message <D73A25AA6E54D511AD74009027B1110F3C0500@ORION> you wrote:
> I appologize, you are correct. I sometimes think of LCD and video as the
> same because I worked with a Lynx chip that allows both LCD and Video out
> from the same buffer. Is it possible to use the 8xx LCD driver to drive the
> video out? I believe the only section that needs to be changed is the
> function that initializes the LCD registers, I may be off though.
It's more complicated, since the video controller will not support a
plain framebuffer, but only YUYV video mode.
What happened to the video driver for the EP boards? It was available
once on MV's FTP server - does not even EP has a copy any more?
[Asking just out of curiousity, as we've already reimplemented all
the stuff we needed - no NTSC support yet, though].
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
As far as we know, our computer has never had an undetected error.
-- Weisert
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: parport_serial link order bug, NetMos support
From: Zwane Mwaikambo @ 2002-12-19 15:52 UTC (permalink / raw)
To: Marek Michalkiewicz; +Cc: linux-kernel
In-Reply-To: <E18OxWK-0004w8-00@alf.amelek.gda.pl>
On Thu, 19 Dec 2002, Marek Michalkiewicz wrote:
> Hello,
>
> I've been trying (for quite a long time now, starting around the
> time when 2.4.19 was released) to submit the following patches into
> the 2.4.x kernel:
>
> http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/00_parport_serial
> http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/01_netmos
>
> (generated for 2.4.20-pre9, but apply cleanly to 2.4.20-final too,
> 00_parport_serial needs to be applied before 01_netmos).
I have local patches which do the same and have been using them for about
a year too (also at 115k). Regarding the parallel port aspect of the card,
i have tested using shared IRQs by running an epat cdrom via said port and
generating a high amount of serial i/o
00:10.0 Communication controller: NetMos Technology 222N-2 I/O Card (2S+1P) (rev 01)
Last time i posted regarding this, Tim Waugh says that the cards brought
about a number of issues, of which i am unable to recollect.
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Ducrot Bruno @ 2002-12-19 15:39 UTC (permalink / raw)
To: Faye Pearson; +Cc: Ducrot Bruno, Malte Thoma, ACPI-Devel
In-Reply-To: <20021219152724.GA14703-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
On Thu, Dec 19, 2002 at 03:27:24PM +0000, Faye Pearson wrote:
> Ducrot Bruno [ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] wrote:
> > > The only thing you can do is opendir("/proc/acpi/thermalzone"), then
> > > readdir for each item - ignore . and .. of course.
> >
> > No. scandir(). You can alphasort.
>
> Picky :) What I was trying to say is that you've got no choice but to
> scan/read directories, you can't hardcode.
>
> Scandir is cute, but perhaps unnecessary in a procfs where the nodes are
> created in-order anyway?
Nope. I really need to scandir() especially for the batteries case, because
the opendir() gave me BAT2 then BAT1 at least for me.
Cheers,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: MVME5100 boot from flash
From: ghannon @ 2002-12-19 15:39 UTC (permalink / raw)
To: Linuxppc-Embedded
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
Stefano,
I'm not sure this is the only approach, but this is what I use.
(See attached file: bugboot.tar.gz)
There is a readme in here that describes the process.
You basically have to build the board's residual data into the
image that gets flashed.
There may be tidbits left out of the readme, so email me if
this doesn't work as written.
Gary Hannon
CSPI
"Stefano Coluccini" <s.coluccini@caen.it> on 12/19/2002 04:03:03 AM
To: "Linuxppc-Embedded" <linuxppc-embedded@lists.linuxppc.org>
cc: (bcc: Gary Hannon/CSP)
Subject: MVME5100 boot from flash
Hi all,
I have a MVME5100 and i can use Linux on it booting from the network, now
I'm trrying to boot from flash but without success. I have thought to
simply
put the image that is good for the network boot in the flash bank with
pflash, but it doesn't work. Anyone knows what i have to do or where i can
found documentation about this topic ?
Thanks,
Stefano.
+--------------------------------------------------------+
! Stefano Coluccini ! CAEN SpA - Computing Div. !
! Via Vetraia, 11 ! 55049 Viareggio (LU)-ITALY !
! Tel. +39 0584 388 398 ! Fax +39 0584 388 959 !
! s.coluccini@caen.it ! www.caen.it/computing !
+--------------------------------------------------------+
[-- Attachment #2: bugboot.tar.gz --]
[-- Type: application/octet-stream, Size: 13158 bytes --]
^ permalink raw reply
* Re: ACPI with P4 mainboard
From: Faye Pearson @ 2002-12-19 15:32 UTC (permalink / raw)
To: Margit Schubert-While; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <4.3.2.7.2.20021219152505.00b54d00-KvFWrsCPMkLbFfAX06+HdQ@public.gmane.org>
Margit Schubert-While [margitsw-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org] wrote:
> 1) Didn't think that a P4 < 3.06Ghz had HT :-)
There are Xeons which do.
> <6>ACPI: Processor [CPU1] (supports C1, 8 throttling states)
> <6>ACPI: Processor [CPU2] (supports C1, 8 throttling states)
>
> 2) There is nothing in "fan" and "thermal_zone". I suspect that
> the DSDT
> lacks this info.
That's usually the reason. Run your dsdt through iasl to disassemble it
and see if there are errors.
Faye
--
Faye Pearson,
Covert Development
ClaraNET Ltd. Tel 020 7903 3000
Your job is being a professor and researcher: That's one hell of a good excuse
for some of the brain-damages of minix.
-- Linus Torvalds to Andrew Tanenbaum
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: pb compiling cross gcc, binutils, glibc and so on ...
From: david @ 2002-12-19 15:31 UTC (permalink / raw)
To: BREUVART Jean-Charles; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <36EB27C27D93D4119DE500508BDF85B30B2D710A@TOCOMEXC03>
Hello,
> RedHat 8.0 comes with gcc 3.2, binutils 2.13.90.0.2, make 3.79.1, I don't
> know how to get the libc version ...
You can get the libc version by directly executing /lib/libc.so.6
> Here is the trouble :
>
> choose-temp.c:29: stdio.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:30: sys/types.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:32: unistd.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:35: stdlib.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:38: sys/file.h: Aucun fichier ou r?pertoire de ce type
These errors tell you it can't find the header files for your specific target
platform.
You can either copy these from an existing PPC system, or build glibc from
scratch for your system.
A good guide for creating glibc from scratch is to be found at:
http://penguinppc.org/embedded/cross-compiling/
I hope this helps.
Best regards,
David Mazur
--
Mind: Embedded Linux, eCos and JVM development in Europe
http://mind.be tel +32-16-309.666
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Faye Pearson @ 2002-12-19 15:27 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: Malte Thoma, ACPI-Devel
In-Reply-To: <20021219132303.GH4257-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
Ducrot Bruno [ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] wrote:
> > The only thing you can do is opendir("/proc/acpi/thermalzone"), then
> > readdir for each item - ignore . and .. of course.
>
> No. scandir(). You can alphasort.
Picky :) What I was trying to say is that you've got no choice but to
scan/read directories, you can't hardcode.
Scandir is cute, but perhaps unnecessary in a procfs where the nodes are
created in-order anyway?
Faye
--
Faye Pearson,
Covert Development
ClaraNET Ltd. Tel 020 7903 3000
When it comes to broken marriages most husbands will split the blame --
half his wife's fault, and half her mother's.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Invalidate: busy buffer + MD RAID 1
From: Teodor Iacob @ 2002-12-19 15:35 UTC (permalink / raw)
To: Igmar Palsenberg; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212181905500.4421-100000@jdi.jdimedia.nl>
I get the same behaviour on several machines .. but I sleep well at night :P
On Wed, Dec 18, 2002 at 07:45:00PM +0100, Igmar Palsenberg wrote:
>
> Hi,
>
> I get a 'invalidate: busy buffer' about 20 times at reboot. Only at
> reboot however.
>
> Setup :
>
> linux-2.4.19 + grsecurity-1.9.7d + acl+xattr 0.8.53 + freeswan (inc. aes
> and that kind of stuff)
>
> The machine (Compaq ML350) has 2 scsi devices (sda, sdb) and a RAID 1
> setup :
>
> md0 : sda1 + sdb1
> md1 : sda3 + sdb3
> swap is done on sda2 + sdb2, using default prio's.
>
> Triggering the 'invalidate: busy buffer' is easiest done by letting squid
> create it's cache dirs and then rebooting.
>
> No data corruption is occuring (at last not any that a force fsck can
> detect), but I removed the RAID1 setup to make sure I sleep well tonight
> :)
>
> Looking at the md.c code, line 1708 :
>
> ITERATE_RDEV(mddev,rdev,tmp) {
> if (rdev->faulty)
> continue;
> invalidate_device(rdev->dev, 1);
> if (get_hardsect_size(rdev->dev)
> > md_hardsect_sizes[mdidx(mddev)])
> md_hardsect_sizes[mdidx(mddev)] =
> get_hardsect_size(rdev->dev);
> }
>
> Looks like it is invalidating the underlying devices (sda[13], sdb[13] in
> my case.
>
> Since my RAID array doesn't get screwed I suspect that the md code does
> the above again on a do_md_stop(), but I can't find it.
>
> Anyone got any comments on this ??
>
>
>
> Regards,
>
>
> Igmar
>
>
> Please CC all responses.
>
>
>
> --
>
> Igmar Palsenberg
> JDI Media Solutions
>
> Helhoek 30
> 6923PE Groessen
> Tel: +31 (0)316 - 596695
> Fax: +31 (0)316 - 596699
> The Netherlands
>
> mailto: i.palsenberg@jdimedia.nl
> PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
>
> -
> 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/
--
Teodor Iacob,
Network Administrator
Astral TELECOM Internet
^ permalink raw reply
* How can I expand the window size of a telnet session?
From: Jamie Risk @ 2002-12-19 15:27 UTC (permalink / raw)
To: linux-newbie
I've given up getting an XTerm session from my windows X
client working, and really all I want is large text window session.
So, how can I expand the window size of telnet session beyond
the anaemic dimensions of 80x25?
-
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: Problem with IP-Pools
From: Markus Schaber @ 2002-12-19 15:24 UTC (permalink / raw)
To: Martin Josefsson; +Cc: netfilter-devel
In-Reply-To: <1039180838.30495.104.camel@tux>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
Hello,
Martin Josefsson <gandalf@wlug.westbo.se> schrieb:
> You can find the current version (0.3.2a) here:
>
> http://gandalf.hjorten.nu/ippool/
>
> (I hope it compiles :)
I tried it with 2.4.20 (no patch-o-matic things applied), and the
compilation failed, outputting the attached error messages.
I didn't have time ot have a closer look yet, but if you have any idea,
or a newer verison available, it would be appreciated.
Thanks,
Markus
--
Markus Schaber - http://www.schabi.de/
Schabi's Flohmarkt unter http://schabi.de/flohmarkt
[-- Attachment #2: compile.stderr --]
[-- Type: text/plain, Size: 7296 bytes --]
make -C kernel CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/kernel'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/kernel'
make -C drivers CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/drivers'
make -C block modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/block'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/block'
make -C cdrom modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/cdrom'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/cdrom'
make -C char modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/char'
make -C drm modules
make[3]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/char/drm'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/char/drm'
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/char'
make -C hotplug modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/hotplug'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/hotplug'
make -C ide modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/ide'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/ide'
make -C media modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/media'
make -C radio modules
make[3]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/media/radio'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/media/radio'
make -C video modules
make[3]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/media/video'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/media/video'
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/media'
make -C misc modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/misc'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/misc'
make -C net modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/net'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/net'
make -C parport modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/parport'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/parport'
make -C scsi modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/scsi'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/scsi'
make -C sound modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/sound'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/sound'
make -C usb modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/usb'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/usb'
make -C video modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/video'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/video'
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers'
make -C mm CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/mm'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/mm'
make -C fs CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/fs'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/fs'
make -C net CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/net'
make -C core modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/net/core'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/net/core'
make -C ipv4 modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/net/ipv4'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/net/ipv4'
make -C ipv4/netfilter modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/net/ipv4/netfilter'
ld -m elf_i386 -r -o ip_conntrack.o ip_conntrack_standalone.o ip_conntrack_core.o ip_conntrack_proto_generic.o ip_conntrack_proto_tcp.o ip_conntrack_proto_udp.o ip_conntrack_proto_icmp.o
ld -m elf_i386 -r -o iptable_nat.o ip_nat_standalone.o ip_nat_rule.o ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o ip_nat_proto_tcp.o ip_nat_proto_udp.o ip_nat_proto_icmp.o
gcc -D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/pool/linux-2.4.20/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=ip_pool -DEXPORT_SYMTAB -c ip_pool.c
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/net/ipv4/netfilter'
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/net'
^ permalink raw reply
* new and updated setools
From: Frank Mayer @ 2002-12-19 15:20 UTC (permalink / raw)
To: 'selinux'
We just finally released a new update to our setools package at
www.tresys.com/selinux . This release includes a new tool (sepcut),
which is a first attempt at a GUI policy source
configuration/browse/edit/test tool. This tools is like of more value
to novices than to experts. It's relatively basic in capabilities,
especially in regard to an editor. However, it does provide a means to
view all parts of policy development in a single tool, and to easily
enable/disable/add/remove program modules.
Along with a bunch of fixes and changes, we've included regexp support
and the ability to open MLS-enabled policies in our analysis tool
(apol). (The MLS changes don't allow you to analyze the MLS aspects,
but lets you analyze a policy that includes MLS...this is rather
experimental). We also updated seuser to work with both the old and new
style of login contexts.
The source code, screen shots, and other information can be found at
www.tresys.com/selinux. As always, feedback, bug reports, etc. are
appreciated at selinux@tresys.com.
Regards, Frank
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: 2.5.52-mm2
From: Martin J. Bligh @ 2002-12-19 15:22 UTC (permalink / raw)
To: Andrew Morton, William Lee Irwin III; +Cc: lkml, linux-mm
In-Reply-To: <3E01A004.58F2B880@digeo.com>
> Actually, just looking at mmzone.h, I have to say "ick". The
> non-NUMA case seems unnecessarily overdone. eg:
>
># define page_to_pfn(page)
> ((page - page_zone(page)->zone_mem_map) +
> page_zone(page)->zone_start_pfn)
>
> Ouch. Why can't we have the good old `page - mem_map' here?
Ummm .... mmzone.h:
#ifdef CONFIG_DISCONTIGMEM
....
#define page_to_pfn(page) ((page - page_zone(page)->zone_mem_map) +
page_zone(page)->zone_start_pfn)
....
#endif /* CONFIG_DISCONTIGMEM */
page.h:
#ifndef CONFIG_DISCONTIGMEM
#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
#endif /* !CONFIG_DISCONTIGMEM */
I'll admit the file obfuscation hides this from being easy to read, but
i'm not stupid enough to screw things up *that* badly. Well, not most
of the time ;-) Want me to reshuffle things around so that the same defines
end up in the same file, and people have a hope in hell of reading it?
If I do that, it'll probably be based on the struct page breakout patch,
and making these things all static inlines, so people stop blowing their
own feet off.
M.
PS. cscope is cool ;-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* module-init-tools 0.9.5
From: Tomas Szepe @ 2002-12-19 15:29 UTC (permalink / raw)
To: Rusty Russell; +Cc: lkml
$ uname -r
2.4.20
[compile and install 2.5.52]
still in 2.4.20:
# depmod -V
module-init-tools 0.9.5
# depmod -ae -F /boot/System.map-2.5.52 2.5.52
#
[reboot into 2.5.52]
# modprobe pcnet32
FATAL: module pcnet32 not found.
# depmod -ae
# modprobe pcnet32
#
Hmm?
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: Martin J. Bligh @ 2002-12-19 15:24 UTC (permalink / raw)
To: Alex Tomas, William Lee Irwin III
Cc: Denis Vlasenko, David Lang, Robert Love, Till Immanuel Patzschke,
lse-tech, linux-kernel
In-Reply-To: <m3u1hapa51.fsf@lexa.home.net>
> WLI> As userspace solutions go your suggestions is just as good. The
> WLI> kernel still needs to get its act together and with some
> WLI> urgency.
>
> what about retreiving info from /proc/kmem or something like? just to
> avoid binary -> text(proc) -> binary
The binary <-> text translation problem is less of an issue than all the
syscall traffic, dcache hits, etc. Search linux-kernel archives for a
recent thread entitiled "ps performance sucks" or something similar.
M.
^ permalink raw reply
* Re: latest acpi: new behavior of the UPBI method
From: Markus Gaugusch @ 2002-12-19 15:15 UTC (permalink / raw)
To: acpi-devel
In-Reply-To: <3E01E193.3040406-gXTsMEhN/Y091FlJP1ih0VAUjnlXr6A1@public.gmane.org>
On Dec 19, Jacques GANGLOFF <jacques-gXTsMEhN/Y091FlJP1ih0VAUjnlXr6A1@public.gmane.org> wrote:
> On my VAIO FX702, I have a recurrent problem
> with the battery info:
>
> * the time needed to dump /proc/acpi/battery/BAT1/info
> is about 0.5s and during this time the box is frozen.
> * the last entries in info are corrupted, i.e. model number,
> serial number, battery type and OEM info.
Robert Moore from Intel is working on this issue (I help him by trying his
patches).
> As reported by another VAIO user on this list, my feeling is
> that these problems are linked.
No, they are not. The bad writte model number should be fixed in the next
version. Don't know about the large delay, but probably this isn't fixed
yet.
Markus
--
__________________ /"\
Markus Gaugusch \ / ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org X Against HTML Mail
/ \
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* RE: pb compiling cross gcc, binutils, glibc and so on ...
From: Claus Gindhart @ 2002-12-19 15:14 UTC (permalink / raw)
To: 'BREUVART Jean-Charles',
'linuxppc-embedded@lists.linuxppc.org'
A good and stable binary package of a complete gcc cross toolchain
is supplied with SuSE Linux 8.0.
This is the version:
----
claugi@claugi-wnt:~> /opt/cross/bin/powerpc-linux-gcc --version
2.95.3
---
I used with cross-toolchain succesfully on various PowerPC platforms.
It is no problem to install a SuSE RPM on a redhat system, if you
have no fear to do a "rpm -i --nodeps".
Unfortunatley these funny guys decided to remove this package in
their new 8.1 package; but maybe they have it still available for
download, or You can purchase a 8.0 version.
-----Original Message-----
From: BREUVART Jean-Charles [mailto:jean-charles.breuvart@airbus.com]
Sent: Donnerstag, 19. Dezember 2002 15:52
To: 'linuxppc-embedded@lists.linuxppc.org'
Subject: pb compiling cross gcc, binutils, glibc and so on ...
Hello world !
I'm trying to create a cdk, the host is a PIII runnning RedHat 8.0 (kernel
2.4.18), and the target is GNU kernel 2.4.20 running on a PPC755B
proprietary board. I've read lots of HOWTOs but I haven't succeeded yet !!!
RedHat 8.0 comes with gcc 3.2, binutils 2.13.90.0.2, make 3.79.1, I don't
know how to get the libc version ...
One told me that gcc 3.2 wasn't a nice version to create a cross-compiler
(actually, I've tried and this seems to be true), so I've downloaded from
www.gnu.org the following :
- gcc-2.95.3.tar.gz and gcc-core-2.95.3.tar.gz
- binutils-2.13.90.0.4.tar.gz and binutils-2.12.90.0.7.tar.gz
- glibc-2.3.tar.gz and glibc-linuxthreads-2.3.tar.gz
- make-3.80.tar.gz
- linux-src-2.4.20.tar.gz
I' succeeded in building a native gcc 2.95.3 and make 3.8, and used them to
create the famous Hello world C program, actually all that stuff works. But
I still remain to encounter pb while creating the cdk !!!
here is what I did :
1. restrict $PATH to /sbin:/bin:/usr/sbin:/usr/bin
2. build a native gcc core 2.95.3 from scratch in /usr/src/gcc-2.95.3/ dir,
and install it in /usr/local/ (the default) :
- cd /usr/src/gcc-2.95.3/
- make clean
- make distclean
- ./configure --enable-languages=c,c++ ; this uses my RedHat
distribution's cc, which link to gcc
- make bootstrap
- make install
3 build make 3.80 in /usr/src/make-3.80/ dir, and install it in /usr/local/
(the default) :
- cd /usr/src/make-3.80/
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure (I don't know if it's better to
use gcc 2.95.3 or gcc 3.2, however, this uses RedHat distribution's binutils
!)
- make
- make install
4. build binutils 2.12.90.0.7 for powerpc cross compile, and install it in
/opt/powerpc-linux/ :
- cd /usr/src/binutils
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
--enable-shared --with-newlib --prefix=/opt/powerpc-linux (I still don't
know if it's better to use gcc 2.95.3 or gcc 3.2)
- make
- make install
5. build gcc core 2.95.3 for powerpc cross compile, and install it in
/opt/powerpc-linux/ :
- cd /usr/src/gcc-2.95.3/
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
--enable-shared --enable-languages=c --with-newlib
--prefix=/opt/powerpc-linux
- add /opt/powerpc-linux at the end of $PATH, otherwise make doesn't
find powerpc-linux-as, powerpc-linux-ld and so on
- make
Here is the trouble :
choose-temp.c:29: stdio.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:30: sys/types.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:32: unistd.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:35: stdlib.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:38: sys/file.h: Aucun fichier ou r?pertoire de ce type
there aren't any of those in /opt/powerpc-linux/ or its subdirs
this the same trouble I had when I tried to build directly a cross gcc
2.95.2 for powerpc-linux with my RedHat distribution's gcc and binutils ...
So here are my questions :
- did anyone do that before ?
- does a pre-compiled version of such a cross dev toolsets already exists
for x86-pc-linux or sparc-sun ? I heard about "ELDK"
by Wolfgang Denk
- is what I did wrong ?
- where should the cross gcc build process search for those headers ? How
to indicate it ?
- must I use native binutils or cross binutils to build a cross gcc ?
- to build the bin utilities, including binutils, for the embedded linux
kernel's filesystem that will run on the PPC755B, I think I'll use the cross
gcc to build them from their source code ? I think that the one build in 4.
won't run, they only run on my host ?
if needed, I can change my host and use a Sun Workstation runnning SunOS
5.5.1 ...
So thanks in advance.
Regards,
Jean-Charles Breuvart
This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.5.52-mm2
From: Martin J. Bligh @ 2002-12-19 15:22 UTC (permalink / raw)
To: Andrew Morton, William Lee Irwin III; +Cc: lkml, linux-mm
In-Reply-To: <3E01A004.58F2B880@digeo.com>
> Actually, just looking at mmzone.h, I have to say "ick". The
> non-NUMA case seems unnecessarily overdone. eg:
>
># define page_to_pfn(page)
> ((page - page_zone(page)->zone_mem_map) +
> page_zone(page)->zone_start_pfn)
>
> Ouch. Why can't we have the good old `page - mem_map' here?
Ummm .... mmzone.h:
#ifdef CONFIG_DISCONTIGMEM
....
#define page_to_pfn(page) ((page - page_zone(page)->zone_mem_map) +
page_zone(page)->zone_start_pfn)
....
#endif /* CONFIG_DISCONTIGMEM */
page.h:
#ifndef CONFIG_DISCONTIGMEM
#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
#endif /* !CONFIG_DISCONTIGMEM */
I'll admit the file obfuscation hides this from being easy to read, but
i'm not stupid enough to screw things up *that* badly. Well, not most
of the time ;-) Want me to reshuffle things around so that the same defines
end up in the same file, and people have a hope in hell of reading it?
If I do that, it'll probably be based on the struct page breakout patch,
and making these things all static inlines, so people stop blowing their
own feet off.
M.
PS. cscope is cool ;-)
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: bart @ 2002-12-19 15:20 UTC (permalink / raw)
To: root; +Cc: linux-kernel, billyrose
On 19 Dec, Richard B. Johnson wrote:
> On Thu, 19 Dec 2002 billyrose@billyrose.net wrote:
>> long_call:
>> pushl $0xfffff000
>> ret
>>
>
> Because the number pushed onto the stack is a displacement, not
> an address, i.e., -4095. To have the address act as an address,
Not true. A ret(urn) is (sort of) equivalent to 'pop %eip'. The above
code would actually jump to address 0xfffff000, but probably be slow
since it confuses the branch prediction.
Bart
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
^ permalink raw reply
* latest acpi: new behavior of the UPBI method
From: Jacques GANGLOFF @ 2002-12-19 15:11 UTC (permalink / raw)
To: acpi-devel
Hi,
On my VAIO FX702, I have a recurrent problem
with the battery info:
* the time needed to dump /proc/acpi/battery/BAT1/info
is about 0.5s and during this time the box is frozen.
* the last entries in info are corrupted, i.e. model number,
serial number, battery type and OEM info.
As reported by another VAIO user on this list, my feeling is
that these problems are linked.
The interesting thing with the latest acpi patch (20021212), is that
the corruption in the last entries of info has changed. Now I get :
cat /proc/acpi/battery/BAT1/info
present: yes
design capacity: 44400 mWh
last full capacity: 44400 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 400 mWh
design capacity low: 384 mWh
capacity granularity 1: 64 mWh
capacity granularity 2: 64 mWh
model number: 50 43 47 41 2D 42 50 37 31 41 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
serial number: 20 20 20 20 20 20 20 20 00
battery type: 4C 49 4F 4E 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
OEM info: 53 6F 6E 79 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
This is a progress since if we translate all the hex numbers in ASCII
caracters we get :
model number: PCGA-BP71A
serial number:
battery type: LION Corp.
OEM info: Sony Corp.
which is rather close to what it should be (except for the "LION Corp."
???).
So why are these information given in hex dump format ? And why
is this dump so long ? My skill in AML programming is near from
beginner, so I need some help to go further.
Below is the dump that includes the faultly method (UPBI), I suppose it
should be a
good starting point.
Cheers,
Jacques
Device(BAT1) {
Name(_HID, 0x0a0cd041)
Name(_UID, 0x1)
Name(_PCL, Package(0x1) {
\_SB_,
})
Name(PBIF, Package(0xd) {
0x0,
0x5,
0x5,
0x1,
0x39d0,
0x0190,
0x0180,
0x40,
0x40,
"BAT1",
" ",
" ",
" ",
})
Name(PBST, Package(0x4) {
0x0,
0x5,
0x5,
0x2710,
})
Name(UBIF, 0x01e9)
Name(BP__, 0x1)
Method(_STA) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
If(Local0) {
Store(0x1, BP__)
}
Else {
Store(0x0, BP__)
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BATO)
And(0xfffe, \_SB_.PCI0.PIB_.EC0_.BATF,
\_SB_.PCI0.PIB_.EC0_.BATF)
If(And(0xc0, \_SB_.PCI0.PIB_.EC0_.BATO, )) {
Or(\_SB_.PCI0.PIB_.EC0_.BATF, 0x1,
\_SB_.PCI0.PIB_.EC0_.BATF)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
}
}
If(BP__) {
Return(0x1f)
}
Else {
Return(0xf)
}
}
Method(_BIF) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(BP__) {
UPBI()
}
Else {
IVBI()
}
Store(0x01e9, UBIF)
}
}
Return(PBIF)
}
Method(_BST) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
If(Local0) {
UPBS()
}
Else {
IVBS()
}
}
}
Else {
IVBS()
}
Return(PBST)
}
Method(UPBI) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
\_SB_.PCI0.PIB_.EC0_.SMWR(0x8, 0x14, 0x1, Local2)
\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x14, 0x1, RefOf(Local3))
Store(Zero, Local0)
Store(0xc, Local1)
Store(Buffer(0xd) {0x0, 0x18, 0x0, 0x0, 0x19, 0x0, 0x0,
0x0, 0x0, 0x21, 0x0, 0x22, 0x20 }, Local2)
While(LGreater(Local1, 0x8)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0xb, 0x16,
Local3, RefOf(Local4)))) {
GBFE(Local4, 0x20, RefOf(Local5))
PBFE(Local4, Local5, 0x20)
Increment(Local5)
PBFE(Local4, Local5, 0x0)
Store(Local4, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
While(LGreater(Local1, 0x0)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16,
Local3, RefOf(Local5)))) {
Store(Local5, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
Store(0xa, Local1)
If(LNot(And(UBIF, VTOB(Local1), ))) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16, 0x1c,
RefOf(Local5)))) {
Store(ToBCD(Local5, ), Local0)
Store(ITOS(Local0), Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
Store(\_SB_.PCI0.PIB_.EC0_.BANK, Local1)
Store(0x3, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(\_SB_.PCI0.PIB_.EC0_.MFCP, Local2)
If(LEqual(Local2, 0x0)) {
Store(0x5, Index(PBIF, 0x2, ))
}
Else {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x2, ))
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(DerefOf(Index(PBIF, 0x1, )), Local2)
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x1, ))
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(UPBS) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1388))) {
Store(0x2, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local2)
If(And(Local2, 0x8000, )) {
Or(Local2, 0xffff0000, Local2)
Add(Not(Local2, ), 0x1, Local2)
}
Store(\_SB_.PCI0.PIB_.INF3, Local3)
Store(\_SB_.PCI0.PIB_.INF2, Local5)
If(LNot(LEqual(Local2, DerefOf(Index(PBST, 0x1, ))))) {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBST, 0x1, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local3, DerefOf(Index(PBST, 0x3, ))))) {
Multiply(Local3, 0x14, Local3)
Divide(Local3, 0x40, Local4, Local3)
Store(Local3, Index(PBST, 0x3, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local5, DerefOf(Index(PBST, 0x2, ))))) {
Multiply(Local5, 0xa, Local5)
Store(Local5, Index(PBST, 0x2, ))
Store(Ones, Local0)
}
Store(0x0, Local4)
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local7)
If(And(Local7, 0x0c00, )) {
If(And(Local7, 0x10, )) {
}
Else {
Or(0x2, Local4, Local4)
}
}
Else {
If(And(Local7, 0x0100, )) {
Or(0x1, Local4, Local4)
}
}
If(LNot(LEqual(Local4, DerefOf(Index(PBST, 0x0, ))))) {
Store(Local4, Index(PBST, 0x0, ))
Store(Ones, Local0)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(HVBI) {
Store(0x9650, Index(PBIF, 0x1, ))
Store(0x9650, Index(PBIF, 0x2, ))
Store(0x39d0, Index(PBIF, 0x4, ))
Store("PCGA-BP71", Index(PBIF, 0x9, ))
Store("LION", Index(PBIF, 0xb, ))
Store("Sony Corp.", Index(PBIF, 0xc, ))
}
Method(IVBI) {
Store(0x01e9, UBIF)
Store(0x5, Index(PBIF, 0x1, ))
Store(0x5, Index(PBIF, 0x2, ))
Store(0x5, Index(PBIF, 0x4, ))
Store("Bad", Index(PBIF, 0x9, ))
Store("Bad", Index(PBIF, 0xa, ))
Store("Bad", Index(PBIF, 0xb, ))
Store("Bad", Index(PBIF, 0xc, ))
}
Method(IVBS) {
Store(0x0, Index(PBST, 0x0, ))
Store(0x5, Index(PBST, 0x1, ))
Store(0x5, Index(PBST, 0x2, ))
Store(0x2710, Index(PBST, 0x3, ))
}
Method(CHBP, 1) {
Store(Zero, Local0)
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
If(And(Arg0, Local1, )) {
If(BP__) {
UPBS()
}
Else {
If(LEqual(Local2, Or(Local3, 0x0fff, ))) {
UPBI()
}
UPBS()
Store(0x1, BP__)
Store(0x01e9, UBIF)
}
}
Else {
If(BP__) {
Store(0x0, BP__)
IVBI()
IVBS()
Or(0x4, Local0, Local0)
}
}
}
}
--
_________________________________
(
) Jacques GANGLOFF
( Associate Professor
) LSIIT / EAVR
( Bd Sebastien Brant
) 67400 Illkirch
( Tel : +33 (0)3 90 24 44 68
) Fax : +33 (0)3 90 24 44 80
( http://eavr.u-strasbg.fr
)_________________________________
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ 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.