All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Possible problem in asm/bitops.h
From: Tom Rini @ 2002-12-17 14:59 UTC (permalink / raw)
  To: Georg Klug; +Cc: linuxppc-embedded
In-Reply-To: <FFECLICFNBJAHONLGAKMAEFOCHAA.gklug@giga-stream.de>


On Tue, Dec 17, 2002 at 10:10:09AM +0100, Georg Klug wrote:

> > I suspect the actual problem is that iproute2 only needs
> > a very small amount of what is in include/linux/inetdev.h
>
> That might be true. But would the solution be to copy the linux/inetdev.h
> to a local directory and change that file until it doesn't need the file
> asm/bitops.h anymore?

Correct.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: counting shell args
From: Mike Dresser @ 2002-12-17 15:05 UTC (permalink / raw)
  To: johnjulian1; +Cc: Scott Taylor, linux-admin
In-Reply-To: <33C0BF62.7C9965DB.4DAE6F57@netscape.net>

On Mon, 16 Dec 2002 johnjulian1@netscape.net wrote:

> Just a note responding to your comment about this being for backing up windows boxes. I back up ours with a script that does it in steps testing for errors along the way.
> ping winbox
> mount winbox /mnt/winbox
> rsync /mnt/winbox user@remotebox
>
> this doesn't compress but does give me a lot of error checking. The remote box in my case is a Solaris box with a big raid and tape jukebox.
>
> If you're interested I'll email you the script.

I looked into using mount(smbmount), but ran into problems with smbmount
not keeping track properly of just how many files there are on a
filesystem.  Been a problem ever since Samba 1.9.something at the minimum.

do 3 ls -alR's in a row, and it'll come up with different numbers each
time.

Even more odd than smbtar. :)

Mike


^ permalink raw reply

* Re: kmalloc and startup process
From: Pantelis Antoniou @ 2002-12-17 15:06 UTC (permalink / raw)
  To: joakim.tjernlund, linuxppc-embedded
In-Reply-To: <3DFF2956.6020903@intracom.gr>


Pantelis Antoniou wrote:

>
> Joakim Tjernlund wrote:
>
>> Don't know when it's safe to call kmalloc, but maybe you
>> should avoid kmalloc?  Is it possible to use
>> kmalloc when the microcode(8xx_io/micropatch.c) is loaded?
>>
>>   Jocke
>>
> I fixed the problem via another way.
>
> At startup I use a statically allocated area, or
> the bootmem allocated page.
>
> The kmalloc is used only when a request for memory
> cannot be satisfied by this memory.
>
> I will probably post the patch for the hostmem today,
> followed tommorow by the patch for the dpmem.
>
> Stay tuned.

It seems that I don't have enough time to post the patch today.
Tommorow however I'll post the final one.

Regards

>
>>>
>>> Hi
>>>
>>> I'm hacking now the 8xx hostalloc and dpalloc stuff,
>>> and I have a a question.
>>>
>>> At what point in the startup process is it OK to call
>>> kmalloc?
>>>
>>> I don't think it is safe at the setup_arch point.
>>>
>>> Is this correct?
>>>
>>> Thanks
>>>
>>> --
>>> Pantelis Antoniou
>>> INTRACOM S.A. Greece
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Pantelis Antoniou
> INTRACOM S.A. Greece
>
>
>
>
>
>
--
Pantelis Antoniou
INTRACOM S.A. Greece


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: jsoe0708 @ 2002-12-17 15:14 UTC (permalink / raw)
  To: grundler, Ed Schaller; +Cc: parisc-linux
In-Reply-To: <3DED9BBD000021C7@ocpmta7.freegates.net>

Hello Grant,

>>
>>I've looked a bit at the same problem on A500 with
>>a regular (single port) HP tulip card.
>>
>>> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debia=
n),
>>> it seems that the older kernel is finding the transceiver and
>>> successfully auto-negotiating the link while the newer is not.
>>
>>yeah - same symptom that I saw.
>>
>>> Any ideas how to solve this? Any help would be greatly appreciated.
>>
>>I suspect it's a tulip driver bug.
>>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>>into 2.4.20.
>>
>Same on B2k with add card.
>Hmm I notice strange detail:
>2.4.19 : lan heart bit on (even if interface not configure)
>2.4.20 (& 21-pre1) : no lan heart bit on (interface configured or not)
>
>I will try to revert tulip driver and advise you.
>
Well I find some minutes to do this reverse and it works.
Still have to find the bug ?

