* Re: update_mmu_cache bug
From: Brian Murphy @ 2002-12-10 21:00 UTC (permalink / raw)
To: linux-mips; +Cc: Ralf Baechle
In-Reply-To: <20021210191801.GF609@gateway.total-knowledge.com>
ilya@theIlya.com wrote:
>Following small patch is needed to prevent kernel from going into infinite loop
>on page_fault. Probably similar patches are needed for other CPUs as well,
>but since I don;t have any, I'll let those who do take care of that :)
>
> Ilya.
>
>
>
It also seems not to work for the 32 bit kernel. The macro for
pte_offset_map
is very different in pgtable.h in the 32 bit directory than the 64 bit.
(Is there a good reason for this Ralf?)
/Brian
^ permalink raw reply
* vmalloc
From: Imran Badr @ 2002-12-10 21:02 UTC (permalink / raw)
To: Linux-kernel
In-Reply-To: <20021210205045.GB63@DervishD>
Hi,
Is there any limitation on the amount of memory that can be allocated by
using vmalloc ( like 128KB for kmalloc) ?
Thanks,
Imran.
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: James Bottomley @ 2002-12-10 20:58 UTC (permalink / raw)
To: Justin T. Gibbs
Cc: James Bottomley, Christoph Hellwig, linux-scsi, Alan Cox,
Marcelo Tosatti, Linus Torvalds
In-Reply-To: <649720000.1039550610@aslan.btc.adaptec.com>
gibbs@scsiguy.com said:
> Unfortunately, even though I've setup a BK repository in an attempt to
> make this task easier, BK doesn't do what I want. It seems that only
> if I can push to a public repository or can export my repository for
> others to pull from, will BK auto-matically figure out which change
> sets don't exist where and generate the correct stuff. Unfortunately
> my IT department will not allow me to export a BK server, so that is
> out of the question. Anyone care to tell me the magic incantation to
> get BK to generate a cumulative patch set against the parent
> repository? Or must I do a second clone and manually create patches?
You can "borrow" a public repository on bkbits.net. See
http://www.bitkeeper.com/Hosted.html
There isn't a way to diff two respositories, but you can see the differences
with bk changes -{L|R} <other repository> and make diffs for each change set.
(alternatively, if the child is just the parent with only your patches tacked
on, you can diff from the common ancestor).
James
^ permalink raw reply
* Re: hard drive head parking in linux
From: Chuck Gelm @ 2002-12-10 20:58 UTC (permalink / raw)
To: Jerry James Haumberger; +Cc: linux-newbie
In-Reply-To: <200212101811.LAA18667@cu.imt.net>
Jerry James Haumberger wrote:
>
> Hello, Steven --
>
> >> I understand that early PC hard drives had to have
> >> their heads parked when shut down,
>
> >A blast from the past. Yes, indeed, pre-IDE drives
> >(two data cables) needed parking. Over the years I've
> >had several of these monsters. I even installed a small
> >Linux on one (it had to be small 'cause the HD was only
> >20mb :-). Did you know that the latest Slackware (8.1)
> >still provides a stock kernel (xt.i) for such drives?
> >Imagine that: a 2.4.18 kernel on an old Seagate MFM.
>
> But do you know whether or not Linux lifts the HD heads after a
> period of inactivity, or is this already an automatic feature
> of the later hard drives... say, my (approx.) 700MB HD on
^^^^^^^^
They made MFM or RLL drives that big?
I would guess that a drive that big is IDE. :-|
Regards, Chuck
-
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: [BENCHMARK] 2.5.51 with contest
From: Robert Love @ 2002-12-10 21:05 UTC (permalink / raw)
To: Stan Bubrouski; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3DF64852.9030006@ccs.neu.edu>
On Tue, 2002-12-10 at 15:02, Stan Bubrouski wrote:
> I disagree, 2.4.20 is the current stable kernel, it would
> be nice to see how it compares to the current development,
> what's faster, what's not... from Con's previous results
> we can see that some things are indeed not as fast in 2.5.x
> as in 2.4.x. It's just nice to be able to see the whole
> picture. I often follow these threads for just this purpose.
Like I said, that may give users warm fuzzies or be helpful to marketing
folks but Con's benchmark is not really useful for _helping developers_
wrt comparing 2.4 vs 2.5.
A benchmark like AIM9, which is a bunch of micro-benchmarks, is useful
because we can say "look truncating a zero-length file is a lot slower
now".
But a contest result from 2.4 to 2.5 tells us what? Especially since
lower times in contest may not even be bad. Contest is invaluable for
testing one change vs. without. In fact, I would venture to say Con's
work is a big reason why 2.5 has the fairness and interactive
performance it does. But it is not so helpful to see changes since 2.4.
Robert Love
^ permalink raw reply
* config.h
From: Chuck Winters @ 2002-12-10 20:56 UTC (permalink / raw)
To: linux-c-programming
Would it be prudent to include the linux/config.h file in a user
level program to check for the existence of certain modules? I know
there are other ways, like using autoconf, etc. I was just wondering.
Chuck
^ permalink raw reply
* Alteon AceNIC Coper Seen as Fibre ? (and incorrect settings)
From: Stephan van Hienen @ 2002-12-10 21:03 UTC (permalink / raw)
To: sparclinux, linux-kernel
Sun UltraSparc 10
kernel 2.4.20
eth2: Alteon AceNIC Gigabit Ethernet at 0x1ff02900000, irq 6,7d0
Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:60:cf:20:92:fc
PCI bus width: 32 bits, speed: 33MHz, latency: 64 clks
eth2: Firmware up and running
unplugging the utp cable, and plugging back in gives :
eth2: 10/100BaseT link UP
eth2: Optical link DOWN
eth2: 10/100BaseT link UP
but this card is not an Fibre (Optical) card ?
also ethtool gives incorrect information :
(ethtool 1.7)
---
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Half
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
---
card is connected to 100mbit switch at full duplex
and i think Auto-negotiation is on ?
^ permalink raw reply
* Re: [LARTC] how to get the latency down on maxed out classes? + extra question
From: Stef Coene @ 2002-12-10 20:55 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103955243525543@msgid-missing>
> TC_UPLINK_RATE="100"
> TC_RATE[0]=50
> TC_CEIL[0]=110
So this class has ceil = 110kbit, but the parent class has ceil = 100kbit.
The parent ceil is not respected so this class can use 110kbit if it wants.
I don't think this is what you want.
> TC_RATE[1]=15
> TC_CEIL[1]=60
> TC_RATE[2]=10
> TC_CEIL[2]=60
> TC_RATE[3]=5
> TC_CEIL[3]=30
There is also a drawbeck if you use prio to improve latency. Devik did some
testing. A lower prio is good for delays IF the class with the lower prio
never sends more then it's rate (so it's never overlimited). If it do so,
other classes are served first and the delays will be very bad. I haven't
test it myself, but you can find it in the user guide of htb chapter 7
(http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio).
You can force a class to never exceeds its rate if you use a policer in the
filter so packets that exceeds the rate are dropped by the filter. But
again, I haven't test it.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH] fix strange stack calculation for secondary cpus
From: Dave Hansen @ 2002-12-10 21:00 UTC (permalink / raw)
To: dhow >> David Howells; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
in arch/i386/kernel/smpboot.c:
stack_start.esp = (void *) (1024 + PAGE_SIZE + (char *)idle);
This causes problems when I switch to 4k stacks? What is supposed to
be going on here? Why point esp into the middle of the stack? If you
wanted to do that, why not just use PAGE_SIZE>>2?
In any case, I think THREAD_SIZE needs to be here instead of PAGE_SIZE.
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #2: fix-esp-2.5.51.patch --]
[-- Type: text/plain, Size: 467 bytes --]
--- linux-2.5.50/arch/i386/kernel/smpboot.c.bad Tue Dec 10 12:56:10 2002
+++ linux-2.5.50/arch/i386/kernel/smpboot.c Tue Dec 10 12:56:55 2002
@@ -806,7 +806,7 @@
/* So we see what's up */
printk("Booting processor %d/%d eip %lx\n", cpu, apicid, start_eip);
- stack_start.esp = (void *) (1024 + PAGE_SIZE + (char *)idle->thread_info);
+ stack_start.esp = (void *) (THREAD_SIZE + (char *)idle->thread_info);
/*
* This grunge runs the startup process for
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Andrew McGregor @ 2002-12-10 20:50 UTC (permalink / raw)
To: Pavel Machek, Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021210204031.GF20049-jyMamyUUXNJG4ohzP4jBZS1Fcj925eT/@public.gmane.org>
I strongly suspect that s4bios will work on this machine, but swsusp won't.
Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia
put pm support in their driver, it's game over for Linux. Except that the
BIOS knows how to suspend it, so some kernel/driver combinations work with
APM. I suspect any Geforce2go Dell is the same.
Andrew
--On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
wrote:
> Hi!
>
>> > I concur with your pros and cons. This makes me think that if S4BIOS
>> > support ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
>
>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>> bad tables or "knowing" what other-os does)
>
> We have full control over S4 (== swsusp), so we can fix that in most
> cases.
>
> S4BIOS is still little friendlier to the user -- no need to set up
> swap partition and command line parameter, can't go wrong if you boot
> without resume=, etc.
> Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* [PATCH] SCSI tape driver fix for 2.5.51
From: Kai Makisara @ 2002-12-10 20:48 UTC (permalink / raw)
To: linux-scsi
The SCSI tape driver in 2.5.51 does not find any devices. The
following patch fixes this (and adds a missing unlocking call).
Kai
--- linux-2.5/drivers/scsi/st.c 2002-12-10 17:33:47.000000000 +0200
+++ linux-2.5-km1/drivers/scsi/st.c 2002-12-10 18:24:01.000000000 +0200
@@ -991,8 +991,10 @@
return (-EBUSY);
}
- if(!scsi_device_get(STp->device))
+ if(scsi_device_get(STp->device)) {
+ write_unlock(&st_dev_arr_lock);
return (-ENXIO);
+ }
STp->in_use = 1;
write_unlock(&st_dev_arr_lock);
STp->rew_at_close = STp->autorew_dev = (minor(inode->i_rdev) & 0x80) == 0;
^ permalink raw reply
* Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: DervishD @ 2002-12-10 20:59 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, marcelo
In-Reply-To: <20021210.124740.86261163.davem@redhat.com>
Hi David :)
> > + * NOTE: in this function we rely on TASK_SIZE being lower than
> > + * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
> > This assumption is wrong.
> OK, then another way of fixing the corner case that exists in
> do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
> is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
> when page-aligning the size.
> And after your patch, we'd use a zero length. That is a bug.
With my patch, we don't use a zero length :?? My patch sees if
PAGE_ALIGN will f*ck the length, and if so, it returns EINVAL. This
is better than getting '0' as a valid address when specifying a large
size, don't you think so?
> Look at what happens, you PAGE_ALIGN(len) after all the range checks
> then we use a len of '0' for the rest of the function. How is that
> supposed to be better?
Because PAGE_ALIGN won't return 0? I don't see your assumption of
'len' going to zero due to my patch :?? With my patch, if the
requested size is '0', then the hint address is returned, and if the
size is so high that PAGE_ALIGN will barf at it, returning 0 when it
shouldn't, mmap will return EINVAL. The function never uses a 'len'
of 0. Never.
Raúl
^ permalink raw reply
* IBM spamms me with error messages
From: Pavel Machek @ 2002-12-10 20:56 UTC (permalink / raw)
To: kernel list
Hi!
I replied to some mail on l-k and IBM spammed me with 20+ error
messages. Now it is apparently going to do that again.
IBM: I asked your postmasters to fix your mail systems, and you
apparently don't know how to do that. Can you fix it?!
I don't know what broken mailserver substituted my email address as
pavel%internet.vnet@RCHGATE.RCHLAND.IBM.COM, and I do not care much,
but STOP SPAMMING ME.
Pavel
RCHGATE.RCHLAND.IBM.COM unable to deliver following mail to
recipient(s):
<tinglett@rchmail.rchland.ibm.com>
RCHGATE.RCHLAND.IBM.COM received negative reply:
501 5.1.8 <@RCHGATE.RCHLAND.IBM.COM:PAVEL@INTERNET.RSCS>... Domain of
sender address PAVEL@INTERNET.RSCS does not exist
** Text of Mail follows **
Received: by RCHGATE.RCHLAND.IBM.COM (IBM VM SMTP Level 3A0) via
spool with SMTP id 6538 ; Tue, 10 Dec 2002 14:45:57 CST
Received: by RCHGATE (cvtto822 5.1.7) via <pavel@internet> id 2652
(NOTE)
for <tinglett@rchland>; Tue, 10 Dec 2002 14:45:57 -0600
Date: Tue, 10 Dec 2002 21:40:31 +0100
From: "Pavel Machek" <pavel%internet.vnet@RCHGATE.RCHLAND.IBM.COM>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
cc: "Grover, Andrew" <andrew.grover@intel.com>,
"'Ducrot Bruno'" <poup@poupinou.org>,
"Pavel Machek" <pavel%internet.vnet@RCHGATE.RCHLAND.IBM.COM>,
"Ducrot Bruno" <ducrot@poupinou.org>,
"Patrick Mochel" <mochel@osdl.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"ACPI mailing list" <acpi-devel@lists.sourceforge.net>
Subject: Re: =?iso-8859-1?Q?=DDACPI=A8=5F?=Re:
=?iso-8859-1?Q?=DD2.5.50,=5FACPI=A8=5F?=link error
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
In-Reply-To: <1039481341.12046.21.camel@irongate.swansea.linux.org.uk>
References:
<EDC461A30AC4D511ADE10002A5072CAD04C7A581@orsmsx119.jf.intel.com>
<1039481341.12046.21.camel@irongate.swansea.linux.org.uk>
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Sam Ravnborg @ 2002-12-10 20:53 UTC (permalink / raw)
To: John Bradford, Jaroslav Kysela; +Cc: linux-kernel, Kai Germaschewski
In-Reply-To: <200212101158.gBABwSnr003646@darkstar.example.net>
On Tue, Dec 10, 2002 at 11:58:28AM +0000, John Bradford wrote:
> make -f scripts/Makefile.build obj=sound/synth/emux
> ld -m elf_i386 -r -o sound/synth/built-in.o sound/synth/emux/built-in.o
> ld: cannot open sound/synth/emux/built-in.o: No such file or directory
> make[2]: *** [sound/synth/built-in.o] Error 1
> make[1]: *** [sound/synth] Error 2
> make: *** [sound] Error 2
kbuild in 2.5.51 requires that there exist one variable named obj-*
before built-in.o is generated.
In the Makefile for sound/synth/emux the variables obj-* is only set if
CONFIG_SND_SEQUENCER is set to y or m.
The best approach may be a derived bool defined in Kconfig, but
an alterneative solution is to rearrange the Makefile a bit.
Try the following (untested) patch.
Sam
===== Makefile 1.4 vs edited =====
--- 1.4/sound/synth/emux/Makefile Tue Jun 18 11:16:20 2002
+++ edited/Makefile Tue Dec 10 21:49:49 2002
@@ -5,16 +5,13 @@
export-objs := emux.o
+snd-emux-synth-objs-$(CONFIG_SND_SEQUENCER_OSS) := emux_oss.o
snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
- emux_effect.o emux_proc.o soundfont.o
-ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
- snd-emux-synth-objs += emux_oss.o
-endif
+ emux_effect.o emux_proc.o soundfont.o \
+ $(snd-emux-synth-objs-y)
# Toplevel Module Dependency
-ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
- obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
- obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
-endif
+sequencer-$(CONFIG_SND_SEQUENCER) += snd-emux-synth.o
+obj-$(CONFIG_SND_SBAWE) := $(sequencer-y) $(sequencer-m)
+obj-$(CONFIG_SND_EMU10K1) += $(sequencer-y) $(sequencer-m)
-include $(TOPDIR)/Rules.make
^ permalink raw reply
* Re: [BENCHMARK] 2.5.51 with contest
From: Arador @ 2002-12-10 20:51 UTC (permalink / raw)
To: Stan Bubrouski; +Cc: rml, conman, linux-kernel
In-Reply-To: <3DF64852.9030006@ccs.neu.edu>
On Tue, 10 Dec 2002 15:02:26 -0500
Stan Bubrouski <stan@ccs.neu.edu> wrote:
> I disagree, 2.4.20 is the current stable kernel, it would
> be nice to see how it compares to the current development,
> what's faster, what's not... from Con's previous results
> we can see that some things are indeed not as fast in 2.5.x
> as in 2.4.x. It's just nice to be able to see the whole
> picture. I often follow these threads for just this purpose.
>From this point, if you compare 2.4 vs 2.5 you can just say:
It's faster or slower. Comparing 2.5 vs 2.5 gives you a picture
of what's gone better, and why. IMHO.
Diego Calleja
^ permalink raw reply
* Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: David S. Miller @ 2002-12-10 20:47 UTC (permalink / raw)
To: raul; +Cc: linux-kernel, marcelo
In-Reply-To: <20021210204530.GA63@DervishD>
From: DervishD <raul@pleyades.net>
Date: Tue, 10 Dec 2002 21:45:30 +0100
Hi David :)
> + * NOTE: in this function we rely on TASK_SIZE being lower than
> + * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
> This assumption is wrong.
OK, then another way of fixing the corner case that exists in
do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
when page-aligning the size.
And after your patch, we'd use a zero length. That is a bug.
Anyway you cannot use a size larger than SIZE_MAX-PAGE_SIZE even
on sparc64, since mmap will fail when page aligning such a size,
returning 0 :((( Reverting the change is worse (IMHO).
This is wrong.
I said that the address space can be this huge size. I didn't
say that this means such a huge single mmap() could work.
It makes that your assumption that allows for the code change
you made is invalid.
if ((len = PAGE_ALIGN(len)) == 0)
and this returns 0 if the requested size ('len', here) is between
SIZE_MAX-PAGE_SIZE and SIZE_MAX. And this is wrong.
And your change causes us to use a len of "zero" in this case, how is
that more valid?
Look at what happens, you PAGE_ALIGN(len) after all the range checks
then we use a len of '0' for the rest of the function. How is that
supposed to be better?
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Alan Cox @ 2002-12-10 21:24 UTC (permalink / raw)
To: Daniel Egger; +Cc: Dave Jones, Linux Kernel Mailing List
In-Reply-To: <1039549178.7224.7.camel@sonja>
On Tue, 2002-12-10 at 19:39, Daniel Egger wrote:
> Do you have pointers to some optimisation manual or whatever?
> gcc currently defines the c3 as 486+mmx+3dnow however I doubt
> that this model is entirely correct and as such leaves some
> space for improvements.
VIA are a little odd at times. A vendor that doesn't publish CPU manuals
and push optimisation data at app writers is -odd- by my standards
anyway. I've been discussing a few things with VIA recently and we'll
see what happens over time.
Alan
^ permalink raw reply
* Re: [BK-2.4] [Patch] Small do_mmap_pgoff correction
From: DervishD @ 2002-12-10 20:50 UTC (permalink / raw)
To: Linux-kernel
Hi David :)
> + * NOTE: in this function we rely on TASK_SIZE being lower than
> + * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
> This assumption is wrong.
OK, then another way of fixing the corner case that exists in
do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
when page-aligning the size.
Anyway you cannot use a size larger than SIZE_MAX-PAGE_SIZE even
on sparc64, since mmap will fail when page aligning such a size,
returning 0 :((( Reverting the change is worse (IMHO).
> Please revert this change, it adds absolutely nothing.
It corrects the corner case. See below. If you have a better
solution for the corner case problem that doesn't involve limiting
the max size you can request for mmaping so it doesn't get the last
page, it is welcome, of course :))
The code says:
if ((len = PAGE_ALIGN(len)) == 0)
and this returns 0 if the requested size ('len', here) is between
SIZE_MAX-PAGE_SIZE and SIZE_MAX. And this is wrong. Don't know if
under sparc64 the PAGE_ALIGN macro returns correct values, but I
don't think so, since the correct value for an address in the last
page is 0 when page aligned. The problem is that we are aligning a
SIZE, not an address :((
Maybe a new macro needed here...
If you want the entire explanation, just tell :) I wrote in the
past for the same patch. Anyway, nor Linus nor Alan did see anything
wrong with this :??
Raúl
^ permalink raw reply
* Re: GDB patch
From: Nigel Stephens @ 2002-12-10 20:40 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Carsten Langgaard, Ralf Baechle, linux-mips
In-Reply-To: <20021210193241.GA15908@nevyn.them.org>
Daniel Jacobowitz wrote:
>>Actually Carsten *is* trying to implement a protocol, it's just that
>>it's an extension to the gdb remote debug protocol, as used in our
>>SDE-MIPS toolchain (viz sde-gdb). Algorithmics (now MIPS Technologies
>>UK), always extended the gdb remote debug protocol to support reading
>>and writing of single registers, and to support variable register
>>sizes (to allow a 64-bit debug stub to inter-work with gdb debugging a
>>32-bit application).
>>
>>
>
>My point is that we implement the GDB protocol, for use with GDB -
>implementing random extensions to it is not a good idea. I would
>strongly prefer these extensions be discussed on the GDB list before
>you try adding them to the CVS tree. Also, I bet Andrew has a
>different idea of how the 64/32 thing ought to work than you do. He's
>the remote protocol maintainer.
>
>These things should be planned on the GDB side before making yet more
>stubs use them.
>
>
I thought the Linux community prided itself on inventing new and
"non-standard" extensions to the toolchain ;-). But yes, we should try
to avoid incompatible changes. As part of MIPS we will hopefully have
the resources to interface with the rest of the GNU community, and argue
for the inclusion of our patches in the CVS trees.
>>When we first implemented these extensions we used the 'R' command to
>>write a single register, and 'r' to read one (they weren't then used
>>by gdb). Since then the remote protocol has gained the 'P' command to
>>
>>
>
>'R' was added in 1995 according to my records. Really?
>
>
Yup. SDE-MIPS 1.1 shipped in 1992. :-)
>The protocol does, actually. GDB doesn't _implement_ it, but the
>extension is documented in the manual ('p') and I wouldn't be surprised
>if Red Hat actually had an implementation somewhere. I recommend the
>documentation of the protocol, on the GDB web site.
>
>Also note that `R' is extended restart process; the manual lists `r' as
>"restart entire target system". I don't know when that was used but
>it's reason enough to stay away from using that letter to read a
>register.
>
>
Yeah, that's why we dropped 'R' in our more recent gdb ports, but I
wasn't aware of the new use of 'r' - I'll check out that page.
Certainly 'p' is the logical inverse of 'P', so we'll change our gdb
remote stub to use that. So how about accepting Carsten's change, with
the 'R' case removed, and 'r' changed to 'p'?
Nigel
--
Nigel Stephens Mailto:nigel@mips.com
_ _ ____ ___ MIPS Technologies (UK) Phone.: +44 1223 706200
|\ /|||___)(___ The Fruit Farm Direct: +44 1223 706207
| \/ ||| ____) Ely Road, Chittering Fax...: +44 1223 706250
TECHNOLOGIES (UK) Cambridge CB5 9PH Cell..: +44 7976 686470
[formerly Algorithmics] England http://www.algor.co.uk
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Pavel Machek @ 2002-12-10 20:40 UTC (permalink / raw)
To: Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Pavel Machek,
Ducrot Bruno, Patrick Mochel, Linux Kernel Mailing List,
ACPI mailing list
In-Reply-To: <1039481341.12046.21.camel-MMxVpc8zpTQVh3rx8e9g/fyykp6/JSeS3vcXtXqGYxw@public.gmane.org>
Hi!
> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.
And S4BIOS will never get added to 2.4 since it needs driver model
:-(.
> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)
We have full control over S4 (== swsusp), so we can fix that in most
cases.
S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: DervishD @ 2002-12-10 20:45 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, marcelo
In-Reply-To: <20021210.121908.00373632.davem@redhat.com>
Hi David :)
> + * NOTE: in this function we rely on TASK_SIZE being lower than
> + * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
> This assumption is wrong.
OK, then another way of fixing the corner case that exists in
do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
when page-aligning the size.
Anyway you cannot use a size larger than SIZE_MAX-PAGE_SIZE even
on sparc64, since mmap will fail when page aligning such a size,
returning 0 :((( Reverting the change is worse (IMHO).
> Please revert this change, it adds absolutely nothing.
It corrects the corner case. See below. If you have a better
solution for the corner case problem that doesn't involve limiting
the max size you can request for mmaping so it doesn't get the last
page, it is welcome, of course :))
The code says:
if ((len = PAGE_ALIGN(len)) == 0)
and this returns 0 if the requested size ('len', here) is between
SIZE_MAX-PAGE_SIZE and SIZE_MAX. And this is wrong. Don't know if
under sparc64 the PAGE_ALIGN macro returns correct values, but I
don't think so, since the correct value for an address in the last
page is 0 when page aligned. The problem is that we are aligning a
SIZE, not an address :((
Maybe a new macro needed here...
If you want the entire explanation, just tell :) I wrote in the
past for the same patch. Anyway, nor Linus nor Alan did see anything
wrong with this :??
Raúl
^ permalink raw reply
* ether_crc wrong in 2.5.50
From: Manfred Spraul @ 2002-12-10 20:35 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
The ether_crc were converted to use the crc32 library in 2.5.
The conversion is incorrect:
crc32_le and _be are about the bit order in which the bits are processed:
_le means least significant bit first, _be msb first.
ethernet is always lsb first.
ether_crc means the output should be in the cpu bit order [msb in bit 31],
ether_crc_le means the output should be with msb in bit 0: that what
crc32_le usually generates.
The attached patch is tested with winbond-840, natsemi and 8139too, i.e.
ether_crc works.
ether_crc_le generates the same output as the inline functions from
2.4.18, but it's untested due to lack of nics.
Could someone test it on a nic that uses ether_crc_le?
--
Manfred
[-- Attachment #2: patch-crc --]
[-- Type: text/plain, Size: 3707 bytes --]
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 5
// SUBLEVEL = 50
// EXTRAVERSION =
--- 2.5/include/linux/crc32.h 2002-11-04 23:30:16.000000000 +0100
+++ build-2.5/include/linux/crc32.h 2002-12-10 19:15:50.000000000 +0100
@@ -9,9 +9,19 @@
extern u32 crc32_le(u32 crc, unsigned char const *p, size_t len);
extern u32 crc32_be(u32 crc, unsigned char const *p, size_t len);
+extern u32 bitreverse(u32 in);
#define crc32(seed, data, length) crc32_le(seed, (unsigned char const *)data, length)
+
+/*
+ * Helpers for hash table generation of ethernet nics:
+ *
+ * Ethernet sends the least significant bit of a byte first, thus crc32_le
+ * is used. The output of crc32_le is bit reversed [most significant bit
+ * is in bit nr 0], thus it must be reversed before use. Except for
+ * nics that bit swap the result internally...
+ */
+#define ether_crc(length, data) bitreverse(crc32_le(~0, data, length))
#define ether_crc_le(length, data) crc32_le(~0, data, length)
-#define ether_crc(length, data) crc32_be(~0, data, length)
#endif /* _LINUX_CRC32_H */
--- 2.5/lib/crc32.c 2002-11-04 23:30:03.000000000 +0100
+++ build-2.5/lib/crc32.c 2002-12-10 19:16:47.000000000 +0100
@@ -255,6 +255,16 @@
}
#endif
+u32 bitreverse(u32 x)
+{
+ x = (x >> 16) | (x << 16);
+ x = (x >> 8 & 0x00ff00ff) | (x << 8 & 0xff00ff00);
+ x = (x >> 4 & 0x0f0f0f0f) | (x << 4 & 0xf0f0f0f0);
+ x = (x >> 2 & 0x33333333) | (x << 2 & 0xcccccccc);
+ x = (x >> 1 & 0x55555555) | (x << 1 & 0xaaaaaaaa);
+ return x;
+}
+
/*
* A brief CRC tutorial.
*
@@ -399,16 +409,6 @@
}
#endif
-static u32 attribute((const)) bitreverse(u32 x)
-{
- x = (x >> 16) | (x << 16);
- x = (x >> 8 & 0x00ff00ff) | (x << 8 & 0xff00ff00);
- x = (x >> 4 & 0x0f0f0f0f) | (x << 4 & 0xf0f0f0f0);
- x = (x >> 2 & 0x33333333) | (x << 2 & 0xcccccccc);
- x = (x >> 1 & 0x55555555) | (x << 1 & 0xaaaaaaaa);
- return x;
-}
-
static void bytereverse(unsigned char *buf, size_t len)
{
while (len--) {
--- 2.5/drivers/net/natsemi.c 2002-11-04 23:30:05.000000000 +0100
+++ build-2.5/drivers/net/natsemi.c 2002-12-10 19:20:01.000000000 +0100
@@ -164,6 +164,7 @@
#include <linux/delay.h>
#include <linux/rtnetlink.h>
#include <linux/mii.h>
+#include <linux/crc32.h>
#include <asm/processor.h> /* Processor type for cache alignment. */
#include <asm/bitops.h>
#include <asm/io.h>
@@ -1898,44 +1899,6 @@
return &np->stats;
}
-/**
- * dp83815_crc - computer CRC for hash table entries
- *
- * Note - this is, for some reason, *not* the same function
- * as ether_crc_le() or ether_crc(), though it uses the
- * same big-endian polynomial.
- */
-#define DP_POLYNOMIAL 0x04C11DB7
-static unsigned dp83815_crc(int length, unsigned char *data)
-{
- u32 crc;
- u8 cur_byte;
- u8 msb;
- u8 byte, bit;
-
- crc = ~0;
- for (byte=0; byte<length; byte++) {
- cur_byte = *data++;
- for (bit=0; bit<8; bit++) {
- msb = crc >> 31;
- crc <<= 1;
- if (msb ^ (cur_byte & 1)) {
- crc ^= DP_POLYNOMIAL;
- crc |= 1;
- }
- cur_byte >>= 1;
- }
- }
- crc >>= 23;
-
- return (crc);
-}
-
-
-void set_bit_le(int offset, unsigned char * data)
-{
- data[offset >> 3] |= (1 << (offset & 0x07));
-}
#define HASH_TABLE 0x200
static void __set_rx_mode(struct net_device *dev)
{
@@ -1960,9 +1923,8 @@
memset(mc_filter, 0, sizeof(mc_filter));
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
i++, mclist = mclist->next) {
- set_bit_le(
- dp83815_crc(ETH_ALEN, mclist->dmi_addr) & 0x1ff,
- mc_filter);
+ int i = (ether_crc(ETH_ALEN, mclist->dmi_addr) >> 23) & 0x1ff;
+ mc_filter[i/8] |= (1 << (i & 0x07));
}
rx_mode = RxFilterEnable | AcceptBroadcast
| AcceptMulticast | AcceptMyPhys;
^ permalink raw reply
* Re: 2.2 networking, NET_BH latency
From: Stelian Pop @ 2002-12-10 20:42 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Kernel Mailing List
In-Reply-To: <1039554124.22116.1.camel@rth.ninka.net>
On Tue, Dec 10, 2002 at 01:02:04PM -0800, David S. Miller wrote:
> > [
> > I posted this on lkml two weeks ago, and got no responses.
> > Am I asking something too trivial or nobody knows the answers ? :-)
> >
> > Thanks.
> > ]
>
> Most of us have forgotten even how the 2.2.x networking works
> it's been so long since we even glanced at the code.
Well, that's an easy excuse, especially coming from you :-)
Stelian.
--
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com
^ permalink raw reply
* Re: [LARTC] how to get the latency down on maxed out classes? + extra question
From: sufcrusher @ 2002-12-10 20:32 UTC (permalink / raw)
To: lartc
I've been using HTB for a while now and been tweaking and experimenting with
it a lot. I haven't got it perfect yet, but it's a lot better than nothing
(both terms of bandwidth efficiency and latency under load).
Basically what I do is create a few classes with different priorities: 0, 1,
2 and 3 (lower value, higher priority). Then I add a filter rule to each
class that sends all packets with a specific iptables MARK to that class.
Then I create some iptables rules that put the traffic in the correct class,
which means that all game traffic (and for testing all ICMP packets) go into
priority 0. Ssh, telnet, ACK packets, etc. go into 1. Http, ftp go into 2
and all other packets (kazaa/direct connect and other unknown stuff) is left
with priority 3. I limit the total upstream traffic to 100kbit (of the
128kbit my ISP provides me). I'm pretty sure I could go up a little higher
when I get the details tweaked right. I set rates and ceilings for each
class, although (in theory) the priorities should take care of it and it
should be possible to have each class use what they want.
My question here is: why does HTB not permit me to use more than 4
priorities? Some documentation I've seen says I should be able to go as high
as priority 7. Maybe my HTB version is too old? Anyway, my linux box is a
mess, I'll re-install it sometime soon and start using 2.4.20.
I use iptables rules like these for the marking:
iptables -I PREROUTING -t mangle -i eth2 --jump MARK --set-mark 1 -p ICMP
iptables -I PREROUTING -t mangle -i eth0 --jump MARK --set-mark 1 -p ICMP
Another trick I use is reducing the maximum (tcp) packet size, using (which
is good for the latency). I've seen other scripts that do the same using
different MTU settings and even custom routing tables with maximum MTU size.
I haven't really thought about the differences much, but this trick
effectively gives the same results:
iptables -I PREROUTING -t mangle -i eth2 --jump TCPMSS --set-mss 700 -p
TCP --tcp-flags SYN,RST SYN
iptables -I PREROUTING -t mangle -i eth0 --jump TCPMSS --set-mss 700 -p
TCP --tcp-flags SYN,RST SYN
And another important thing to do is change a simple kernel setting, which
improves HTB accuracy enormously, which is nice when you're tweaking the
settings: in /usr/src/linux/include/net/pkt_sched.h change
PSCHED_CLOCK_SOURCE to PSCHED_CPU if you have a cpu with timestamp counter
(TSC) that will give you Mhz timer granularity.
Don't forget to change the interfacenames in the above lines (and the script
below).
After having used a pretty complicated script, I recently started rewriting
it, so far I made this (no sfq or other stuff, just bare classes).
#!/bin/sh
INET_INTERFACE="eth0"
PRIOS='0 1 2 3'
TC_UPLINK_RATE="100"
TC_RATE[0]P
TC_CEIL[0]\x110
TC_RATE[1]\x15
TC_CEIL[1]`
TC_RATE[2]\x10
TC_CEIL[2]`
TC_RATE[3]=5
TC_CEIL[3]0
# Packet marks (which prioritiy is linked to which MARK value)
MARK[0]="1"
MARK[1]="2"
MARK[2]="3"
MARK[3]="4"
# Executables and stuff
IPTABLES="iptables"
TC="tc"
IP="ip"
LOG="/dev/null"
# Comment the next two lines to really run the tc commands.
TC="echo tc"
LOG="/dev/stdout"
# Find last prio, which will be the default
for PRIO in $PRIOS
do
LAST_PRIO=$PRIO
done
# The TC part
$TC qdisc del dev $INET_INTERFACE root
$TC qdisc add dev $INET_INTERFACE root handle 1:0 htb default
$[$LAST_PRIO+10]
$TC class add dev $INET_INTERFACE parent 1:0 classid 1:1 htb rate
${TC_UPLINK_RATE}kbit
for PRIO in $PRIOS
do
echo -e "\n***** Prio $PRIO *****" > $LOG
# Add leaf classes for PRIO traffic
$TC class add dev $INET_INTERFACE parent 1:1 \
classid 1:$[$PRIO+10] htb \
rate ${TC_RATE[$PRIO]}"kbit" \
ceil ${TC_CEIL[$PRIO]}"kbit" \
prio $PRIO
# Now filter PRIO traffic to this leaf
$TC filter add dev $INET_INTERFACE parent 1:0 \
protocol ip prio $PRIO handle ${MARK[$PRIO]} \
fw flowid 1:$[$PRIO+10]
done
Anyway, hope it helps someone.
Jannes Faber
----- Original Message -----
From: "Don Cohen" <don-lartc@isis.cs3-inc.com>
To: <lartc@mailman.ds9a.nl>; <abz@frogfoot.net>
Sent: Sunday, December 08, 2002 6:30 PM
Subject: [LARTC] how to get the latency down on maxed out classes?
> > lets say I want to limit traffic to/from client to 64kbit. now, client
opens
> > a tcp connection blasting away at full speed.
> >
> > If client now pings isp, it gets on average around 7 seconds latency. I
> > tried to improve this by using SFQ on the leaf nodes of my HTB
hierarchy,
> > but that does not really improve the situation, only makes it much
worse.
> > with SFQ I get anything between 250ms and 13 seconds latency.
>
> You understand what's going on here?
> As I recall, both pfifo and sfq default to queues of length 128
> packets. If you fill that with 1500 byte packets you have ~200Kbytes
> which is about 1.6Mbits. At 64Kbit/sec that would take ~30 sec to
> send so your latency could be as high as 30 sec.
> You can limit this latency by reducing the queue size.
>
> On the other hand, the application that fills the queue evidently
> doesn't mind large latency. Otherwise it wouldn't fill the queue.
>
> I think I posted to this list once a description (maybe even the
> code?) of another way to limit latency - drop packets that have been
> in the queue for more than a timeout period (I tend to use 3 sec).
>
> SFQ should have the desirable result that one tcp connection won't
> slow down another one or a ping.
>
> > I then tried fifos. With small packet fifos the packet loss is just
> > to great to be of any use and even then the latency is quite high
(~200ms).
> You consider 200ms high? One max size packet = 1500 bytes = 12Kbit
> which is about 200ms on a 64Kbit link. You can't expect to do better.
>
> > I'm thinking of using RED, but the number of parameters is daunting and
I
> > have no idea how the HTB rate correlates to packet size and burst rates
for
> > red.
> RED should be independent of HTB.
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Pavel Machek @ 2002-12-10 20:40 UTC (permalink / raw)
To: Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Pavel Machek,
Ducrot Bruno, Patrick Mochel, Linux Kernel Mailing List,
ACPI mailing list
In-Reply-To: <1039481341.12046.21.camel@irongate.swansea.linux.org.uk>
Hi!
> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.
And S4BIOS will never get added to 2.4 since it needs driver model
:-(.
> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)
We have full control over S4 (== swsusp), so we can fix that in most
cases.
S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ 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.