* MPC8xx SCC for sync. HDLC on 2.4 kernel
From: Jos Beck @ 2004-01-27 16:23 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to build a synchronous HDLC driver for the SCC of the MPC850/860
under linux kernel 2.4.22
I have got one working on a 2.2.5 kernel and one buggy, async only, for the 2.4
kernels.
What would be the best approach: porting the 2.2.5 driver to the 2.4.x kernel or
digging into the driver (ehdlc.c by Rodolfo Giometti based on Dan Malek's
enet.c) to make it work for sync HDLC at high speeds?
Or an alternative?
Best regards,
Jos Beck
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [despammed] trafic info
From: Andreas Kretschmer @ 2004-01-27 16:23 UTC (permalink / raw)
To: netfilter
In-Reply-To: <1169375166.20040127185956@internetplustravel.ru>
am Tue, dem 27.01.2004, um 18:59:56 +0300 mailte Oleg Savostyanov folgendes:
> Hello netfilter,
>
> I am using my LinuxBox as a NAT device for my LAN.
> Debian Woody 2.4.23
> I suspect one of my (or not one) computers infected by virus
> And generating outgoing trafic.
> Is there any way without installing packages to view from my linuxbox
> established connects, any info about
> transferred bytes during this connect, etc..?
> Or maybe someone can suggest good program for that.
You can log in the FORWARD-Chain. (All outgoing with SYN). Now you can
see source, destination and service (port on destination).
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
^ permalink raw reply
* Re: bk pull on ia64 linux tree
From: David Mosberger @ 2004-01-27 16:22 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401121658240.14305@evo.osdl.org>
>>>>> On Tue, 27 Jan 2004 09:49:17 -0500, Martin Hicks <mort@wildopensource.com> said:
Martin> I accidentally left a debug printk in the sn2
Martin> timer_interrupt(). Here is a fix. I sent an updated patch
Martin> to David yesterday, but I guess it didn't make it.
The patch you sent me yesterday didn't apply, so it went into the bit
bucket. Sorry.
--david
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andi Kleen @ 2004-01-27 16:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Eric, stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040126215056.4e891086.akpm@osdl.org>
> Can you plesae confirm that restoring only -funit-at-a-time again produces
> a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
It works just fine on the SuSE 9.0 3.3-hammer gcc.
So far the reports point to some Mandrake gcc 3.3 having problems
(they used an older version of Hammer branch). It's hard to be sure
because everybody having any problem with the kernel seems to like
to report it to this thread :-) But before just disabling
it I would like to track down the problem and see if it's really a
compiler issue or something that can be fixed in the kernel.
If you really want to disable it I would prefer to only check for that
compiler version and keep it for working 3.3-hammers.
-Andi
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-27 16:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.10170.911012.262682@cargo.ozlabs.ibm.com>
>>>>> On Tue, 27 Jan 2004 19:56:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about the attached one? It will touch memory more when
>> moving an element down, but we're talking about exception tables
>> here, and I don't think module loading time would be affected in
>> any noticable fashion.
Paul> Hmmm... Stylistically I much prefer to pick up the new
Paul> element, move the others up and just drop the new element in
Paul> where it should go, rather than doing swap, swap, swap down
Paul> the list.
Sure, the latter can be done, too.
Paul> Also, I don't think there is enough code there to be worth the
Paul> bother of trying to abstract the generic routine so you can
Paul> plug in different compare and move-element routines. The
Paul> whole sort routine is only 16 lines of code, after all. Why
Paul> not just have an ia64-specific version of sort_extable?
Paul> That's what I thought you would do.
Because the Alpha needs exactly the same code.
--david
^ permalink raw reply
* Re: [OT] Sco
From: Timothy Miller @ 2004-01-27 16:22 UTC (permalink / raw)
To: walt; +Cc: Linux Kernel
In-Reply-To: <40168A38.4010203@myrealbox.com>
walt wrote:
> Wakko Warner wrote:
>
>> There's a new virus out called W32/MyDoom.A that between feb 1st and
>> 12th it
>> will DoS www.sco.com. I didn't see anything on the list about it this
>> morning so I thought I'd share.
>
>
> So, are you suggesting that we all start using Outlook Express on Jan 31?
As much as SCO disturbs me, these kinds of underhanded attacks against
them disgust me. They stoop to SCO's level, or worse. SCO can and will
be dealt with properly through the use of FACTS.
Besides, DoS attacks against SCO will only be blamed on the Linux
community. So the developer of that virus is either a complete idiot or
is acting to intentionally hurt our image.
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: David Mosberger @ 2004-01-27 16:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.10170.911012.262682@cargo.ozlabs.ibm.com>
>>>>> On Tue, 27 Jan 2004 19:56:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about the attached one? It will touch memory more when
>> moving an element down, but we're talking about exception tables
>> here, and I don't think module loading time would be affected in
>> any noticable fashion.
Paul> Hmmm... Stylistically I much prefer to pick up the new
Paul> element, move the others up and just drop the new element in
Paul> where it should go, rather than doing swap, swap, swap down
Paul> the list.
Sure, the latter can be done, too.
Paul> Also, I don't think there is enough code there to be worth the
Paul> bother of trying to abstract the generic routine so you can
Paul> plug in different compare and move-element routines. The
Paul> whole sort routine is only 16 lines of code, after all. Why
Paul> not just have an ia64-specific version of sort_extable?
Paul> That's what I thought you would do.
Because the Alpha needs exactly the same code.
--david
^ permalink raw reply
* Re: trafic info
From: David Cannings @ 2004-01-27 16:17 UTC (permalink / raw)
To: Oleg Savostyanov, netfilter
In-Reply-To: <1169375166.20040127185956@internetplustravel.ru>
On Tuesday 27 January 2004 3:59 pm, Oleg Savostyanov wrote:
> Hello netfilter,
>
> I am using my LinuxBox as a NAT device for my LAN.
> Debian Woody 2.4.23
> I suspect one of my (or not one) computers infected by virus
> And generating outgoing trafic.
> Is there any way without installing packages to view from my linuxbox
> established connects, any info about
> transferred bytes during this connect, etc..?
> Or maybe someone can suggest good program for that.
If you're prepared to change your ming about installing packages, you
could try "trafshow" or "iptraf". I prefer iptraf but they're both good.
In Woody, trafshow is in the apt package "netdiag" and iptraf is in
"iptraf".
David
^ permalink raw reply
* Re: running masm611 inside dosemu and freedos
From: Ged Haywood @ 2004-01-27 16:17 UTC (permalink / raw)
To: Ryan Underwood; +Cc: linux-msdos
In-Reply-To: <20040126003747.GA2859@dbz.icequake.net>
Hi all,
On Sun, 25 Jan 2004, Ryan Underwood wrote:
> One thing to note is that there have been problems in the past related
> to the MASM linker and the DOS extender that it uses (Phar Lap). I
> think if the linker is invoked from ml.exe, it will work fine, but the
> linker cannot be invoked on its own (it will crash dosemu).
I use the X32 DOS extender mostly for C stuff. Early versions of this
product used to be marketed under the name 'DOSX' with the Zortech
compiler. While it never worked with earlier versions it does now
work under the latest DOSEMU. I have to tweak stack parameters on the
command line which I don't have to do under real DOS, I haven't
investigated the cause but it's not too surprising to find something
like that.
Zortech claimed compatibility with Phar Lap as well as DOSX, maybe
Phar Lap might work now too?
73,
Ged.
^ permalink raw reply
* Re: RFC: Trailing blanks in source files
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-01-27 16:15 UTC (permalink / raw)
To: rmps; +Cc: linux-kernel, yoshfuji
In-Reply-To: <Pine.LNX.4.58.0401271544120.27260@joel.ist.utl.pt>
In article <Pine.LNX.4.58.0401271544120.27260@joel.ist.utl.pt> (at Tue, 27 Jan 2004 15:44:56 +0000 (WET)), Rui Saraiva <rmps@joel.ist.utl.pt> says:
> It seems that many files [1] in the Linux source have lines with
> trailing blank (space and tab) characters and some even have formfeed
> characters. Obviously these blank characters aren't necessary.
I do not like to change this if it is done blindly.
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: Encrypted Filesystem
From: Andi Kleen @ 2004-01-27 16:13 UTC (permalink / raw)
To: Michael A Halcrow; +Cc: linux-kernel
In-Reply-To: <OFA97B290B.67DE842E-ON87256E27.0061728C-86256E27.0061BB0E@us.ibm.com.suse.lists.linux.kernel>
Michael A Halcrow <mahalcro@us.ibm.com> writes:
Hi,
First thanks for attempting this work. The state of art of encrypted
file systems in Linux currently is really not satisfying and can need
some improvements.
Here are some thoughts about it:
I wrote my own crypto loop implementation at some point because I
wasn't satisfied with the existing ones for my own needs. From that
experience I think first going over crypto loop is not a good idea
because a block device is not a good unit of encryption.
Better use a stacking file system or somesuch. Technically this
has the advantage that you don't need to cache the data twice (crypto
loop keeps both unencrypted and crypted data in the page cache)
and the disadvantage that you need to encrypt on every write instead of
every cache flush (that's quite reasonable with fast encryption algorithms)
The biggest shortcomming in crypto loop is that you cannot change the
password easily. Doing so would require reencryption of the whole
volume and it is hard to do so in a crash safe way (or you risk loss
of the volume when the machine crashes during reencryption) Another
problem is that using the user key makes it easy to use dictionary
attacks using known plain text. For example the first block on a ext2
file system is always zero and can be easily used to do a dictionary
attack based on a weak user password. The standard crypto loop uses
fixed IVs too which do not help against this.
I fixed this for my private implementation by using a different
encrypted keyfile and a session key for the actual implementation. And
the IV for each block is generated by a hash with another
secret. Disadvantage is of course that you have to store the keyfile
somewhere (with loop it is not practical to put any metadata into the
encrypted volume) and not lose it. With an stacking file system that
would be easier because you can just store it directly into underlying
fs.
One problem with this approach for a stacking file system is that you
need a new session key for each file if you encrypt them separately.
I'm not quite sure /dev/random can supply that many good secrets.
On a normal user system there is plenty of entropy from the keyboard
and mouse, but on a headless server it can be quite difficult.
For a loop device you only need the session key once so it's not a big
issue. For any session keys you may need to store secret state separately and
use a different method to generate them based on the state (e.g. using
a counter and a secure hash)
Another problem with stacking file systems is that they're not really
tried in the Linux VFS and there may be problems with it. Still they're
probably solvable. Please when you encounter any problems report them
to the Linux developers to fix them cleanly, not work around them in ugly ways
in your own code.
Not directly related to the file system, but in a bigger picture the
biggest problem with using cryptography regularly in Linux is that
there is no nice way for users to prevent pages from being swapped out
to disk. Always when you decrypt a file you risk it ending up
unencrypted on the swap partition. This means even when your file
system encrypts great you still risk your data when reading it.
While it would be possible to encrypt swap too I'm not sure this is a
good idea: e.g. it requires global key management, which is probably
bad. And it could cause performance problems. One idea that has been
around forever for it was to give each uid a global quota for
mlock()ed pages. This would at least allow to keep the keys secure.
One a bit more far fetched idea I was thinking about was to make the
mlock quota quite big (let's say for the currently logged in X user
1/2 of memory or less for a multi user system) and add a "crypto
tainted" flag to the processes. This means every process that accesses
the crypto file system is tainted this way and is prevented from
writing out any dirty pages up to the quota. Other swapping that
doesn't involve writing dirty pages like discarding of read only
program text is fine. When you exceed the quota you could warn
the user or prevent the process from growing in a more security
paranoid setting. This is not 100% fool proof - it could somehow
leak the secret data to other not tained processes, but would probably
still do much better than the current "I don't care" state.
Back from the far fetched ideas. I think using a stacked file system
is the best way to go. Loop is just too dumb. NFS loopback or FUSE
are too slow. The biggest challenge is probably good key management
(both session and user keys). The Linux interface will be probably
simple compared to that.
-Andi
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Tom Eastep @ 2004-01-27 16:11 UTC (permalink / raw)
To: Harald Welte, Willy Tarreau
Cc: Henrik Nordstrom, Michal Ludvig, netfilter-devel
In-Reply-To: <20040127103917.GC11761@sunbeam.de.gnumonks.org>
On Tuesday 27 January 2004 02:39 am, Harald Welte wrote:
>
> My proposal:
> From conntracks view (and thus from NAT view), there (shuld be?) two
> seperate connections for any given to-be-encapsulated packet:
>
> - the payload connection (tcp/udp/whatever)
> - conntrack entry created at PREROUTING
> - conntrack entry confirmed (put in hash) at XXX
> - the AH/ESP connection
> - conntrack entry created at YYY
> - conntrack entry confirmed at POSTROUTING
>
> To do this, somewhen between esp_output() is called and the beginning of
> the modification of the packet payload, we need to call
> nf_hook(POST_ROUTING). This way, conntrack would be able to put the
> connection in the hash, and people can do SNAT-like operations in
> nat->POSTROUTING. We could even pass a dummy output device structure
> with an interface name "esp" so people can SNAT everything heading for
> esp encapsulation.
I like this proposal. I assume that on input, payload packets would also have
this dummy device as their input device? And on output that payload packets
would have "esp" as their output device in the FORWARD and OUTPUT hooks as
well?
I would also like to register my vote for having the AH/ESP packets go through
INPUT and OUTPUT. This would allow Shorewall to treat IPSEC in the same way
as it does all other tunnel types:
a) the payload connection uses a dedicated device ("esp" in this case)
b) the encapsulated traffic originates at the gateway on output and is
directed to the gateway on input.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
^ permalink raw reply
* Re: MIPS Kernel size
From: Thiemo Seufer @ 2004-01-27 16:10 UTC (permalink / raw)
To: kip.r2; +Cc: linux-mips
In-Reply-To: <1075215091.40167af364b77@imp1-a.free.fr>
kip.r2@free.fr wrote:
> What will be the approximate size for a minimal MIPS kernel?
IIRC a 2.4 kernel with the bare minimum to boot on a cobalt
machine is a bit below 600k compressed. You will miss many
drivers on such a System. :-)
Thiemo
^ permalink raw reply
* Re: [Bug 1959] New: cs46xx driver mmap_valid 0-->1 in kernel 2.6.x?
From: Takashi Iwai @ 2004-01-27 16:00 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <365550000.1075216480@[10.10.2.4]>
At Tue, 27 Jan 2004 07:14:40 -0800,
Martin J. Bligh wrote:
>
> Is there a reason to keep mmap_valid=0 in cs46xx driver or is this a real bug? I
> haven't seen any new bugs with this patch applied, all the multimedia
> applications (mplayer, xine, xmms, noatun) keeps on working.
cs46xx doesn't always support the direct hardware buffer.
Only in some cases with a proper period (fragment) numbers, it can
support the direct buffer access. mmap_valid option forces the driver
to allow OSS apps the direct accessing via mmap. This might not work
always, depending on the parameter the app uses. Use at your own
risk.
In short: it's not a real bug as long as mmap_valid=1 option works.
You had luck that your OSS apps (using mmap) seem working :)
--
Takashi Iwai <tiwai@suse.de> ALSA Developer - www.alsa-project.org
^ permalink raw reply
* linuxppc trees / BK help
From: Christian Kujau @ 2004-01-27 16:05 UTC (permalink / raw)
To: linuxppc-dev
hello,
after reading the recent threads about the different ppc trees (and much
BK stuff i still have to learn) i am still wondering if there are CVS
trees from say 2.4.24-benh or linuxppc-2.5-benh available.
there is a BK2CVS gateway, but my cloning always results only in
"strange trees". as seen on http://penguinppc.org/dev/kernel.shtml i do
bk clone bk://source.mvista.com/linuxppc-2.5-benh linuxppc-2.5-benh-BK
after passing the consistency check, a sourcetree shows up but
filenames are different from normal:
evil@sheep:/data/MP3/scratch/kernel$ ls linuxppc-2.5-benh-BK/
BitKeeper Documentation SCCS arch crypto drivers fs include init
~ ipc kernel lib mm net scripts security sound usr
evil@sheep:/data/MP3/scratch/kernel$
- --> there are no files in the directory, only dirs.
evil@sheep:/data/MP3/scratch/kernel$ ls -w10 linuxppc-2.5-benh-BK/kernel/
SCCS
power
evil@sheep:/data/MP3/scratch/kernel$
yes, there are files somewhere too, e.g.
linuxppc-2.5-benh-BK/sound/pci/cs46xx/SCCS/s.dsp_spos.h
is there, but it is some kind of changelog or so. as you can imagine,
compiling fails :-(
someone there to enlighten me what´s going on here?
Thank you,
Christian.
- --
BOFH excuse #259:
Someone's tie is caught in the printer, and if anything else gets
printed, he'll be in it too.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Apache:access_log - 408
From: ccddtt @ 2004-01-27 16:02 UTC (permalink / raw)
To: netfilter, netfilter
hi,
you can see same question:
http://www.merit.edu/mail.archives/nanog/2001-09/msg01457.html
======= 2004-01-26 17:06:00
^ permalink raw reply
* trafic info
From: Oleg Savostyanov @ 2004-01-27 15:59 UTC (permalink / raw)
To: netfilter
Hello netfilter,
I am using my LinuxBox as a NAT device for my LAN.
Debian Woody 2.4.23
I suspect one of my (or not one) computers infected by virus
And generating outgoing trafic.
Is there any way without installing packages to view from my linuxbox
established connects, any info about
transferred bytes during this connect, etc..?
Or maybe someone can suggest good program for that.
Thanks in advance.
Oleg mailto:savostyanov@internetplustravel.ru
^ permalink raw reply
* Re: [OT] Sco
From: walt @ 2004-01-27 15:56 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <20040127081506.C4346@animx.eu.org>
Wakko Warner wrote:
> There's a new virus out called W32/MyDoom.A that between feb 1st and 12th it
> will DoS www.sco.com. I didn't see anything on the list about it this
> morning so I thought I'd share.
So, are you suggesting that we all start using Outlook Express on Jan 31?
^ permalink raw reply
* Re: 2.6.1: process start times by procps
From: Petri Kaukasoina @ 2004-01-27 15:52 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040125110847.GA10824@elektroni.ee.tut.fi>
On Sun, Jan 25, 2004 at 01:08:47PM +0200, I wrote:
> On Fri, Jan 23, 2004 at 09:47:14PM +0200, I wrote:
> > For example, I started this bash process really at 21:24 (date showed 21:24
> > then):
> >
> > kaukasoi 22108 0.0 0.2 4452 1532 pts/4 R 21:28 0:00 /bin/bash
>
> OK, I would like to make my bug report more accurate: the problem seems to
> be that the value of btime in /proc/stat is not correct.
btime in /proc/stat does not stay constant but decreases at a rate of 15
secs/day. (So I thought that that's why there is that four minute error in
ps output after uptime of a couple of weeks.) Maybe this has something to do
with the fact that the 'timer' line in /proc/interrupts does not seem to
increase at an exact rate of 1000 steps per second but about 1000.18 steps
per second, instead. (The relative error is the same: 0.18 divided by 1000
is equal to 15 seconds divided by 24 hours).
I made an experiment shown below. I know nothing about kernel programming,
so this is probably not correct, but at least btime seemed to stay constant.
(I don't believe this fixes procps, though. If HZ if off by 180 ppm then I
guess ps can't possibly get its calculations involving HZ right. But at
least the bootup time reported by procinfo stays constant.)
--- linux-2.6.1/fs/proc/proc_misc.c.orig 2004-01-09 08:59:09.000000000 +0200
+++ linux-2.6.1/fs/proc/proc_misc.c 2004-01-27 14:39:04.000000000 +0200
@@ -363,19 +363,13 @@
u64 jif;
unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0, irq = 0, softirq = 0;
struct timeval now;
- unsigned long seq;
-
- /* Atomically read jiffies and time of day */
- do {
- seq = read_seqbegin(&xtime_lock);
-
- jif = get_jiffies_64();
- do_gettimeofday(&now);
- } while (read_seqretry(&xtime_lock, seq));
+ struct timespec uptime;
+ do_gettimeofday(&now);
+ do_posix_clock_monotonic_gettime(&uptime);
/* calc # of seconds since boot time */
- jif -= INITIAL_JIFFIES;
- jif = ((u64)now.tv_sec * HZ) + (now.tv_usec/(1000000/HZ)) - jif;
+ jif = ((u64)now.tv_sec * HZ) + (now.tv_usec/(1000000/HZ)) \
+ - ((u64)uptime.tv_sec * HZ) - (uptime.tv_nsec/(NSEC_PER_SEC/HZ));
do_div(jif, HZ);
for (i = 0; i < NR_CPUS; i++) {
^ permalink raw reply
* Re: virus warning
From: Juan Hernandez @ 2004-01-27 15:47 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <001101c3e4a8$800f4970$88e118d2@dw1>
yes, it's the SCO virus ;)
On Tue, 2004-01-27 at 03:38, Info wrote:
> ClamAV has detected it. Stopping more than 30 emails since this morning
> ----- Original Message -----
> From: <Alistair Tonner>
> To: "Netfilter Mailing List (E-mail)" <netfilter@lists.netfilter.org>
> Sent: Tuesday, January 27, 2004 2:45 PM
> Subject: Re: virus warning
>
>
> >
> > Obviously this is a really new one ... F-prot didn't catch it .. and mines
> up to date ...
> > However ... since kmail and linux don't much like 7 bit mime ... *grin*
> >
> > I'm handing this one up to the folks at F-Prot to see why they didn't
> catch it...
> >
> >
> > Alistair.
> >
> > On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> > > friends,
> > >
> > > we got a virus in our list.
> > > clamav warned me about it.
> > > it's now spreading like fire even on other lists.
> > >
> > > thought you might like to be warned.
> > >
> > >
> > > Cheers,
> > >
> > > fritz <www.mesedilla.com>
> > > ---
> > > + Basta Ikaw Lord
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > This email and any files transmitted with it are confidential and
> > > intended solely for the use of the individual or entity to whom they
> > > are addressed. If you have received this email in error please notify
> > > the sender immediately by e-mail and delete this e-mail from your
> > > system. Please note that any views or opinions presented in this
> > > email are solely those of the author and do not necessarily represent
> > > those of the company. Finally, the recipient should check this email
> > > and any attachments for the presence of viruses. The company accepts
> > > no liability for any damage caused by any virus transmitted by this
> > > email.
> > >
> > > Overture Media, Inc.
> > > Direct Line: (632) 635-4785
> > > Trunkline: (632) 631-8971 Local 146
> > > Fax: (632) 637-2206
> > > Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> > > Quezon City 1100
> >
> >
>
>
>
^ permalink raw reply
* RFC: Trailing blanks in source files
From: Rui Saraiva @ 2004-01-27 15:44 UTC (permalink / raw)
To: linux-kernel
Hello,
It seems that many files [1] in the Linux source have lines with
trailing blank (space and tab) characters and some even have formfeed
characters. Obviously these blank characters aren't necessary.
I wonder if it is a waste of time to send patches that clean the
source? Those patches will only remove those trailing blank characters and
will be splitted by maintainer.
Regards,
Rui Saraiva
[1]
> grep -lR "[[:blank:]]$" /usr/src/linux/ | wc -l
8163
^ permalink raw reply
* Need to modify the Program Header info
From: Fahd Abidi @ 2004-01-27 15:44 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I have a situation where the program headers built into an ELF executable
seem like they are incorrect. The target is an MPC5200, Here are the
program header and section header info:
Program Header:
LOAD off 0x00000000 vaddr 0x80000000 paddr 0x80000000 align 2**16
filesz 0x00009fc0 memsz 0x00009fc0 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001f80 80008000 80008000 00008000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000040 80009f80 80009f80 00009f80 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 80009fc0 80009fc0 00009fc0 2**0
ALLOC
3 .stab 0000219c 80009fc0 80009fc0 00009fc0 2**2
CONTENTS, READONLY, DEBUGGING
4 .comment 00000098 8000d838 8000d838 0000c15c 2**0
CONTENTS, READONLY
5 .stabstr 000016dc 8000c15c 8000c15c 0000c1f4 2**0
CONTENTS, READONLY, DEBUGGING
The Section header displays the correct load address, file offset and
Alignment information. The program header is incorrect. Does anyone know of
a way to modify the program header without messing around with the ld
script? I looked at objcopy and it seemed like it might do the trick but I
can't figure out what commands to use to change the program header
information.
Thanks for the help!!
Fahd Abidi
Field Applications Engineer
Ultimate Solutions, Inc.
=================================================
Professional Development Tools for Embedded Systems
Toll Free: 866-455-3383 x205
Facsimile: 978-926-3091
Email: fabidi@ultsol.com
www: http://www.ultsol.com
FAQ: http://www.ultsol.com/Faqs.htm
begin 666 ATT00047.htm
M/"%$3T-465!%($A434P@4%5"3$E#("(M+R]7,T,O+T141"!(5$U,(#,N,B\O
M14XB/@T*/$A434P^#0H\2$5!1#X-"CQ-151!($A45% M15%5258](D-O;G1E
M;G0M5'EP92(@0T].5$5.5#TB=&5X="]H=&UL.R!C:&%R<V5T/5=I;F1O=W,M
M,3(U,B(^#0H\345402!.04U%/2)'96YE<F%T;W(B($-/3E1%3E0](DU3($5X
M8VAA;F=E(%-E<G9E<B!V97)S:6]N(#8N,"XV,C0Y+C$B/@T*/%1)5$Q%/DYE
M960@=&\@;6]D:69Y('1H92!0<F]G<F%M($AE861E<B!I;F9O/"]4251,13X-
M"CPO2$5!1#X-"CQ"3T19/@T*/"$M+2!#;VYV97)T960@9G)O;2!T97AT+W!L
M86EN(&9O<FUA=" M+3X-"@T*/% ^/$9/3E0@4TE:13TR/DAE;&QO(&%L;"P\
M+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY)(&AA=F4@82!S:71U
M871I;VX@=VAE<F4@=&AE('!R;V=R86T@:&5A9&5R<R!B=6EL="!I;G1O(&%N
M($5,1B!E>&5C=71A8FQE('-E96T@;&EK92!T:&5Y(&%R92!I;F-O<G)E8W0N
M(%1H92!T87)G970@:7,@86X@35!#-3(P,"PF;F)S<#L@2&5R92!A<F4@=&AE
M('!R;V=R86T@:&5A9&5R(&%N9"!S96-T:6]N(&AE861E<B!I;F9O.CPO1D].
M5#X\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY0<F]G<F%M($AE861E<CH\+T9/
M3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^)FYB<W [)FYB<W [)FYB<W [($Q/
M040@;V9F)FYB<W [)FYB<W [)FYB<W [(#!X,# P,# P,# @=F%D9'(@,'@X
M,# P,# P,"!P861D<B P>#@P,# P,# P(&%L:6=N(#(J*C$V/"]&3TY4/@T*
M#0H\0E(^/$9/3E0@4TE:13TR/B9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R!F:6QE<WH@,'@P,# P.69C,"!M96US
M>B P># P,# Y9F,P(&9L86=S(')W>#PO1D].5#X-"CPO4#X-"@T*/% ^/$9/
M3E0@4TE:13TR/E-E8W1I;VYS.CPO1D].5#X-"@T*/$)2/CQ&3TY4(%-)6D4]
M,CY)9'@@3F%M929N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P
M.R9N8G-P.R9N8G-P.R9N8G-P.R!3:7IE)FYB<W [)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [(%9-029N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R!,34$F;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#L@
M1FEL92!O9F8F;F)S<#L@06QG;CPO1D].5#X-"@T*/$)2/CQ&3TY4(%-)6D4]
M,CXF;F)S<#L@," N=&5X="9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P
M.R9N8G-P.R9N8G-P.R9N8G-P.R P,# P,68X,"9N8G-P.R X,# P.# P,"9N
M8G-P.R X,# P.# P,"9N8G-P.R P,# P.# P,"9N8G-P.R R*BHR/"]&3TY4
M/@T*#0H\0E(^/$9/3E0@4TE:13TR/B9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P
M.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R!#3TY414Y44RP@
M04Q,3T,L($Q/040L(%)%041/3DQ9+"!#3T1%/"]&3TY4/@T*#0H\0E(^/$9/
M3E0@4TE:13TR/B9N8G-P.R Q("YD871A)FYB<W [)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [(# P,# P,#0P)FYB<W [(#@P
M,# Y9C@P)FYB<W [(#@P,# Y9C@P)FYB<W [(# P,# Y9C@P)FYB<W [(#(J
M*C(\+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [($-/
M3E1%3E13+"!!3$Q/0RP@3$]!1"P@1$%403PO1D].5#X-"@T*/$)2/CQ&3TY4
M(%-)6D4],CXF;F)S<#L@,B N8G-S)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [(# P,# P,# P)FYB<W [
M(#@P,# Y9F,P)FYB<W [(#@P,# Y9F,P)FYB<W [(# P,# Y9F,P)FYB<W [
M(#(J*C \+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M($%,3$]#/"]&3TY4/@T*#0H\0E(^/$9/3E0@4TE:13TR/B9N8G-P.R S("YS
M=&%B)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [(# P,# R,3EC)FYB<W [(#@P,# Y9F,P)FYB<W [(#@P,# Y9F,P
M)FYB<W [(# P,# Y9F,P)FYB<W [(#(J*C(\+T9/3E0^#0H-"CQ"4CX\1D].
M5"!325I%/3(^)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [)FYB<W [)FYB<W [($-/3E1%3E13+"!214%$3TY,62P@1$5"
M54='24Y'/"]&3TY4/@T*#0H\0E(^/$9/3E0@4TE:13TR/B9N8G-P.R T("YC
M;VUM96YT)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [(# P,# P,#DX
M)FYB<W [(#@P,#!D.#,X)FYB<W [(#@P,#!D.#,X)FYB<W [(# P,#!C,35C
M)FYB<W [(#(J*C \+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB
M<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [($-/3E1%3E13+"!214%$3TY,63PO1D].5#X-"@T*/$)2/CQ&3TY4
M(%-)6D4],CXF;F)S<#L@-2 N<W1A8G-T<B9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R P,# P,39D8R9N8G-P.R X,# P8S$U8R9N8G-P.R X,# P
M8S$U8R9N8G-P.R P,# P8S%F-"9N8G-P.R R*BHP/"]&3TY4/@T*#0H\0E(^
M/$9/3E0@4TE:13TR/B9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P
M.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R!#3TY414Y44RP@4D5!1$].3%DL
M($1%0E5'1TE.1SPO1D].5#X-"CPO4#X-"@T*/% ^/$9/3E0@4TE:13TR/E1H
M92!396-T:6]N(&AE861E<B!D:7-P;&%Y<R!T:&4@8V]R<F5C="!L;V%D(&%D
M9')E<W,L(&9I;&4@;V9F<V5T(&%N9"!!;&EG;FUE;G0@:6YF;W)M871I;VXN
M(%1H92!P<F]G<F%M(&AE861E<B!I<R!I;F-O<G)E8W0N($1O97,@86YY;VYE
M(&MN;W<@;V8@82!W87D@=&\@;6]D:69Y('1H92!P<F]G<F%M(&AE861E<B!W
M:71H;W5T(&UE<W-I;F<@87)O=6YD('=I=&@@=&AE(&QD('-C<FEP=#\@22!L
M;V]K960@870@;V)J8V]P>2!A;F0@:70@<V5E;65D(&QI:V4@:70@;6EG:'0@
M9&\@=&AE('1R:6-K(&)U="!)(&-A;B=T(&9I9W5R92!O=70@=VAA="!C;VUM
M86YD<R!T;R!U<V4@=&\@8VAA;F=E('1H92!P<F]G<F%M(&AE861E<B!I;F9O
M<FUA=&EO;BX\+T9/3E0^/"]0/@T*#0H\4#X\1D].5"!325I%/3(^5&AA;FMS
M(&9O<B!T:&4@:&5L<"$A/"]&3TY4/@T*/"]0/@T*#0H\4#X\1D].5"!325I%
M/3(^1F%H9"!!8FED:3PO1D].5#X-"@T*/$)2/CQ&3TY4(%-)6D4],CY&:65L
M9"!!<'!L:6-A=&EO;G,@16YG:6YE97(\+T9/3E0^#0H-"CQ"4CX\1D].5"!3
M25I%/3(^56QT:6UA=&4@4V]L=71I;VYS+"!);F,N/"]&3TY4/@T*#0H\0E(^
M/$9/3E0@4TE:13TR/CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T\+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^
M4')O9F5S<VEO;F%L($1E=F5L;W!M96YT(%1O;VQS(&9O<B!%;6)E9&1E9"!3
M>7-T96US/"]&3TY4/@T*#0H\0E(^/$9/3E0@4TE:13TR/E1O;&P@1G)E93H@
M.#8V+30U-2TS,S@S('@R,#4\+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^
M1F%C<VEM:6QE.B Y-S@M.3(V+3,P.3$\+T9/3E0^#0H-"CQ"4CX\1D].5"!3
M25I%/3(^16UA:6PZ(&9A8FED:4!U;'1S;VPN8V]M/"]&3TY4/@T*#0H\0E(^
M/$9/3E0@4TE:13TR/G=W=SH@/$$@2%)%1CTB:'1T<#HO+W=W=RYU;'1S;VPN
M8V]M(CYH='1P.B\O=W=W+G5L='-O;"YC;VT\+T$^/"]&3TY4/@T*#0H\0E(^
M/$9/3E0@4TE:13TR/D9!43H@/$$@2%)%1CTB:'1T<#HO+W=W=RYU;'1S;VPN
M8V]M+T9A<7,N:'1M(CYH='1P.B\O=W=W+G5L='-O;"YC;VTO1F%Q<RYH=&T\
D+T$^/"]&3TY4/@T*/"]0/@T*#0H\+T)/1%D^#0H\+TA434P^
`
end
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: virus warning
From: Juan Hernandez @ 2004-01-27 15:44 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <001101c3e4a8$800f4970$88e118d2@dw1>
Is this the new SCO virus? if it is... I'll infect all the computers in
my network in purpose ;)
Juan
On Tue, 2004-01-27 at 03:38, Info wrote:
> ClamAV has detected it. Stopping more than 30 emails since this morning
> ----- Original Message -----
> From: <Alistair Tonner>
> To: "Netfilter Mailing List (E-mail)" <netfilter@lists.netfilter.org>
> Sent: Tuesday, January 27, 2004 2:45 PM
> Subject: Re: virus warning
>
>
> >
> > Obviously this is a really new one ... F-prot didn't catch it .. and mines
> up to date ...
> > However ... since kmail and linux don't much like 7 bit mime ... *grin*
> >
> > I'm handing this one up to the folks at F-Prot to see why they didn't
> catch it...
> >
> >
> > Alistair.
> >
> > On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> > > friends,
> > >
> > > we got a virus in our list.
> > > clamav warned me about it.
> > > it's now spreading like fire even on other lists.
> > >
> > > thought you might like to be warned.
> > >
> > >
> > > Cheers,
> > >
> > > fritz <www.mesedilla.com>
> > > ---
> > > + Basta Ikaw Lord
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > This email and any files transmitted with it are confidential and
> > > intended solely for the use of the individual or entity to whom they
> > > are addressed. If you have received this email in error please notify
> > > the sender immediately by e-mail and delete this e-mail from your
> > > system. Please note that any views or opinions presented in this
> > > email are solely those of the author and do not necessarily represent
> > > those of the company. Finally, the recipient should check this email
> > > and any attachments for the presence of viruses. The company accepts
> > > no liability for any damage caused by any virus transmitted by this
> > > email.
> > >
> > > Overture Media, Inc.
> > > Direct Line: (632) 635-4785
> > > Trunkline: (632) 631-8971 Local 146
> > > Fax: (632) 637-2206
> > > Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> > > Quezon City 1100
> >
> >
>
>
>
^ permalink raw reply
* Re: [patch] remove null-ifiers
From: Matthew Wilcox @ 2004-01-27 15:43 UTC (permalink / raw)
To: Jes Sorensen, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
len.brown-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20040127150954.GA12740-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
On Tue, Jan 27, 2004 at 04:09:55PM +0100, Karol Kozimor wrote:
> > -static uid_t asus_uid = 0;
> > -static gid_t asus_gid = 0;
> > +static uid_t asus_uid;
> > +static gid_t asus_gid;
>
> We certainly *don't* want to do that, last time I checked C did not
> actually guarantee to zero out uninitialized variables -- unless it's
> different in the kernelspace. Are you sure pointers are initialized as
> NULLs?
Looks like you checked the wrong standard then. Global variables are
guaranteed to be zeroed, stack variables (ie function-local) have the
behaviour you described. Jes' patch is correct.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
-------------------------------------------------------
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: 2.6.2-rc1 / ACPI sleep / irqbalance / kirqd / pentium 4 HT problems on Uniwill N258SA0
From: Bart Samwel @ 2004-01-27 15:38 UTC (permalink / raw)
To: Pavel Machek; +Cc: Huw Rogers, linux-kernel, linux-laptop
In-Reply-To: <20040127083936.GA18246@elf.ucw.cz>
Pavel Machek wrote:
>>Anyway, sleep/suspend/standby functionality (important to most laptop
>>users, need to close the lid and go): This checkin to
>>kernel/power/main.c seems to disable suspend with SMP (!?):
>>
>>--- 1.3/kernel/power/main.c Sat Jan 24 20:44:47 2004
>>+++ 1.4/kernel/power/main.c Sat Jan 24 20:44:47 2004
>>@@ -172,6 +172,12 @@
>> if (down_trylock(&pm_sem))
>> return -EBUSY;
>>
>>+ /* Suspend is hard to get right on SMP. */
>>+ if (num_online_cpus() != 1) {
>>+ error = -EPERM;
>>+ goto Unlock;
>>+ }
>>+
>> if ((error = suspend_prepare(state)))
>> goto Unlock;
>>
>>... which, given the prevalence of hyperthreaded CPUs on laptops, is
>>fighting a trend. I backed out the above with a #if 0 then tried echo -n
>>1>/proc/acpi/sleep again. This time I got:
>
>
> Well, no sleep developers have SMP or HT machines, AFAICT.
>
> If you back that out... well you are on your own.
Just a random thought: if I understand it correctly, CPU hotplugging is
intended to be able to take CPUs online and offline one by one, am I
right? Well, when that infrastructure's ready, this can probably be made
to work for SMP by taking all the other CPUs offline first. They're all
going to go offline because of the suspend anyway, so it shouldn't make
much difference. :)
-- Bart
^ 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.