Joel


*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

^ permalink raw reply

* Re: counting shell args
From: Mike Dresser @ 2002-12-17 15:15 UTC (permalink / raw)
  To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021216135627.01c67f78@mustang>

On Mon, 16 Dec 2002, Scott Taylor wrote:

> >is the ethernet unplugged AGAIN,
>
> Damn janitors!

Janitors?  I get the users unplugging their machines.  Had one guy
complain his floppy drive and cdrom were broken.  I go up to the plant(2
hour drive each way), and there's no screws on the case, the floppy drive
is fubar, and the cdrom isn't even plugged in, and if it were, it wouldn't
work anyways cause it was set to Master with the hard drive on the same
cable set to master.  And the ethernet cable hanging from the wall.

Guy put a TV tuner card in his machine by himself. (pentium 200 too)

Got stuck when he had no network, no floppy drive, and no cdrom to install
drivers with.

We don't even have soundcards in the machines, why did he think we'd allow
a TV Tuner board?

He won't be doing that again.  He's stuck with his 5" b&w portable now.

Mike


^ permalink raw reply

* Re: how to forward packets to another gateway, if i'm one
From: Ben Russo @ 2002-12-17 15:16 UTC (permalink / raw)
  To: Saulius Menkevicius; +Cc: netfilter@lists.netfilter.org
In-Reply-To: <ISPFE7vXn10A5fpk965000657df@mail.takas.lt>

On Fri, 2002-12-06 at 12:28, Saulius Menkevicius wrote:
>   Is there any way of forwarding packets to another gateway, which, 
> besides, is on the same network. Say, I'm on IP 10.0.0.2, and I act 
> as a gateway (ADSL, really) for a number of machines on the same LAN. 
> And there's another such gateway, hooked to another ADSL, which 
> handles connections for another bunch of machines. Essentially the 
> hosts 10.0.0.1 and 10.0.0.2 are identic and perform the same 
> function.
> 
If both 10.0.0.1 and 10.0.0.2 are on the same subnet then just find 
the client machines that you want to use 10.0.0.1 as their gateway
and change their default route. No changes at all would be required
on either gateway.



^ permalink raw reply

* [Linux-ia64] Strange ACPI interruptions in 2.5.45 kernel
From: Joel GUILLET @ 2002-12-17 15:21 UTC (permalink / raw)
  To: linux-ia64

Hello,

I'm working on a Lion machine (with 2 processors Itanium I) running
a 2.5.45 kernel, and I've got thousands of interruptions routed throw
ACPI.

I use PS/2 mouse and keyboard.
I've seen there were lots of problems with PS/2 on 2.5-ia64 kernels but I
didn't see anyone who had this one.

When I say "lots" of interruptions, I mean about 80 times more than the
timer ticks !!!! So, one of my processor spend almost all his time dealing
with ACPI interruptions .

Just to have a look, I've tried to disable ACPI interruptions after the
boot. ...and now, the interruptions are reported via one of the serial irq
(according to the /proc/interrupts).. if it can help.

I had no problems with this interruptions in the 2.5.44 kernel or previous
versions. I searched the code to see what had changed between the 2
kernels, but I couldn't find any interesting explanation.
BUT I already had problems since the 2.5 kernels(like a lot of people)
with my mouse or/and my keyboard (with i8042).

So if you have any idea...?

Thanks in advance.


---------
** Joel



^ permalink raw reply

* Re: usbaudio won't do 24-bit or 32-bit i/o...
From: Takashi Iwai @ 2002-12-17 15:28 UTC (permalink / raw)
  To: Patrick Shirkey; +Cc: alsa-devel
In-Reply-To: <3DFE2295.2020502@boosthardware.com>

At Tue, 17 Dec 2002 03:59:33 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
> > 
> > the attached patch will (hopefully) do the same thing as qinit in the
> > kernel at the initialization (applied to the latest cvs).  please let
> > me know whether it works.
> 
> Ouch. The latest cvs results in a hard lock when loading the usb-audio 
> driver.

hmmm, it seems that the problem is on usb-uhci driver.
mysteriously, the midi part of quattro causes the kernel panic.  the
audio part seems ok.
you can avoid this either by using uhci driver or by commenting out
the entry for quattro in alsa-kernel/usb/usbquirks.h.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* Re: Domain transition
From: Russell Coker @ 2002-12-17 15:32 UTC (permalink / raw)
  To: Justin Smith, SELinux
