* Athlon PSE/AGP Bug
From: Ben Carrell @ 2002-01-22 17:59 UTC (permalink / raw)
To: linux-kernel
Just curious if using 4k page tables versus 4mb has an effect on
performance?
-Ben Carrell
ben@xmission.com
^ permalink raw reply
* Re: TUX support?
From: J Sloan @ 2002-01-22 17:59 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Arjan van de Ven, linux-kernel, Tux mailing list
In-Reply-To: <Pine.LNX.4.30.0201221110030.5699-100000@mustard.heime.net>
My guess is Ingo is having lots of fun with
the O(1) scheduler and other kernel stuff
right now - I'd like to see a 2.5 branch of
tux myself, but things are probably moving
a bit quickly for that right now....
I'm sure tux is not going away, it was just
yesterday that Alex Kramarov submitted
a patch to provide expires support.
TuX is too good to go away!
jjs
Roy Sigurd Karlsbakk wrote:
>>>Does anyone know who's in charge of the Tux server now? I got excellent,
>>>responsive support and answers from Ingo in December, but now the mailing
>>>list and Ingo's updates seem to have died out...
>>>
>>If you demand answers you can always buy a support contract.... Red Hat
>>sells those for TUX you know...
>>
>
>I apologize...
>I don't demand answers. I just wondered if the mailing list and so is
>still online. I've submitted a couple of bug reports, and nothing's
>happened, so I wondered if Tux is being discontinued. In that case, I need
>to find something else ...
>
>--
>Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
>
>Computers are like air conditioners.
>They stop working when you open Windows.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: pte-highmem-5
From: Hugh Dickins @ 2002-01-22 18:01 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel, Linus Torvalds
In-Reply-To: <20020121191539.K8292@athlon.random>
On Mon, 21 Jan 2002, Andrea Arcangeli wrote:
> On Sat, Jan 19, 2002 at 08:56:53PM +0000, Hugh Dickins wrote:
> > ....
> > that puts a limit NR_CPUS+1 on the kmaps needed here, so just add
> > NR_CPUS+1 for safety to the poolsize already thought necessary (??),
>
> the number of cpus have nothing to do with this, the issue is only the
> number of tasks, the problem is the same in a UP or in a 1024way
> machine.
If copy_page_range were some low-level function called from all over
the place, or if it blocked after its second kmap, I'd agree with you.
But I'm afraid your PAGETABLE2 justifications have only made me firmer
in the opinion that it's unnecessary. Never mind, that disagreement
is irrelevant because...
> > instead of holding a separate pool. But the stronger reason is that
> > pte_offset2 is being called with dst->page_table_lock held, yet it
>
> pte_offset2 is called without the pagetable lock held, otherwise it had
> to be a pte_offset_atomic, we cannot recall pte_offset with a spinlock
> held because pte_offset can schedule.
>
> > may have to block while all its kmaps are in use: elsewhere you have
> > consistently used pte_offset_atomic when spinlock held, why not here?
>
> because the spinlock isn't held there :)
Please look again. src->page_table_lock is not held across pte_offset2,
but dst->page_table_lock _is_ being held across pte_offset2. See comment
just above copy_page_range. See how the immediately preceding pte_alloc
expects dst->page_table_lock to be held. So, pte_offset_atomic is
appropriate there, and pte_offset2 etc can go.
Actually, I'm coming to think that most of the pte_offset_atomic
calls should be replaced by a pte_offset_nowait: which gives the usual
pte_offset kmap if it can without blocking, or an atomic if not - your
pte_kunmap seems nicely designed for that very possibility. Whether
pte_offset_nowait should ever flush_all_zero_pkmaps, or just return
an atomic in the end-of-pkmap case, I'm not sure.
> the mixture between PAGETABLE2 and PAGETABLE series due the
> reentrance of kmap is more difficult to proof as correct. The reason it
> cannot deadlock is that the previous pte_alloc (from the PAGETABLE
> serie) is on a certainly newly created kmap, so it cannot be the one
> that keeps a PAGETABLE2 slot pinned. As far as you do pte_offset2 while
> you are sure you're not keeping pinned a PAGETABLE2 slot in the same
> path (possibly with a pte_offset/pte_alloc) you're safe. The case of the
> fork() path is obviously correct because the pte_alloc will map
> something new.
No, the phrase "newly created kmap" is misleading. It is a new use
for a kmap, but the mapping being used may simply be that left over
from the previous use of that page. To get the SERIEs working as you
intend, you need to re-kmap whenever serie wanted differs from serie
already assigned (but PAGETABLE/PAGETABLE2 distinction a nuisance,
PAGETABLE2 when it's forking parent, PAGETABLE at other times).
And what happens when a page is wanted for two purposes at once? I'm
thinking there of mapping /dev/mem, kmapping as DEFAULT while it's in
use as PAGETABLE. At present /dev/mem does not supply highmem, but if
page tables are in highmem, I believe we shall need to give something
like LKCD's lcrash access to it.
> Same is true between KM_SERIE_PAGETABLE and KM_SERIE_DEFAULT, the reason
> it is obviously correct here is because the mixture cannot happen since
> the first place, because pages will pass through the freelist before the
> two can be mixed, and so they will be kunmapped first.
I think you're mistaken there: passing through the
freelist doesn't affect a page's kmapping at all, does it?
We could make changes to do so, but that wouldn't be enough.
> > ....
> > And doesn't that argument assume an ordering, a rule that a task
> > would necessarily allocate DEFAULT before PAGETABLE (or vice versa)?
>
> The ordering doesn't matter. You just don't need to keep pinned a
> DEFAULT while mapping a default, and the other way around for pagetable.
>
> > But I think in some contexts it's one way round (DEFAULT before
> > PAGETABLE when read's file_read_actor's __copy_to_user faults),
> > and in other contexts the other way round (PAGETABLE before DEFAULT
> > when do_no_page's block_read_full_page clears hole, or nfs readpage,
> > or ramfs readpage, or shmem_nopage's clear_highpage). I'm willing
> > to believe that the DEFAULT,PAGETABLE distinction reduces the chance
> > of kmap exhaustion deadlock, but it looks difficult to carry through.
>
> I don't think there's any possible conflict between DEFAULT and
> PAGETABLE.
But I'm suggesting that in some cases a DEFAULT kmap is pinned while
a PAGETABLE kmap is being acquired, and in other cases a PAGETABLE
kmap is pinned while a DEFAULT kmap is being acquired; which might
be happening concurrently in an unlimited (well, <32768) number of
tasks. Is that not so? And couldn't that deadlock, even if the
DEFAULT/PAGETABLE distinction were strictly maintained? Of course,
the all-one-pool case can deadlock there too: perhaps more easily
(though it would be sensible to give that one pool as many entries
as all your pools combined).
Well, I've had my say: I believe the SERIEs, as currently implemented,
give _an illusion of_ security from kmap deadlock. But it feels like
I'm failing to dislodge you from your belief in them, and they're
not actively harmful, so I'll shut up - until provoked!
> > A final point. I don't have a conclusive argument (beyond simplicity),
> > but I believe it will prove to be a mistake to give highmem pagetables
> > to the kernel's vmalloc area. I think you should define pte_alloc_k
> > for vmalloc, then you can avoid its pte_kunmaps, and remove traps.c
> > fault.c ioremap.c drm_scatter.h drm_vm.h from the patch (drm_proc.h
> > would have to stay; but personally, I'd just delete that #if 0 block
> > and be done with it - it's shown up too often in my pte greps!); and
> > save you from having to add all those video drivers using "rvmalloc"
> > into the patch, currently they're missing.
>
> That's an option, but it's so easy to update those few drivers that I'm
> not sure if it worth to ask yourself if the pte are been allocated by
> vmalloc, and also putting hacks into vmalloc.c doesn't look very nice,
> it is more effort than to update the drivers I believe.
Well, you've done that work now in pre4aa1, and you've fixed the only
actual problem I saw with it overnight, and was hoping to hit you with
today (the vmalloc fault in interrupt context). I still don't like it
(just now I was checking my pagetable_init patch, wanted to check the
the vmalloc pagetable, quite difficult), but never mind.
Hugh
^ permalink raw reply
* Re: [parisc-linux] vmlinux header for savecrash.
From: Bruno Vidal @ 2002-01-22 17:55 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux@lists.parisc-linux.org
In-Reply-To: <20020122174533.38418482A@dsl2.external.hp.com>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Hi
I don't know how to retrieve option pass to the kernel,
but give me some clue, and I'll add this information in
the dump header asap, because it is a really good idea :-)
Grant Grundler wrote:
>
> Randolph Chung and I were wondering if dump driver could save a
> parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
> I haven't checked if something like that already exists.
>
> grant
--
Vidal Bruno, (770-4271)
SSD-HA Team, HP-UX & LINUX Support
bruno_vidal@admin.france.hp.com
[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]
begin:vcard
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard
^ permalink raw reply
* Re: [parisc-linux] B2000
From: Grant Grundler @ 2002-01-22 17:55 UTC (permalink / raw)
To: Witvliet, Hans; +Cc: parisc-linux
In-Reply-To: <03273D4BC7F4D511AC440008C7E6F8815420CA@nlntmail2b.ats.nld.alcatel.nl>
"Witvliet, Hans" wrote:
> LS
> Even though under "tested hardware" it stated : B, C and J workstations
The kernel runs those boxes.
> I noticed that there were some difficulties with the B2000 in previous
> versions
> With the latest version (0.93) I still get after booting (from internal
> cdrom-drive):
Built-in IDE cd-rom drive on BCJ-[123567]XXX is not supported.
Off and on I've been hacking on suckyio IDE support but it's still
not working.
Install from either external SCSI CD-ROM or via network.
grant
^ permalink raw reply
* Re: [parisc-linux] vmlinux header for savecrash.
From: Randolph Chung @ 2002-01-22 17:53 UTC (permalink / raw)
To: Grant Grundler; +Cc: Bruno Vidal, parisc-linux@lists.parisc-linux.org
In-Reply-To: <20020122174533.38418482A@dsl2.external.hp.com>
> Randolph Chung and I were wondering if dump driver could save a
> parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
> I haven't checked if something like that already exists.
Is this really an arch-dependent problem? How do other architectures (I
think lkcd works on i386 and alpha?) do this?
randolph
--
@..@ http://www.TauSq.org/
(----)
( >__< )
^^ ~~ ^^
^ permalink raw reply
* Re: 2.4.17: Hang after IDE detection
From: Lionel Bouton @ 2002-01-22 17:50 UTC (permalink / raw)
To: Nils Rennebarth; +Cc: linux-kernel
In-Reply-To: <20020122173815.GH900@ipe.uni-stuttgart.de>
On Tue, Jan 22, 2002 at 06:38:15PM +0100, Nils Rennebarth wrote:
> On Tue, Jan 22, 2002 at 05:18:27PM +0200, Liakakis Kostas wrote:
> > I recently got an older k6-2/333 with a SiS chipset and tried to install
> > linux on it.
> >
> > Every recent distro I tryed with a 2.4.x kernel would hang after detecting
> > the SiS5513 controller.
>
> > SIS5513: chipset revision 208
> > SIS5513: not 100% native mode: will probe irqs later
> > SIS5597
> > ide0: BM-DMA at 0x4000-0x4007, BIOS settings hda:pio, hdb:pio
> > ide1: BM-DMA at 0x4008-0x400f, BIOS settings hdc:pio, hdb:pio
> for me the hang happens here. Other symptoms are about the same.
>
> > hda: ST34321A, ATA DISK drive
> > hdc: CD-540E, ATAPI CD/DVD-DROM drive
> > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > ide1 at 0x170-0x177,0x376 on ira 15
> > <hang>
> all recent (>=16) and a 2.4.6 pre7 kernel hang. 2.2.19 is no problem.
>
> Nils
Support for the 5597 coming in. Without net connection at home though.
May have to use floppy disks to bring code with me at work and then post.
Expect a post with an alpha version of ATA16/ATA33 chips support and
some ATA66 bugfixes before the week's end.
LB.
^ permalink raw reply
* Re: thread-ready ABIs
From: Kevin D. Kissell @ 2002-01-22 17:47 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Dominic Sweetman, Ralf Baechle, Ulrich Drepper, Mike Uhler,
MIPS/Linux List (SGI), H . J . Lu
In-Reply-To: <20020122123743.A17232@nevyn.them.org>
> > Anyway, do you see a hole or a serious performance
> > problem with my modified proposal (explicit mmap()
> > to create the necessary storage)?
>
> Same problem as with clone. I recommend the clone manpage; it says:
>
> CLONE_VM
> If CLONE_VM is set, the calling process and the child
processes run in the same
> memory space. In particular, memory writes performed by the
calling process or
> by the child process are also visible in the other process.
Moreover, any mem
> ory mapping or unmapping performed with mmap(2) or munmap(2)
by the child or
> calling process also affects the other process.
>
> If CLONE_VM is not set, the child process runs in a separate
copy of the memory
> space of the calling process at the time of clone. Memory
writes or file map
> pings/unmappings performed by one of the processes do not
affect the other, as
> with fork(2).
>
> That is, if any memory OR MAPPING is shared, they all are.
Daniel, you didn't read my message. The per-thread memory
would be allocated *after* the clone() in pthread_create().
More specifically, pthread_create() would set it up so that
the function passed to clone for invocation was in fact a
wrapper that sets up the memory and thread data before
invoking the application function passed to pthread_create().
Now, if the idea is that the clone() system call is supposed
to cause the thread to be born, like Athena, full-grown from
the head of Zeus, with the analog to the thread register
already set up when it leaves the kernel, then I would be inclined
to concede that we need to change the ABI, the kernel, and
compilers, and I would ask just what we get for our trouble.
But if we are permitted the pthreads abstraction, there's a
lot that can be done transparently.
Regards,
Kevin K.
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Peter Wächtler @ 2002-01-22 17:51 UTC (permalink / raw)
To: Mark Hahn; +Cc: lkml
In-Reply-To: <Pine.LNX.4.33.0201221206320.20907-100000@coffee.psychology.mcmaster.ca>
Mark Hahn schrieb:
>
> > So the time between the interrupt handler wanting to schedule a specific
> > task/thread and the next scheduling decision is crucial, right?
>
> sure, if there's some reason for user-space to run immediately
> after the irq. that's certainly not the case in general.
>
> remember, we're talking about what mainline Linux should do.
>
> > I have no hard numbers, but I can imagine that this can also lead to
> > better IO (in terms of latency AND IO throughput but with the cost of
> > cpu cycles [user space CPU throughput]).
>
> poorer throughput in general, since there's no chunking
> (write gathering, etc.) this is my complaint about the
> eager-preempt patches: that the *mandate* eager wakeup.
> the traditional kernel design *can* implement eager wakeup,
> but can also express chunking.
>
So can the interrupt handler code. The handler decides what to do,
depending on the status of the device. The higher level woken up task can
also do what it wants/ see fits in. The only difference is that higher level
gets notified a bit earlier - nothing more.
Does the current preempt patch unconditionally mandates preemption to occur?
This would be indeed a design flaw. The handler has to make the decision -
he knows it best.
> > I don't know the Linux kernel good enough right now, but if you shorten
> > the scheduling latency: that could be a win for faster IO. But there's always
> > a tradeoff: if you spent too much time in scheduling decisions/preparations
> > the overhead eats the lower latency (especially if your mutexes have to deal
> > with priority inversion, giving a lock holder at least the same priority as
> > the lock contender for the period it holds the lock).
>
> no, my criticism is strictly based on the fact that
> eager wakeup is often bad.
Ooh, that sounds different.
But where does a delayed wakeup makes sense in the _general_ case?
You wouldn't want slow interrupts. Kernel preemption allows you a quicker
notify of higher levels. It does not imply any policy on what to do
with this event.
Of course it's still bad to flood the system with interrupts.
The interrupt handler has to decide if he has to wakeup a higher
level thread, immediatly, on the next schedule or not (if he can
handle it on its own).
^ permalink raw reply
* Re: Autostart RAID 1+0 (root)
From: Jakob Østergaard @ 2002-01-22 17:46 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Alok K. Dhir, linux-kernel
In-Reply-To: <Pine.LNX.3.96.1020122120342.27404A-100000@gatekeeper.tmr.com>
On Tue, Jan 22, 2002 at 12:15:28PM -0500, Bill Davidsen wrote:
> On Fri, 18 Jan 2002, Alok K. Dhir wrote:
>
> > I want to test using a software RAID 1+0 partition as root: md0 and md1
> > set up as mirrors between two disks each, and md2 set up as a stripe
> > between md0 and md1. However, the RedHat 7.2 installer doesn't allow
> > creating nested RAID partitions.
>
> Here's my understanding. If you are using hardware RAID you can do
> anything your controller supports, and it looks like a single drive to the
> CPU. But if you are looking for reliable boot, you need to use /boot as a
> RAID-1 partition on the first two drives, and make that partition the
> active partition (that may not be needed with your BIOS).
I think he is referring to software RAID. And yes, it is indeed a problem
that the RedHat installer cannot create nested RAIDs (at least, I too was
unable to do that, so either it's impossible, or I'm equally blind).
> This is because if the first disk fails totally, the 2nd will be used to
> boot. You also should use an initrd image to be sure all you need to get
> up is on that small mirrored partition. After that your other partitions
> can be whatever pleases you.
Also, GRUB/LILO only support booting from RAID-1 (or no RAID).
...
> >
> > Does the kernel support autostarting nested RAID partitions?
> >
Yes it does. If you have persistent superblocks on all arrays, they
*should* autostart.
If you boot from the 4G disk, does the array start properly ? Does
it start properly even if you remove your /etc/raidtab ?
Please check that you have the correct RAID levels either compiled
into your kernel, or on an initrd.
> > Is doing software 1+0 a bad idea anyway due to performance issues?
>
> It should outperform most other RAID configs under heavy load, but in most
> cases RAID-5 is fine for system which don't need the absolute highest
> performance. Note that the extra writes are queued and there are no extra
> reads unless it is in recovery mode. RAID-1 can be faster, because there
> are two copies of the data, if one drive is busy the other can be used. I
> haven't checked to see that software RAID does that correctly and gets the
> benefit.
A performance improvement went into 2.4 at some stage - all newer 2.4 kernels
will schedule reads to the mirror which has it's head nearest to where the
read should occur. This works very well in my experience.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
^ permalink raw reply
* Re: 2.4.17:Increase number of anonymous filesystems beyond 256?
From: Pete Zaitcev @ 2002-01-22 17:45 UTC (permalink / raw)
To: Rainer Krienke; +Cc: Pete Zaitcev, linux-kernel, nfs
In-Reply-To: <200201221523.g0MFNst03011@bliss.uni-koblenz.de>
> From: Rainer Krienke <krienke@uni-koblenz.de>
> Date: Tue, 22 Jan 2002 16:23:54 +0100
> Thanks for the hint. I fixed pmap_create() according to your proposal and now
> nfsd works again.
Care to share the patch?
> Raising the count of elements of
> unnamed_dev_in_use in fs/super.c to eg 4096 resulted in the opportunity to
> mount as many NFS directories.
You did not send your patch (yet again), so there is no way
to tell precisely what you have accomplished. I suspect that it may
create pages with same device number that belong to different
mounts. I do not pretend to understand how VFS and page cache
use device numbers. If device numbers are used for any indexing,
pages may be mixed up with resulting data corruption.
I cannot say if this scenario is likely without looking
at the VFS code. Perhaps we ought to ask Stephen, Al, or Trond
about it.
> Why did you
> Pete base your patch on 4 new major device numbers whereas Andis patch did
> not need them?
He probably never tested his patch. I asked him and we'll know
soon if it was so.
-- Pete
^ permalink raw reply
* Re: [parisc-linux] vmlinux header for savecrash.
From: Grant Grundler @ 2002-01-22 17:45 UTC (permalink / raw)
To: Bruno Vidal; +Cc: parisc-linux@lists.parisc-linux.org
In-Reply-To: <3C4D2EFB.F82671C2@admin.france.hp.com>
Bruno Vidal wrote:
> Sorry, but on my system, fgrep gives nothing
> (and by using strings, I found nothing also).
grundler@gsyprf11:~$ uname -a
Linux gsyprf11.external.hp.com 2.4.17-pa11 #3 SMP Fri Jan 18 23:32:06 PST 2002 parisc64 unknown
grundler@gsyprf11:~$ strings /boot/vmlinux | fgrep 2.4.17
Linux version 2.4.17-pa11 (grundler@gsyprf10) (gcc version 3.0.3) #3 SMP Fri Jan 18 23:32:06 PST 2002
Linux 2.4.17-pa11
2.4.17-pa11
grundler@gsyprf11:~$
Perhaps a simple fgrep isn't sufficient for what you have.
You might need to pick out certain fields.
> And I
> can't use dmesg buffer, because by definition it is a buffer,
> so after running sometime, the palo boot strings is not
> in the buffer anymore.
right. They should be in the /var/log/messages if they are no longer
in the dmesg buffer.
> Some new ideas ?
Randolph Chung and I were wondering if dump driver could save a
parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
I haven't checked if something like that already exists.
grant
^ permalink raw reply
* Re: thread-ready ABIs
From: Ulrich Drepper @ 2002-01-22 17:41 UTC (permalink / raw)
To: Dominic Sweetman
Cc: Kevin D. Kissell, Ralf Baechle, Mike Uhler, linux-mips,
H . J . Lu
In-Reply-To: <15437.13028.496595.150427@gladsmuir.algor.co.uk>
Dominic Sweetman <dom@algor.co.uk> writes:
> Sometimes when you're busy it's understandable to respond with "RTFM".
> But to fail to provide a URL is not very respectful: other people
> reading this list are quite smart, they're just smart about different
> things from you.
A simple Google search would have turned up
http://developer.intel.com/design/itanium/downloads/24537003.pdf
as the first choice. Section 7.5.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
^ permalink raw reply
* Re: 2.4.17: Hang after IDE detection
From: Nils Rennebarth @ 2002-01-22 17:38 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.GSO.4.21.0201221547420.18952-100000@skiathos.physics.auth.gr>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Tue, Jan 22, 2002 at 05:18:27PM +0200, Liakakis Kostas wrote:
> I recently got an older k6-2/333 with a SiS chipset and tried to install
> linux on it.
>
> Every recent distro I tryed with a 2.4.x kernel would hang after detecting
> the SiS5513 controller.
> SIS5513: chipset revision 208
> SIS5513: not 100% native mode: will probe irqs later
> SIS5597
> ide0: BM-DMA at 0x4000-0x4007, BIOS settings hda:pio, hdb:pio
> ide1: BM-DMA at 0x4008-0x400f, BIOS settings hdc:pio, hdb:pio
for me the hang happens here. Other symptoms are about the same.
> hda: ST34321A, ATA DISK drive
> hdc: CD-540E, ATAPI CD/DVD-DROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on ira 15
> <hang>
all recent (>=16) and a 2.4.6 pre7 kernel hang. 2.2.19 is no problem.
Nils
--
______
(Muuuhh)
Global Village Sau ==> ^..^ |/¯¯¯¯¯
(Kann Fremdsprache) ==> (oo)
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: thread-ready ABIs
From: Kevin D. Kissell @ 2002-01-22 17:34 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Dominic Sweetman, Ralf Baechle, Ulrich Drepper, Mike Uhler,
MIPS/Linux List (SGI), H . J . Lu
In-Reply-To: <20020122121330.A16110@nevyn.them.org>
> > > Perhaps I'm mangling terminology. LinuxThreads is a one-to-one
mapping
> > > of kernel threads to user threads. All the kernel threads, and thus
> > > all the user threads, share the same memory region - including the
> > > stack region. Their stacks are differentiated solely by different
> > > values in the stack pointer register. Thus I don't think what you're
> > > suggesting is possible.
> >
> > I don't see how fork() semantics can be preserved unless
> > the stack regions are replicated (copy-on-write) on a fork().
> > Under ATT and BSD Unix (which is where I did most of
> > my kernel hacking in the old days) that was the *only*
> > way to get a new kernel thread, so it was "obvious"
> > that my proposed hack would work. Linux does have
> > the clone() function as well, and if LinuxThreads are
> > implemented in terms of clone(foo, stakptr, CLONE_VM, arg),
> > you are correct, the proposed scheme would not work
> > without modification.
>
> Which it is. Fork shares no memory regions;
Oh, come on. If it doesn't share text regions, it's completely
brain dead!
> vfork/clone share all memory regions. AFAIK there is no
> share-heap-but-not-stack option in Linux.
Yeah. Not that it matters, but I had misremebered there being
finer grained control than that on clone(). Probably confused
it with something that someone overlaid on Mach once upon a time...
Anyway, do you see a hole or a serious performance
problem with my modified proposal (explicit mmap()
to create the necessary storage)?
Regards,
Kevin K.
^ permalink raw reply
* Re: thread-ready ABIs
From: Daniel Jacobowitz @ 2002-01-22 16:34 UTC (permalink / raw)
To: Kevin D. Kissell
Cc: Dominic Sweetman, Ralf Baechle, Ulrich Drepper, Mike Uhler,
MIPS/Linux List (SGI), H . J . Lu
In-Reply-To: <007601c1a35e$b3e3f940$0deca8c0@Ulysses>
On Tue, Jan 22, 2002 at 05:05:45PM +0100, Kevin D. Kissell wrote:
> > In any case, that's not the real problem. Linux user threads do not
> > have true separate stacks. They share their _entire_ address space;
> > the stacks are all bounded (default is 2MB) and grouped together at the
> > top of the available memory region.
>
> Exactly. But if all we all we are worried about is thread
> specific data for user threads multiplexed on exactly
> one kernel thread, we could probably get by with a
> simple global variable for the thread pointer for the
> current user thread running in the process. It's the
> case of multiple user threads running within multiple
> *kernel* threads (e.g. created by fork()) that complicates
> things, and makes people want to use a register
> or other storage resource associated with exactly one
> kernel thread (and CPU). A permanently assigned
> register, as we have seen, creates various complications,
> so I'm looking for another kernel-thread-specific resource,
> of which I believe the stack region is the best candidate.
> Each process/task/program would have a single global
> variable, which points to a common address in the
> stack region of each kernel thread, which is used
> to store the address of the user-thread-specific
> data of the user thread executing on that kernel thread.
Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping
of kernel threads to user threads. All the kernel threads, and thus
all the user threads, share the same memory region - including the
stack region. Their stacks are differentiated solely by different
values in the stack pointer register. Thus I don't think what you're
suggesting is possible.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: Fwd: Re: 2.4.17:Increase number of anonymous filesystems beyond 256?
From: Pete Zaitcev @ 2002-01-22 17:32 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, zaitcev
In-Reply-To: <mailman.1011289920.22682.linux-kernel2news@redhat.com>
> From: Andi Kleen <ak@suse.de>
> Newsgroups: linux-kernel
> Date: 17 Jan 2002 18:49:53 +0100
> --- linux-work/net/sunrpc/xprt.c-o Mon Oct 8 21:36:07 2001
> +++ linux-work/net/sunrpc/xprt.c Thu Jan 17 18:44:05 2002
> @@ -1507,6 +1507,13 @@
>
> memset(&myaddr, 0, sizeof(myaddr));
> myaddr.sin_family = AF_INET;
> +#define SUNRPC_NONSECURE_PORT 1
> +#ifdef SUNRPC_NONSECURE_PORT
> + err = sock->ops->bind(sock, (struct sockaddr *) &myaddr,
> + sizeof(myaddr));
> + if (err < 0)
> + printk("RPC: cannot bind to a port\n");
> +#else
> port = 800;
> do {
> myaddr.sin_port = htons(port);
> @@ -1516,6 +1523,9 @@
>
> if (err < 0)
> printk("RPC: Can't bind to reserved port (%d).\n", -err);
> +
> +#endif
> +
>
> return err;
> }
Andi, the patch above begs two questions in my mind:
1. Why to bind to 0 (INADDR_ANY) explicitly? My patch does not bind
at all and expects connect() to bind automatically. It is how
userland works and it seems to work here as well.
2. What did you do to increase the number of unnamed devices?
You said the patch "should" work, did that mean you did not test it?
-- Pete
^ permalink raw reply
* Re: BSE MediaEngine - booting from flash problems
From: David Woodhouse @ 2002-01-22 17:34 UTC (permalink / raw)
To: Gad Hayisraeli; +Cc: Linux-mtd List
In-Reply-To: <176701c1a36a$be8df600$1900000a@v.vmanage.com>
gad@syete.co.il said:
> could you please add more details , and examples ? i never did this
> map before ...
drivers/mtd/maps/*.c
The Ocelot one, for example, probes and registers two ranges.
--
dwmw2
^ permalink raw reply
* Re: BSE MediaEngine - booting from flash problems
From: Gad Hayisraeli @ 2002-01-22 17:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linux-mtd List
In-Reply-To: <16324.1011718407@redhat.com>
could you please add more details , and examples ?
i never did this map before ...
Gad
----- Original Message -----
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Gad Hayisraeli" <gad@syete.co.il>
Cc: "Linux-mtd List" <linux-mtd@lists.infradead.org>
Sent: Tuesday, January 22, 2002 6:53 PM
Subject: Re: BSE MediaEngine - booting from flash problems
>
> gad@syete.co.il said:
> > i'm using mediaEngine with bank0 of 4 mb, and bank 1 of 16 mb flash.
> > kernel: 2.4.17-rmk2-bse patch to support mediaEngine. but when the
> > kernel boots(nfs boot), i see it recognizes only the first flash bank.
> > what shall i do in order to recognize also the second ? (i tried to
> > alter sa1100-flash.c partitions but no use.)
>
> You probably need to add another 'map' driver for the second bank, then
> probe and register the flash device(s) in that separately.
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [right one][patch] amd athlon cooling on kt266/266a chipset
From: Daniel Nofftz @ 2002-01-22 17:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1444 bytes --]
in the first mail, i forget to append the patch ... this one is the right
mail to look at ... (sorry)
hi there!
a few month ago someone has posted a patch for enabling the disconneect
on STPGND detect function in the kt133/kt133a chipset. for those who don't
know what this does: it sets a bit in a register of the northbridge of the
chipset to enable the power saving modes of the athlon/duron/athlon xp
prozessors.
i did not found any patch which enables this function on an kt266/kt266a
board. so i modified this patch (
http://groups.google.com/groups?q=via_disconnect&hl=en&selm=linux.kernel.20010903002855.A645%40gondor.com&rnum=1
)
to support the kt266 and kt266a chipset to.
now i am looking for people to test the patch and repord, whether it works
allright on other computers than my computer (i tested this patch on an
epox 8kha+ whith an xp1600+).
if you want to test this patch:
1. first apply the patch
2. enable generel-setup -> acpi , acpi-bus-maager , prozessor
in the kernel config
3. add to the "append" line in /etc/lilo.conf the "amd_disconnect=yes"
statemand (or after reboot enter at the kernel-boot-prompt
"amd_disconnect=yes")
4. build a knew kernel
5. report to me, whether you have problems ...
if the patch gets a good feedback, maybe it is something for the official
kernel tree ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de
[-- Attachment #2: Type: TEXT/PLAIN, Size: 3267 bytes --]
--- linux-2.4.17-orig/drivers/pci/quirks.c Sun Nov 11 19:09:33 2001
+++ linux/drivers/pci/quirks.c Tue Jan 22 16:50:05 2002
@@ -21,6 +21,23 @@
#undef DEBUG
+/* Power Saving for Athlon/Duron CPUs on Via Chipsets has to be enabled bye
+ * kernel-boot-option "amd_disconnect=yes" . This is cause it looks like
+ * there are some stability problems on some boards when this option is
+ * enabled.
+ */
+
+int enable_amd_disconnect;
+
+static int __init amd_disconnect_setup (char *str) {
+ if(!strncmp(str,"yes",3)) {
+ enable_amd_disconnect=1;
+ }
+ return 1;
+}
+
+__setup("amd_disconnect=", amd_disconnect_setup);
+
/* Deal with broken BIOS'es that neglect to enable passive release,
which can cause problems in combination with the 82441FX/PPro MTRRs */
static void __init quirk_passive_release(struct pci_dev *dev)
@@ -146,6 +163,47 @@
printk(KERN_INFO "Applying VIA southbridge workaround.\n");
}
+/* Power Saving for Athlon/Duron/AthonXP CPUs on Via Chipsets.
+ * Found in the net and modified for supporting KT266/KT266A chipsets
+ * by Daniel Nofftz <nofftz@castor.uni-trier.de>
+ * This Funktion must be enabled by kernel booting option "via_disconnect=yes"!
+ */
+
+static void __init quirk_amddisconnect(struct pci_dev *dev)
+{
+ u16 did;
+ u32 res32;
+
+ if(!enable_amd_disconnect) return;
+
+ pci_read_config_word(dev,PCI_DEVICE_ID,&did);
+
+
+ if(did==PCI_DEVICE_ID_VIA_8367_0)
+ {
+ pci_read_config_dword(dev,0x92&0xfc,&res32);
+ if ((res32&0x00800000)==0)
+ {
+ printk(KERN_INFO "Enabling disconnect in VIA northbridge: KT266/266A chipset found.\n");
+ res32|=0x00800000;
+ pci_write_config_dword(dev,0x92&0xfc,res32);
+ } else
+ printk(KERN_INFO "Disconnect already anabled in VIA northbridge.\n");
+
+ }
+ else if((did==PCI_DEVICE_ID_VIA_8363_0)||(did==PCI_DEVICE_ID_VIA_8371_0))
+ {
+ pci_read_config_dword(dev,0x52&0xfc,&res32);
+ if ((res32&0x00800000)==0)
+ {
+ printk(KERN_INFO "Enabling disconnect in VIA northbridge: KT133/KX133 chipset found\n");
+ res32|=0x00800000;
+ pci_write_config_dword(dev,0x52&0xfc,res32);
+ } else
+ printk(KERN_INFO "Disconnect already anabled in VIA northbridge.\n");
+
+ }
+}
/*
* VIA Apollo VP3 needs ETBF on BT848/878
*/
@@ -485,6 +543,9 @@
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, quirk_vialatency },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8371_1, quirk_vialatency },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, 0x3112 /* Not out yet ? */, quirk_vialatency },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0, quirk_amddisconnect },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, quirk_amddisconnect },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8371_0, quirk_amddisconnect },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576, quirk_vsfx },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C597_0, quirk_viaetbf },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C597_0, quirk_vt82c598_id },
^ permalink raw reply
* Re: preemption and pccard ?
From: Erik Gustavsson @ 2002-01-22 17:16 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020122041802.8E8208954D@cx518206-b.irvn1.occa.home.com>
I believe I also saw this when trying a preempt kernel somewhere in the
2.4.17pre series. Only one cardbus slot worked (I think it was the
bottom slot that didn't respond, but I could be mistaken). I was playing
around with various patches at the time, so I didn't pay much attention
to it. I can try to verify it if that would help. This was on a Dell
Latitude CPi D266XT.
/cyr
--
-----------------------------------------------------------------------
You really think you can buy me with promises of power and glory.
You really think... Okay, I'll do it. -- Rimmer
^ permalink raw reply
* Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs)
From: Kevin D. Kissell @ 2002-01-22 17:16 UTC (permalink / raw)
To: aj, hjl, ralf, Machida Hiroyuki; +Cc: linux-mips
In-Reply-To: <20020122232529V.machida@sm.sony.co.jp>
> Kevin, please let us know about "k1 semaphore" you said.
> I want to know we can merge those functions or not.
My proposal is for a very simple emulation of ll/sc for
CPUs that implement the MIPS II "branch likely" instructions
but which do not have a functioning LL/SC. That means
that it is *not* a solution for R3000 processor such as
those found in old DEC and SGI platforms. LL/SC is
also part of MIPS II, but several manufacturers seem
to have done MIPS II/III processors where LL/SC
is not fully functional. This hack could thus be workable
both for the TX59 family and the Vr4100 family.
The idea leverages off the fact that a branch likely
instruction performs a kind of conditional execution.
The instruction in the delay slot is executed only if
the branch is taken. This can be used to synthesize
a conditional store. The user level code for a simple
atomic increment, for example, would look something
like this:
_atomic_inc_nollsc:
.set noreorder
li t0,MAGIC_COOKIE
Retry:
mov k1,t0
lw t1,0(a0)
addiu t1,t1,1
BEQL k1,t0,done
sw t1,0(a0)
b Retry
nop
done
jr ra
nop
If - and this is an important consideration - IF the value
of MAGIC_COOKIE can be determined such that
it can *never* be the residue value left in k1 by a
kernel exception handler, *no* kernel modifications
are required for this to work identically to LL/SC!
If, for example, k1 always ends up containing either
a Status, EPC, or EntryLo value after an ERET, something
like 0xffdadaff could be used as a MAGIC_COOKIE
value, as it is not a sane value for any of the above.
You will get some number of needless retries
in this scheme to the extent that there are TLB
misses on the load and on the instructions themselves
if the routine crosses a page boundary. You
would get those same retries using LL/SC.
You could eliminate those retries by preserving
the appropriate k-register in the TLB refill handler,
but I really doubt that it would be worthwhile.
If there is any doubt about the possibility of the
MAGIC_COOKIE value being left in k1 (or
k0, which could also be used as the "LL flop"
if its behavior is more easily constrained), an
explicit operation at the end of the fault handlers
could be used to clear the register. That would
still be far less complex and intrusive than the mods
that you suggest below.
I have not implemented this scheme under Linux,
but we have tried it with success under other OSes.
It should in principle be SMP safe.
> Technical discussions are welcome.
Well, there you have one!
Regards,
Kevin K.
^ permalink raw reply
* Re: Autostart RAID 1+0 (root)
From: Bill Davidsen @ 2002-01-22 17:15 UTC (permalink / raw)
To: Alok K. Dhir; +Cc: linux-kernel
In-Reply-To: <001201c1a03e$e654acd0$9865fea9@pcsn630778>
On Fri, 18 Jan 2002, Alok K. Dhir wrote:
> I want to test using a software RAID 1+0 partition as root: md0 and md1
> set up as mirrors between two disks each, and md2 set up as a stripe
> between md0 and md1. However, the RedHat 7.2 installer doesn't allow
> creating nested RAID partitions.
Here's my understanding. If you are using hardware RAID you can do
anything your controller supports, and it looks like a single drive to the
CPU. But if you are looking for reliable boot, you need to use /boot as a
RAID-1 partition on the first two drives, and make that partition the
active partition (that may not be needed with your BIOS).
This is because if the first disk fails totally, the 2nd will be used to
boot. You also should use an initrd image to be sure all you need to get
up is on that small mirrored partition. After that your other partitions
can be whatever pleases you.
> Being stubborn, I installed the OS onto a separate 4 gig disk, installed
> all the latest patches+fixes to the OS, including the RH2.4.9-13 kernel,
> then created md0, md1, and md2. I formatted md2 with reiserfs. No
> problem so far.
>
> Next, I copied the entire contents of the root partition onto md2,
> changed the relevant line of /boot/grub/grub.conf from:
>
> kernel /vmlinuz-2.4.9-13 ro root=/dev/sda2
>
> To:
>
> kernel /vmlinuz-2.4.9-13 ro root=/dev/md2
>
> Changed fstab so "/" points to /dev/md2 as well, crossed my fingers, and
> rebooted.
>
> No luck. I get a "cannot mount root" error.
>
> Attempting to speed read the boot messages before I get the panic, it
> appears that md0 and md1 are autostarted, but it doesn't look like md2
> is.
>
> Does the kernel support autostarting nested RAID partitions?
>
> Is doing software 1+0 a bad idea anyway due to performance issues?
It should outperform most other RAID configs under heavy load, but in most
cases RAID-5 is fine for system which don't need the absolute highest
performance. Note that the extra writes are queued and there are no extra
reads unless it is in recovery mode. RAID-1 can be faster, because there
are two copies of the data, if one drive is busy the other can be used. I
haven't checked to see that software RAID does that correctly and gets the
benefit.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* [patch] amd athlon cooling on kt266/266a chipset
From: Daniel Nofftz @ 2002-01-22 17:15 UTC (permalink / raw)
To: Linux Kernel Mailing List
hi there!
a few month ago someone has posted a patch for enabling the disconneect
on STPGND detect function in the kt133/kt133a chipset. for those who don't
know what this does: it sets a bit in a register of the northbridge of the
chipset to enable the power saving modes of the athlon/duron/athlon xp
prozessors.
i did not found any patch which enables this function on an kt266/kt266a
board. so i modified this patch (
http://groups.google.com/groups?q=via_disconnect&hl=en&selm=linux.kernel.20010903002855.A645%40gondor.com&rnum=1
)
to support the kt266 and kt266a chipset to.
now i am looking for people to test the patch and repord, whether it works
allright on other computers than my computer (i tested this patch on an
epox 8kha+ whith an xp1600+).
if you want to test this patch:
1. first apply the patch
2. enable generel-setup -> acpi , acpi-bus-maager , prozessor
in the kernel config
3. add to the "append" line in /etc/lilo.conf the "amd_disconnect=yes"
statemand (or after reboot enter at the kernel-boot-prompt
"amd_disconnect=yes")
4. build a knew kernel
5. report to me, whether you have problems ...
if the patch gets a good feedback, maybe it is something for the official
kernel tree ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de
^ permalink raw reply
* Re: thread-ready ABIs
From: Kevin D. Kissell @ 2002-01-22 17:08 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Dominic Sweetman, Ralf Baechle, Ulrich Drepper, Mike Uhler,
MIPS/Linux List (SGI), H . J . Lu
In-Reply-To: <20020122113420.A14284@nevyn.them.org>
> Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping
> of kernel threads to user threads. All the kernel threads, and thus
> all the user threads, share the same memory region - including the
> stack region. Their stacks are differentiated solely by different
> values in the stack pointer register. Thus I don't think what you're
> suggesting is possible.
I don't see how fork() semantics can be preserved unless
the stack regions are replicated (copy-on-write) on a fork().
Under ATT and BSD Unix (which is where I did most of
my kernel hacking in the old days) that was the *only*
way to get a new kernel thread, so it was "obvious"
that my proposed hack would work. Linux does have
the clone() function as well, and if LinuxThreads are
implemented in terms of clone(foo, stakptr, CLONE_VM, arg),
you are correct, the proposed scheme would not work
without modification.
One such modification would be to have each newly
cloned thread explicitly allocate and map a 1-page
VM region that is private to the kernel thread, and bound
to a known virtual address that is common to all threads
within the task. That known virtual address would take the
place of the below-the-stack storage location I described
earlier. The same algorithm would apply - one has a globally
known address that maps to different storage per-thread,
which can be used to store the address of the (globally visible)
per-thread information. The set-up is slightly more complicated
and heavyweight than the fork()-based model I suggested,
but one could in principle eliminate one level of indirection
at on the lookups at run-time.
Regards,
Kevin K.
^ 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.