In-Reply-To: <1040129546.1247.7.camel@jsmith.org>

On Tue, 17 Dec 2002 13:52, Justin Smith wrote:
> The one domain with high privileges similar to the old root privileges
> is the initrc_t domain.

It seems that initrc_t only really lacks the ability to write to arbitary 
files.  It can ifconfig interfaces (needed for network start scripts), start 
and stop daemons (it's primary purpose), and see everything in "ps ax".

> But transitions cause this domain to "cease to
> exist" by the time Linux has completely booted.

No, there's "run_init" to run scripts in that domain to start daemons.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: SysAdmin rants [was Re: counting shell args]
From: Scott Taylor @ 2002-12-17 15:36 UTC (permalink / raw)
  To: linux-admin
In-Reply-To: <Pine.LNX.4.33.0212171005410.13631-100000@router.windsormac hine.com>

At 07:15 AM 12/17/02, you wrote:
>On Mon, 16 Dec 2002, Scott Taylor wrote:
>
> > >is the ethernet unplugged AGAIN,
> >
> > Damn janitors!
>
>Janitors?

They always get me. :(

>I get the users unplugging their machines.  Had one guy
>complain his floppy drive and cdrom were broken.  I go up to the plant(2
>hour drive each way), and there's no screws on the case, the floppy drive
>is fubar, and the cdrom isn't even plugged in, and if it were, it wouldn't
>work anyways cause it was set to Master with the hard drive on the same
>cable set to master.  And the ethernet cable hanging from the wall.

Good grief!

>Guy put a TV tuner card in his machine by himself. (pentium 200 too)
>
>Got stuck when he had no network, no floppy drive, and no cdrom to install
>drivers with.
>
>We don't even have soundcards in the machines, why did he think we'd allow
>a TV Tuner board?
>
>He won't be doing that again.  He's stuck with his 5" b&w portable now.

ROFL!

I used to admin a plant once too, never had that kind of trouble, but they 
knew not to mess with _MY_ hardware.  Now I consult for that plant and the 
new admin has lost all control.  It's scary some of the things they get 
away with out there; but good for my pocket book. :)

Worst thing I ever saw was some doe head was messing with his tower, that 
was on a box to raise it off the floor, next to his desk.  When he leaned 
over it to check a connection the CD bay closed on the shirt tail which was 
sticking out of his fly.  Wish I had a camera with me.

Scott.



^ permalink raw reply

* Re: counting shell args
From: Scott Taylor @ 2002-12-17 15:38 UTC (permalink / raw)
  To: linux-admin
In-Reply-To: <Pine.LNX.4.50.0212162211130.217-100000@athame.gmpexpress.n et>

At 07:11 PM 12/16/02, you wrote:
>Check argc for a value once script has started.

Interesting concept.

How do you go about this?

Which shell are you using?


^ permalink raw reply

* Re: Via 8233 flooding of errors [2.4-ac]
From: Nathaniel Russell @ 2002-12-17 15:49 UTC (permalink / raw)
  To: alan; +Cc: alan, reddog83, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171033071.1576-100000@reddog.example.net>

Alan,
What would you like to me to send you all i play are mp3's and i watch DVD's???
And about the ignoring drained playback i can just ignore that paranoia, that
is fine with me. Oh and yes i hit ^C to stop the mp3 player :).

CC me <reddog83@chartermi.net>
On 17 Dec 2002, Alan Cox wrote:

> On Tue, 2002-12-17 at 11:41, Nathaniel Russell wrote:
> > Hello
> > When i play 3 or more songs in a row i get the error message of
> > drained playback and my audio just shuts off until i exit the mp3 program
> > and reload it. Every 3rd song though it stops playing. And plus once in
> > awhile i get a Assertion failed message. Help please....
> > Nathaniel
>
> > Assertion failed! chan->is_active == sg_active(chan->iobase),via82cxxx_audio.c,via_chan_maybe_start,line=1347
> > via_audio: ignoring drain playback error -512
> > [SNIPED]
>
> I need to look at the assertion - somehow the chip is being stopped when
> it should not have been. The ignoring drain playback error one is over
> paranoia in the driver and quite legal (you hit ^C is what made that
> second moan appear)
>





^ permalink raw reply

* Re: Via 8233 flooding of errors [2.4-ac]
From: Alan Cox @ 2002-12-17 16:31 UTC (permalink / raw)
  To: Nathaniel Russell; +Cc: alan, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171035450.1629-100000@reddog.example.net>

On Tue, 2002-12-17 at 15:49, Nathaniel Russell wrote:
> Alan,
> What would you like to me to send you all i play are mp3's and i watch DVD's???
> And about the ignoring drained playback i can just ignore that paranoia, that
> is fine with me. Oh and yes i hit ^C to stop the mp3 player :).

Ok lets see if I understand what is actually going on. Can you try

--- drivers/sound/via82cxxx_audio.c~	2002-12-17 15:47:21.000000000 +0000
+++ drivers/sound/via82cxxx_audio.c	2002-12-17 15:48:51.000000000 +0000
@@ -15,7 +15,7 @@
  */
 

-#define VIA_VERSION	"1.9.1-ac"
+#define VIA_VERSION	"1.9.1-ac2"
 

 #include <linux/config.h>
@@ -1344,7 +1344,11 @@
 
 static inline void via_chan_maybe_start (struct via_channel *chan)
 {
-	assert (chan->is_active == sg_active(chan->iobase));
+	if(chan->is_active != sg_active(chan->iobase))
+	{
+		chan->is_active = 0;
+		printk(KERN_ERR "via82cxx_audio: DSP stopped unexpectedly.\n");
+	}
 
 	if (!chan->is_active && chan->is_enabled) {
 		chan->is_active = 1;
@@ -3275,7 +3279,7 @@
 
 	if (file->f_mode & FMODE_WRITE) {
 		rc = via_dsp_drain_playback (card, &card->ch_out, nonblock);
-		if (rc && rc != ERESTARTSYS)	/* Nobody needs to know about ^C */
+		if (rc && rc != -ERESTARTSYS)	/* Nobody needs to know about ^C */
 			printk (KERN_DEBUG "via_audio: ignoring drain playback error %d\n", rc);
 
 		via_chan_free (card, &card->ch_out);

^ permalink raw reply

* Re: another seagate for the black-list?
From: Manish Lachwani @ 2002-12-17 15:52 UTC (permalink / raw)
  To: Aryix; +Cc: linux-kernel
In-Reply-To: <courier.3DFF30A8.000033A8@softhome.net>


>From dmesg that you sent me:

hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide1: reset: success
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide1: reset: success

which shows CRC errors. And in this case, there will
be a UDMA downgrade. Send me the SMART data using
smartctl and replace the cabling. The drive is
initialized UDMA 66

hda: 58633344 sectors (30020 MB) w/418KiB Cache,
CHS=3649/255/63, (U)DMA
blk: queue c030a928, I/O limit 4095Mb (mask
0xffffffff)
hdc: 12596850 sectors (6450 MB) w/256KiB Cache,
CHS=13330/15/63, UDMA(66)

but the UDMA is downgraded on CRC. Thats the expected
behavior



--- Aryix <aryix@softhome.net> wrote:
> On Tue, 17 Dec 2002 06:07:34 -0800
> Manish Lachwani <manish@Zambeel.com> wrote:
> 
> >  Did you send me dmesg o/p?
> > 
> > Send me e-mail at m_lachwani@yahoo.com since I
> will access that shortly 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Aryix
> > To: Manish Lachwani
> > Sent: 12/17/02 5:48 AM
> > Subject: Re: another seagate for the black-list?
> > 
> > On Tue, 17 Dec 2002 05:45:57 -0800
> > Manish Lachwani <manish@Zambeel.com> wrote:
> > 
> > > When you use hdparm -X ..., can you also check
> dmesg for any IDE
> > warnings.
> > > Also, do a hdparm -I /dev/hdX 
> > > 
> Thank you!
>
--------------------------------------------------------------------------
> pub  1024D/BE8E00BE 2002-12-06 Aryix Berius
> (nothing) <aryix@softhome.net>
>      Key fingerprint = 249D C5BC 8B9A C46A C7F4 
> 397D 2A6D 9FF6 BE8E 00BE
> sub  2048g/C1C6CB29 2002-12-10 (linux.sophia.org.ar
> at 200.70.32.145)
> 
> 

> ATTACHMENT part 2 application/octet-stream
name=dmesg



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

^ permalink raw reply

* Re: Domain transition -- enabling user_r in eklogin
From: forrest whitcher @ 2002-12-17 15:48 UTC (permalink / raw)
  To: Russell Coker; +Cc: SELinux
In-Reply-To: <200212171431.52724.russell@coker.com.au>

On Tue, 17 Dec 2002 14:31:52 +0100 
Russell Coker <russell@coker.com.au> did inscribe thusly:

> Redirecting a port 23 connection to one on the local machine and then 
> establishing a new connection to the server is quite easy if you control a 
> router.  Going from that to taking over an idle session is quite easy.
> 

Which is a good reason to use eklogin / 3des encription over kerberized
rlogin. 


For which I've been having problems getting an appropriate transition working.
(the following may have some typos I don't have either box running just now
to refer to)

The remote_login domain was clearly designed with telnet in mind, there is
no transtion to user_u:user_r.

Looking this over I moved login.krb5 into the same SID as /bin/login, using
login.te as an example, however once the user's successfully authenticated
the domain remains system_u:system_r and 'newrole(1)' is not available.

I'm going somewhat from memory so there may be some missed details, however
I've tried re-configuring several times without much luck.

Also this test is being done on a slackware setup, because I was able to
get telnetd working in a redhat system more easily there may be some system 
layout issues causing problems, not sure yet.

forrest

--
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-mjb1 (scalability / NUMA patchset)
From: William Lee Irwin III @ 2002-12-17 15:57 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: linux-kernel, gh
In-Reply-To: <568990000.1040112629@titus>

On Tue, Dec 17, 2002 at 12:10:29AM -0800, Martin J. Bligh wrote:
> The patchset contains mainly scalability and NUMA stuff, and
> anything else that stops things from irritating me. It's meant
> to be pretty stable, not so much a testing ground for new stuff.
> I'd be very interested in feedback from other people running
> large SMP or NUMA boxes.
> http://www.aracnet.com/~fletch/linux/2.5.52/patch-2.5.52-mjb1.bz2

BTW, the mem_map initialization stuff has been pretty well shaken down,
so it's safe to slurp that up now.


Bill

^ permalink raw reply

* Compile warnings due to missing __inline__ in fs/xfs/xfs_log.h
From: Thomas Schlichter @ 2002-12-17 16:01 UTC (permalink / raw)
  To: linux kernel mailing list

As the __inline__ directive in front of the _lsn_cmp function is not used with
the gcc version 2.95.x, compile-warnings result from many files including this
header-file.

Is there any reason why this function is not inlined with these compiler
versions? As I used following patch and compiled the kernel with my
gcc2.95.3(SuSE) and an other gcc2.95.4(Debian) these compiler warnings
disappeared and no additional warning or error occured...

Is there an difference between '__inline__' and 'inline'?
Is 'inline' not part of the ANSI-C standard and so should be preferred?

Thanks

  Thomas Schlichter


diff -u linux-2.5.52/fs/xfs/xfs_log.h linux-2.5.52_patched/fs/xfs/xfs_log.h
--- linux-2.5.52/fs/xfs/xfs_log.h	Mon Dec 16 03:08:24 2002
+++ linux-2.5.52_patched/fs/xfs/xfs_log.h	Tue Dec 17 15:00:13 2002
@@ -52,12 +52,7 @@
  * By comparing each compnent, we don't have to worry about extra
  * endian issues in treating two 32 bit numbers as one 64 bit number
  */
-static
-#ifdef __GNUC__
-# if !((__GNUC__ == 2) && (__GNUC_MINOR__ == 95))
-__inline__
-#endif
-#endif
+static inline
 xfs_lsn_t	_lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch)
 {
 	if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch))


^ permalink raw reply

* Re: Intel P6 vs P7 system call performance
From: John Reiser @ 2002-12-17 16:01 UTC (permalink / raw)
  To: linux-kernel

On Mon, 16 Dec 2002, Linus Torvalds wrote [regarding vsyscall implementation]:
 > The good news is that the kernel part really looks pretty clean.

Where is the CPU serializing instruction which must be executed before return
to user mode, so that kernel accesses to hardware devices are guaranteed to
complete before any subsequent user access begins?  (Otherwise a read/write
by the user to a memory-mapped device page can appear out-of-order with respect
to the kernel accesses in a preceding syscall.)  The only generally useful
serializing instructions are IRET and CPUID; only IRET is implemented univerally.

-- 
John Reiser, jreiser@BitWagon.com


^ permalink raw reply

* Re: Intel P6 vs P7 system call performance
From: Hugh Dickins @ 2002-12-17 16:12 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, Ulrich Drepper, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162140500.1644-100000@home.transmeta.com>

On Mon, 16 Dec 2002, Linus Torvalds wrote:
> 
> Ok, I did the vsyscall page too, and tried to make it do the right thing
> (but I didn't bother to test it on a non-SEP machine).
> 
> I'm pushing the changes out right now, but basically it boils down to the
> fact that with these changes, user space can instead of doing an
> 
> 	int $0x80
> 
> instruction for a system call just do a
> 
> 	call 0xfffff000

I thought that last page was intentionally left invalid?

So that, for example, *(char *)MAP_FAILED will give SIGSEGV;
whereas now I can read a 0 there (and perhaps you should be
using get_zeroed_page rather than __get_free_page?).

I cannot name anything which relies on that page being invalid,
but think it would be safer to keep that it way; though I guess
more compatibility pain to use the next page down (or could
seg lim be used? I forget the granularity restrictions).

Hugh


^ permalink raw reply

* MPC8265/6 and PCI support
From: None Atall @ 2002-12-17 16:04 UTC (permalink / raw)
  To: linuxppc-embedded


 Hello everybody!
I have started writting a PCI driver for Motorola's
MPC8265/6 processors (about 45% complete, untested).
This code will be open source, since this is developed
in my free time :)
 Is there anybody out there developing such a code?
Is he/she willing to help?

                         c ya,
                          Dimitris.

----------------------
Dimitrios Meidanis
Hardware/Software Engineer
http://www.csd.uoc.gr/~meidanis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re:slow NFS performance extracting bits from large files
From: Heflin, Roger A. @ 2002-12-17 16:04 UTC (permalink / raw)
  To: nfs; +Cc: ballen




> Thank you very much. This is a reasonable (obvious!) explanation.  Let =
me
> see if I undertand correctly.
>=20
> I just looked up the specs for the local disk that I was using for the
> comparison testing.  It averages around 600 512-byte sectors (300 kB) =
per
> track, and 1ms average track to track seek time.  So (assuming little
> fragmentation) a typical file is spread across 3 to 4 tracks of the =
disk. =20
> Thus, if I seek to a data set in the middle of a file, and assuming =
that
> the files are "more or less" contiguous on the disk, a typical =
iteration
> of the loop above starting from the first read, should involve:
>=20
> read 32 bytes
> seek to middle    (2 tracks) 2 msec
> read 620 bytes
> seek to next file (2 tracks) 2 msec
>=20
> hence 4 msec/file x 10k files =3D 40 sec read time if the kernel disk =
cache
> buffers are all dirty.  Does the estimate above look reasonable?
>=20
> I'll do the experiment that you suggest, using wc to clear the cache
> first, and see how this compares to what's above.
>=20
	Track to track does not really count.  The average time per io is
	1/2 of the rotational latency.   If it is a 7200 rpm disk, it means
	that even once you get to the proper track it takes 1/2 * 60/7200 =
seconds
	for the proper data to come under the head on average.   The number
	for the above is 4.2ms and then you need to add in the track-to-track
	number to get 5.2ms or so per operation.   And probably you have a =
operation
	also to open each file.   And given that the filename entry data (name, =
and such) may
	not be close, it may not be a short quick seek, it may take longer.  =
Exactly
	how many seeks you have depends on exactly how the filesystem lays
	the data out on disk.

	So you have open, read32b, read620b, each taking 5.2ms or so, so a =
total
	of 15.6ms per file, times 10k files =3D 156 seconds, and that is in a =
perfect
	world.   You may also have a operation to update the file access time =
since
	you have read the file, and each of the seeks could require a read to =
figure
	out exactly where that block actually is on disk.  So there could be as
	many as 4 reads and a write going on on the far end.   And then on top
	of that you have the network latency of around a 1 ms or so to send
	the packets back and forth for each operation.   And my experience in
	the past has been that opens by themselves are pretty expensive, so
	there may be alot of operations going on in the background to make an
	open happen.  =20

> ttl=3D255 time=3D0.264 ms
> ....
> --- storage1.medusa.phys.uwm.edu ping statistics ---
> 26 packets transmitted, 26 received, 0% loss, time 25250ms
> rtt min/avg/max/mdev =3D 0.156/0.230/0.499/0.063 ms
>=20
> so 230 usec (average) x 30,000 =3D 7 seconds
>=20
> OK, so if all is well, then if I run the code locally on the NFS =
server
> itself (with disk cache buffers all dirty) it should take around 7
> seconds less time than if I run it on an NFS client.
>=20
> I'll check the numbers and report back.
>=20
>=20
	On the ping, you really need to ping for at least an hour or more, my
	experience is that if you are ping 1/second for an hour and you are
	losing 1 of 3600 pings (losing 1 ping per hour) it is very obvious to=20
	anything or anyone running that things are being affected, and this
	needs to be fixed.    A clean network will lose the pings at a rate
	of less than 1 of 3600.   And if you are losing 1 of 3600
	packets this will have ugly results on UDP nfs and even on
	other applications.

						Roger


> --__--__--
>=20
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20
>=20
> End of NFS Digest


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply

* Re: how to forward packets to another gateway, if i'm one
From: Andrea Rossato @ 2002-12-17 16:07 UTC (permalink / raw)
  To: netfilter
In-Reply-To: <ISPFE7vXn10A5fpk965000657df@mail.takas.lt>

Saulius Menkevicius wrote:
>   Now, I want to make some traffic that comes from some client and 
> that should go through gateway 10.0.0.1 to be forwarded to 10.0.0.2 
> (without any changes). The need is to make the forwarding transparent 
> to both 10.0.0.2 and the client.

in 10.0.0.1

ip rule add from YOUR_CLIENT [to DESTINATION] table fbsd.out
ip route add default via 10.0.0.2 dev $DEV table fbsd.out

I think this should do the job (for more information http://lartc.org/)
you create a routing table (fbsd.out) that will use 10.0.0.2 as gateaway 
for packets comming from your client.

I did not test this config, since I'm marking packets in the FORWARD 
chain of the mangle table and use
ip rule add fwmark to route them.

hope this helps.
andrea



^ permalink raw reply

* Re: USB PCI
From: Ray Olszewski @ 2002-12-17 16:07 UTC (permalink / raw)
  To: linux-newbie
In-Reply-To: <20021217094200.13045.qmail@web2.mailbox.hu>

At 10:41 AM 12/17/02 +0100, Korosi Akos wrote:
>Hi!
>
>dashielljt <dashielljt@gmpexpress.net> wrote:
>
> >Here's your problem.  You must have a bios on that computer that has a
> > date on or after July 1, 1989.
>...
> > Jude <dashielljt(at)gmpexpress-dot-net>
>
>Thanks! And if the bios is newer, than this date
>(I could check this only in weekend), then
>there are no other problems?

Based on reading Jude's original reply, I'm almost certain that "1989" was 
a typo and should read "1999". (USB was not even an idea in 1989, let alone 
a BIOS feature. The original message went on to comment, "Many unethical 
computer vendors were installing usb equipment before July 1999....") 
Beyond that ... this should be sufficient to let the kernel's USB support 
work. Whether you have "other problems" or not depends on the specific USB 
devices you want to use ... an increasing number are supported by the Linux 
kernel, but there's no way to know if unnamed devices are supported or not, 
or what the difficulties of getting them to work might be.


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
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: Intel P6 vs P7 system call performance
From: John Reiser @ 2002-12-17 16:14 UTC (permalink / raw)
  To: linux-kernel

Ulrich Drepper wrote:
[snip]
  >    pushl %ebp
  >    movl $0xfffff000, %ebp
  >    call *%ebp
  >    popl %ebp

This does not work for mmap64 [syscall 192], which passes a parameter in %ebp.

-- 
John Reiser, jreiser@BitWagon.com


^ permalink raw reply

* Re: TTY_FLIPBUF_SIZE
From: Stuart MacDonald @ 2002-12-17 16:13 UTC (permalink / raw)
  To: Sriram Narasimhan, linux-serial
In-Reply-To: <3DFF0DFF.8030505@tataelxsi.co.in>

From: "Sriram Narasimhan" <nsri@tataelxsi.co.in>
> The TTY_FLIPBUF_SIZE is restricted to 2 * 512 bytes. Can this be
> increased to support synchronous serial lines without affecting other
> serial drivers which still stick to the TTY_FLIPBUF_SIZE limit ?

No. Check the code. struct tty_struct depends on being less than one
page (4 kb) in size, and making the flip bufs any much bigger will
break that.

..Stu



^ permalink raw reply


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.