* Re: shared pagetable benchmarking
From: William Lee Irwin III @ 2002-12-20 11:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: Dave McCracken, linux-mm
In-Reply-To: <3E02FACD.5B300794@digeo.com>
On Fri, Dec 20, 2002 at 03:11:09AM -0800, Andrew Morton wrote:
> Did a bit of timing and profiling. It's a uniprocessor
> kernel, 7G, PAE.
> The workload is application and removal of ~80 patches using
> my patch scripts. Tons and tons of forks from bash.
> 2.5 ends up being 13% slower than 2.4, after disabling highpte
> to make it fair. 3%-odd of this is HZ=1000. So say 10%.
> Pagetable sharing actually slowed this test down by several
> percent overall. Which is unfortunate, because the main
> thing which Linus likes about shared pagetables is that it
> "speeds up forks".
> Is there anything we can do to fix all of this up a bit?
For testing purposes, try removing the opportunistic mmap()-time
sharing.
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Nicolas Mailhot @ 2002-12-20 11:18 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]
|John Bradford wrote:
|
|> [snip]
|>
|>Interesting - so the first stage in reporting a bug would be to select
|>the latest 2.4 and 2.5 kernels that you've noticed it in, and get a
|>list of known bugs fixed in those versions. Also, if you'd selected
|>the maintainer, (from an automatically generated list from the
|>MAINTAINERS file), it could just search *their* changes in the changelog.
|>
|It's often difficult to pick a maintainer for a bug - it may not be the
|fault of a single subsystem. As an example, I recently had a problem
|getting USB and network to function (on kernels 2.5.5x). I noticed that
|toggling Local APIC would also toggle which of the two devices worked.
| Disabling ACPI allows both deviecs to function regardless of local APIC.
|
|So, where is the problem?
|1) Network driver? It doesn't work with ACPI and both Local APIC and
|IO-APIC.
|2) USB driver? It doesn't work with ACPI and no UP APIC.
|3) APIC? Causes weird problems with various drivers when ACPI is turned on.
|4) ACPI? Causes weird problems with various drivers when APIC is toggled.
|
|(this exact bug was in Bugzilla, though I hadn't checked there before
|mailing lkml ;)
I assume you're talking about :
http://bugzilla.kernel.org/show_bug.cgi?id=10
As the reporter, I'll tell you plainly bugzilla rocks for this.
This bug was first reported in linux-kernel, then was picked in the 2.5 problem
reports, then (when bugzilla.kernel.org) was announced reported again in
bugzilla.
Bugzilla enabled the report to be ping-ponged among maintainers until someone
accepted it. And it can be found by other people now (note you missed the linux
kernel report when you posted this). No one was interested before the bugzilla
report.
Bugzilla can be a pain sometimes, it's not intuitive, it's suffering yet from its
hackish bastard origin, but it works, lots of projects are using it (both because
its so easy to deploy and people are familiar with it - try rt
I-need-30+-perl-packages-to-work-only-I-use hell for example) and it's improving.
2.17.1 (seen both at http://bugzilla.mozilla.org/ and http://bugzilla.redhat.com/)
is a *huge* improvement, I can't wait for it to be released for everyone (right now
the bugzilla team has a hard time integrating all the features everyone and his dog
have been contributing back to the project lately).
All bugzilla's I've seen so far would benefit from better version tracking.
All bugzilla's I've seen so far would benefit from better UI.
The problems raised in this thread are pretty generic. They should be tackled a generic
way in the original project.
However I wouldn't even touch any other bug reporting system. Others (like rt) boast a
better original design ; the truth is they have their own warts but not a community
the size of bugzilla to find/fix them (and I'm not even talking about security audits).
Once you've grokked bugzilla (which I freely admit is long and painful) you'll find it's
actually rather powerful and you'll be trained to interact with :
- mozilla bugzilla
- kernel bugzilla
- apache bugzilla
- gnome bugzilla
- kde bugzilla
- abiword bugzilla
- red hat bugzilla
and so on (and all of these deployments have useful tweaks that trickle back in the
original bugzilla)
Not having to learn a new UI to report a bug in another project is quite nice. I know I'd
have thought twice about the feedback I've given to various organizations otherwise.
Regards,
--
Nicolas Mailhot
Not linux-kernel subscribed, sometimes reading the archives, sometimes not
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* shared pagetable benchmarking
From: Andrew Morton @ 2002-12-20 11:11 UTC (permalink / raw)
To: Dave McCracken, linux-mm
Did a bit of timing and profiling. It's a uniprocessor
kernel, 7G, PAE.
The workload is application and removal of ~80 patches using
my patch scripts. Tons and tons of forks from bash.
2.5 ends up being 13% slower than 2.4, after disabling highpte
to make it fair. 3%-odd of this is HZ=1000. So say 10%.
Pagetable sharing actually slowed this test down by several
percent overall. Which is unfortunate, because the main
thing which Linus likes about shared pagetables is that it
"speeds up forks".
Is there anything we can do to fix all of this up a bit?
2.4.21-pre2:
c0106d60 system_call 10 0.1786
c012ca00 __free_pages_ok 10 0.0124
c0114c38 mm_init 13 0.0396
c0124a84 find_vma 13 0.1548
c01283ac generic_file_write 13 0.0073
c012cd24 rmqueue 14 0.0201
c0122570 __free_pte 16 0.1667
c0123df0 handle_mm_fault 16 0.0625
c0123aac do_anonymous_page 25 0.0801
c0126c3c file_read_actor 33 0.1684
c0123be4 do_no_page 37 0.0706
c01226d0 copy_page_range 47 0.0810
c0112878 do_page_fault 49 0.0352
c01225e8 clear_page_tables 70 0.3017
c0122914 zap_page_range 72 0.1118
c01234b0 do_wp_page 275 0.3736
00000000 total 1062 0.0008
created /tmp/prof.time
akpm-prof pushpatch 99 11.83s user 10.56s system 99% cpu 22.439 total
c01283ac generic_file_write 9 0.0050
c012d8b4 free_page_and_swap_cache 9 0.1500
c012625c __find_get_page 10 0.2083
c0118cdc exit_notify 11 0.0174
c012ca00 __free_pages_ok 11 0.0137
c013c030 link_path_walk 16 0.0077
c012cd24 rmqueue 18 0.0259
c0123aac do_anonymous_page 20 0.0641
c0126c3c file_read_actor 25 0.1276
c01226d0 copy_page_range 27 0.0466
c0123be4 do_no_page 29 0.0553
c01225e8 clear_page_tables 32 0.1379
c01052b0 poll_idle 33 0.8250
c0122914 zap_page_range 42 0.0652
c0112878 do_page_fault 50 0.0359
c01234b0 do_wp_page 161 0.2188
00000000 total 791 0.0006
created /tmp/prof.time
akpm-prof poppatch 99 8.60s user 7.57s system 97% cpu 16.530 total
2.5.52-mm3:
c012b998 free_hot_cold_page 94 0.4896
c0117348 do_schedule 103 0.1717
c012ba7c buffered_rmqueue 110 0.5729
c01c1b4c strnlen_user 116 1.3810
c012e36c kmem_cache_alloc 120 1.8750
c0134454 find_vma 133 1.5114
c010a558 system_call 134 3.0455
c01504ac d_lookup 143 0.6164
c0148af4 link_path_walk 153 0.0915
c0116b88 kmap_atomic_to_page 175 1.9886
c0133060 handle_mm_fault 195 0.6414
c01c1d48 __copy_from_user 212 1.8929
c011598c pte_alloc_one 213 1.6641
c0132c74 do_anonymous_page 260 0.6311
c011cab0 do_softirq 300 1.7045
c01c1ce0 __copy_to_user 369 3.5481
c0132e10 do_no_page 529 0.8936
c013c9e4 pte_unshare 572 0.5789
c0116b04 kmap_atomic 585 5.2232
c0131b44 zap_pte_range 585 1.4199
c0115bc0 do_page_fault 600 0.4808
c0136428 page_add_rmap 766 2.1517
c0131890 clear_page_tables 860 2.6220
c013658c page_remove_rmap 928 1.9333
c013250c do_wp_page 2594 3.3601
00000000 total 15261 0.0097
created /tmp/prof.time
akpm-prof pushpatch 99 12.36s user 14.61s system 97% cpu 27.768 total
c0117348 do_schedule 77 0.1283
c010a558 system_call 85 1.9318
c0134454 find_vma 90 1.0227
c01504ac d_lookup 106 0.4569
c0116b88 kmap_atomic_to_page 107 1.2159
c0133060 handle_mm_fault 113 0.3717
c011598c pte_alloc_one 135 1.0547
c0148af4 link_path_walk 135 0.0807
c01c1d48 __copy_from_user 162 1.4464
c0132c74 do_anonymous_page 218 0.5291
c01c1ce0 __copy_to_user 297 2.8558
c011cab0 do_softirq 319 1.8125
c0132e10 do_no_page 325 0.5490
c0131b44 zap_pte_range 362 0.8786
c013c9e4 pte_unshare 375 0.3796
c0116b04 kmap_atomic 384 3.4286
c0115bc0 do_page_fault 447 0.3582
c0136428 page_add_rmap 505 1.4185
c0131890 clear_page_tables 563 1.7165
c013658c page_remove_rmap 585 1.2188
c013250c do_wp_page 1559 2.0194
00000000 total 10586 0.0067
created /tmp/prof.time
akpm-prof poppatch 99 9.00s user 10.31s system 96% cpu 19.926 total
OK, remove shpte:
=================
c0134344 find_vma 110 1.2500
c01c07fc strnlen_user 112 1.3333
c0118c94 copy_process 113 0.0456
c012b77c buffered_rmqueue 120 0.6250
c014f0a0 __d_lookup 133 0.6520
c010a558 system_call 145 3.2955
c01474e0 link_path_walk 162 0.0769
c0116b28 kmap_atomic_to_page 165 1.8750
c0132f00 handle_mm_fault 166 0.5461
c012e02c kmem_cache_alloc 185 2.8906
c012e0d8 kmem_cache_free 188 2.9375
c0115a0c pgd_alloc 193 0.9650
c01c09f8 __copy_from_user 196 1.7500
c011598c pte_alloc_one 216 1.6875
c0132b24 do_anonymous_page 249 0.6163
c011c880 do_softirq 293 1.6648
c01c0990 __copy_to_user 418 4.0192
c0132cb8 do_no_page 446 0.7637
c01317b4 copy_page_range 496 0.7425
c0116aa4 kmap_atomic 591 5.2768
c0115b60 do_page_fault 594 0.4760
c0131a50 zap_pte_range 609 1.2378
c0136314 page_add_rmap 632 1.7556
c01314f0 clear_page_tables 688 2.2051
c013647c page_remove_rmap 817 1.7021
c01323d4 do_wp_page 2600 3.4759
00000000 total 14713 0.0094
created /tmp/prof.time
akpm-prof pushpatch 99 12.29s user 14.40s system 99% cpu 26.913 total
c014f0a0 __d_lookup 91 0.4461
c010a558 system_call 93 2.1136
c0132f00 handle_mm_fault 111 0.3651
c012e02c kmem_cache_alloc 113 1.7656
c01474e0 link_path_walk 118 0.0560
c011598c pte_alloc_one 129 1.0078
c0116b28 kmap_atomic_to_page 129 1.4659
c012e0d8 kmem_cache_free 140 2.1875
c01c09f8 __copy_from_user 160 1.4286
c0115a0c pgd_alloc 170 0.8500
c0132b24 do_anonymous_page 184 0.4554
c011c880 do_softirq 297 1.6875
c01317b4 copy_page_range 309 0.4626
c01c0990 __copy_to_user 318 3.0577
c0132cb8 do_no_page 335 0.5736
c0131a50 zap_pte_range 364 0.7398
c01314f0 clear_page_tables 393 1.2596
c0115b60 do_page_fault 441 0.3534
c0136314 page_add_rmap 441 1.2250
c0116aa4 kmap_atomic 448 4.0000
c013647c page_remove_rmap 550 1.1458
c01323d4 do_wp_page 1593 2.1297
00000000 total 10335 0.0066
created /tmp/prof.time
akpm-prof poppatch 99 9.07s user 10.03s system 99% cpu 19.290 total
Also remove highpte
===================
c01c037c strnlen_user 108 1.2857
c010a558 system_call 111 2.5227
c012b79c buffered_rmqueue 113 0.5885
c0134144 find_vma 117 1.3295
c01171e4 do_schedule 118 0.1954
c0132d20 handle_mm_fault 132 0.4583
c014ebf0 __d_lookup 142 0.6961
c0131010 page_address 147 1.0500
c0116ae4 kmap_atomic 163 1.4554
c0147030 link_path_walk 186 0.0882
c01c0578 __copy_from_user 203 1.8125
c011597c pte_alloc_one 224 1.5556
c0115a0c pgd_alloc 231 1.1550
c0132990 do_anonymous_page 260 0.7065
c011c8d0 do_softirq 283 1.6080
c01c0510 __copy_to_user 380 3.6538
c0132b00 do_no_page 401 0.7371
c01316fc copy_page_range 451 0.7723
c0131944 zap_pte_range 588 1.1575
c013602c page_add_rmap 601 2.5042
c0115b60 do_page_fault 607 0.4716
c0131440 clear_page_tables 637 2.1233
c013611c page_remove_rmap 657 2.0030
c01322b4 do_wp_page 2530 3.6988
00000000 total 13554 0.0087
created /tmp/prof.time
akpm-prof pushpatch 99 11.97s user 13.36s system 99% cpu 25.541 total
c0132d20 handle_mm_fault 100 0.3472
c0147030 link_path_walk 106 0.0503
c0116ae4 kmap_atomic 109 0.9732
c0115a0c pgd_alloc 140 0.7000
c011597c pte_alloc_one 151 1.0486
c01c0578 __copy_from_user 162 1.4464
c0132990 do_anonymous_page 204 0.5543
c011c8d0 do_softirq 305 1.7330
c01c0510 __copy_to_user 308 2.9615
c0132b00 do_no_page 310 0.5699
c01316fc copy_page_range 314 0.5377
c013602c page_add_rmap 361 1.5042
c0131944 zap_pte_range 379 0.7461
c0115b60 do_page_fault 409 0.3178
c013611c page_remove_rmap 430 1.3110
c0131440 clear_page_tables 443 1.4767
c01322b4 do_wp_page 1662 2.4298
00000000 total 9706 0.0062
created /tmp/prof.time
akpm-prof poppatch 99 8.86s user 9.33s system 98% cpu 18.433 total
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* [PATCH]: trivial sys_mincore cleanup
From: Gianni Tedesco @ 2002-12-20 11:17 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
Patch makes 2 simple cleanups:
- Checks the syscall parameters before grabbing mmap semaphore.
- Tidy up a comment.
BTW. How comes mincore() doesn't return a bit vector? :P
diff -urN linux-2.4.19.orig/mm/filemap.c linux-2.4.19/mm/filemap.c
--- linux-2.4.19.orig/mm/filemap.c Sat Aug 3 00:39:46 2002
+++ linux-2.4.19/mm/filemap.c Fri Dec 20 11:11:56 2002
@@ -2736,21 +2736,21 @@
int unmapped_error = 0;
long error = -EINVAL;
- down_read(¤t->mm->mmap_sem);
-
if (start & ~PAGE_CACHE_MASK)
- goto out;
+ return error;
len = (len + ~PAGE_CACHE_MASK) & PAGE_CACHE_MASK;
end = start + len;
if (end < start)
- goto out;
+ return error;
error = 0;
if (end == start)
- goto out;
+ return error;
+
+ down_read(¤t->mm->mmap_sem);
/*
- * If the interval [start,end) covers some unmapped address
+ * If the interval [start,end] covers some unmapped address
* ranges, just ignore them, but return -ENOMEM at the end.
*/
vma = find_vma(current->mm, start);
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Marc-Christian Petersen @ 2002-12-20 11:17 UTC (permalink / raw)
To: Robert Love, Con Kolivas; +Cc: Andrew Morton, linux kernel mailing list
In-Reply-To: <1040341995.2521.81.camel@phantasy>
On Friday 20 December 2002 00:53, Robert Love wrote:
Hi Robert,
> You would probably get the same effect or better by setting
> prio_bonus_ratio lower (or off).
> Setting it lower will also give less priority bonus/penalty and not
> reinsert the tasks so readily into the active array.
> Something like the attached patch may help...
> --- linux-2.5.52/kernel/sched.c 2002-12-19 18:47:53.000000000 -0500
> +++ linux/kernel/sched.c 2002-12-19 18:48:05.000000000 -0500
> @@ -66,8 +66,8 @@
> int child_penalty = 95;
> int parent_penalty = 100;
> int exit_weight = 3;
> -int prio_bonus_ratio = 25;
> -int interactive_delta = 2;
> +int prio_bonus_ratio = 5;
> +int interactive_delta = 1;
> int max_sleep_avg = 2 * HZ;
> int starvation_limit = 2 * HZ;
FYI: These changes are a horrible slowdown of all apps while kernel
compilation.
ciao, Marc
^ permalink raw reply
* Re: [PATCH] Fix CPU bitmask truncation
From: William Lee Irwin III @ 2002-12-20 11:15 UTC (permalink / raw)
To: torvalds, linux-kernel, bjorn_helgaas
In-Reply-To: <20021220103028.GB9704@holomorphy.com>
On Mon, Dec 16, 2002 at 12:13:29PM -0700, Bjorn Helgaas wrote:
>> This patch fixes some obviously incorrect bitmask truncations in 2.4.20.
On Fri, Dec 20, 2002 at 02:30:28AM -0800, William Lee Irwin III wrote:
> Linus, this is the 2.5.x version of the same patch originally by Bjorn
> for 2.4.x. This fixes an entire class of critical 64-bit bugs.
> Against 2.5.52-bk as of 2:25AM 20 Dec 2002. Please apply.
Actually, this looks like a non-issue from userspace on the IA64 boxen
I can get to. akpm pointed out that this seemed to pass his testing,
and on deeper inspection, IA64 userspace did not find this to be an issue.
Bjorn, could you explain on what toolchains and/or architectures you had
this issue? It sounds serious and/or real enough yet I can't actually
make this happen myself.
Thanks,
Bill
^ permalink raw reply
* Re: [PATCH] IRQ distribution in the 2.5.52 kernel
From: William Lee Irwin III @ 2002-12-20 11:15 UTC (permalink / raw)
To: Kamble, Nitin A; +Cc: linux-kernel
In-Reply-To: <E88224AA79D2744187E7854CA8D9131DA5CE2F@fmsmsx407.fm.intel.com>
On Fri, Dec 20, 2002 at 01:08:18AM -0800, Kamble, Nitin A wrote:
> -static inline void balance_irq(int irq)
> +static inline void balance_irq (int cpu, int irq)
> {
> - irq_balance_t *entry = irq_balance + irq;
> unsigned long now = jiffies;
> -
> + unsigned long allowed_mask;
> + unsigned int new_cpu;
> +
> if (clustered_apic_mode)
> return;
This can actually be done for clustered_apic_mode, just not as the
IO-APIC is currently programmed. It needs to either:
(1) develop awareness of multiple APIC buses and not attempt to perform
physical mode interrupt delivery to non-existant destinations or
overflow destination bitmasks to cpus not physically addressible
from the local cluster
or
(2) the IO-APIC must be programmed for clustered hierarchical destinations
in clustered setups, which probably isn't that hot an idea as the
IO-APIC's in such setups usually have some affinity to the locally
addressible physical destinations
These are both a PITA, but I thought I'd just sort of fling the issues
into open discussion since something touching this code hit the list.
There's some complexity in these schemes so unless you feel brave and/or
interested there's no need for you to run off and implement them etc.
No criticism of or flaws in your patch implied.
Thanks,
Bill
^ permalink raw reply
* Re: [LARTC] Using HTB as an ISP "provisioning engine"
From: Daniel Egger @ 2002-12-20 11:07 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104033114505084@msgid-missing>
Am Don, 2002-12-19 um 22.10 schrieb Stef Coene:
> Example :
> You selled 1.1 Mbps to customer1 and 0.37 (=2.2Mbps/6) to 3 other customers.
> So you have a total bandwidth of 2.2Mbps. But you have only 1.2 Mbps
> available.
> class rate = ceil = 1.2 Mbps
> class1 rate = 0.6, ceil = 1.1Mbps
> class2 rate = 0.2, ceil = 0.37Mbps
> class3 rate = 0.2, ceil = 0.37Mbps
> class4 rate = 0.2, ceil = 0.37Mbps
> The bandwidth you selled to the customers is the ceil. They never can use
> more then the ceil. If one customer is using no bandwidth, the remaining
> bandwidth is given to the other customers.
> If all customers are using all bandwidth, each customer is "punished" in the
> same way.
Nice, however (see other mail) it seems unpossible to remove subclasses
on-the-fly which is a hard requirement here. Do I have to recreate the
whole tree on the fly? If so, won't this negatively affect the queues
because all statistics are lost?
--
Servus,
Daniel
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* harddisk freeze on 2.4.20
From: Soeren Sonnenburg @ 2002-12-20 11:08 UTC (permalink / raw)
To: linux-kernel
Hi!
My current setup is A7V8x 2 WDC 180GB disks in raid0, both are masters
(without slaves) on the primary and secondary onboard VT8235 controller.
The drives are attached at the connector in the middle of the cable.
When doing a badblock scan of /dev/hda and /dev/hdc the primary master
disk freezes from time to time, i.e.
it is not accessible anymore/coldfreeze of the system ... even after
a cold reboot the bios complains "primary master fails".
A powerdown / poweron cycle fixes this.
I am not sure whether the reason is cable/DMA/bios of the harddisk/bios/or
linux ide drivers. However to find out the exact cause of this problem I am
grateful for hints on how to find out where the problem lies...
I already tried a different cable for the primary master disk... still the
same problem occurs.
Thanks,
Soeren.
^ permalink raw reply
* [PATCH] zero-size E820 memory (kernel start-up failure)
From: Alexander Achenbach @ 2002-12-20 11:02 UTC (permalink / raw)
To: davej, hpa, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
Hi everybody.
This patch fixes the
Ok, booting the kernel. [hangs]
problem with BIOSes that report E820 memory maps with zero-size entries.
Among the mainboards affected are
EPOX 4G4A+ (presumably)
EPOX 4BEA[-R]
Chaintech 9EJL .
In the past (kernels up to 2.4.20), these mainboards could only boot Linux
with explicit 'mem=' boot parameters.
Up to 2.4.20, a zero-size E820 memory region (eg 0xa0000 - 0xa0000)
reported by the BIOS causes 'sanitize_e820_map' to take the end of this
region as the start of another region, producing two overlapping regions
extending to the end of addressable memory. If the zero-size region is of
a higher type than 'usable RAM' (eg 'reserved'), this causes all memory
above the zero-size region to be marked unusable (leaving 640k as of the
above example -- the kernel fails to start at all).
The patch adds code to remove empty entries before sorting regions. It
was generated for a 2.4.20 kernel.
Best regards,
Alex
[ Please send answers to my Reply-To address.
I'm not subscribed to the kernel mailing list. ]
[-- Attachment #2: nullmem.diff --]
[-- Type: text/plain, Size: 2365 bytes --]
diff -ur linux-2.4.20/arch/i386/kernel/setup.c linux-2.4.20-nullmem/arch/i386/kernel/setup.c
--- linux-2.4.20/arch/i386/kernel/setup.c Fri Nov 29 00:53:09 2002
+++ linux-2.4.20-nullmem/arch/i386/kernel/setup.c Mon Dec 16 14:52:21 2002
@@ -71,6 +71,9 @@
* CacheSize bug workaround updates for AMD, Intel & VIA Cyrix.
* Dave Jones <davej@suse.de>, September, October 2001.
*
+ * Provisions for empty E820 memory regions (reported by certain BIOSes).
+ * Alex Achenbach <xela@slit.de>, December 2002.
+ *
*/
/*
@@ -501,7 +504,7 @@
int chgidx, still_changing;
int overlap_entries;
int new_bios_entry;
- int old_nr, new_nr;
+ int old_nr, new_nr, chg_nr;
int i;
/*
@@ -555,20 +558,24 @@
for (i=0; i < 2*old_nr; i++)
change_point[i] = &change_point_list[i];
- /* record all known change-points (starting and ending addresses) */
+ /* record all known change-points (starting and ending addresses),
+ omitting those that are for empty memory regions */
chgidx = 0;
for (i=0; i < old_nr; i++) {
- change_point[chgidx]->addr = biosmap[i].addr;
- change_point[chgidx++]->pbios = &biosmap[i];
- change_point[chgidx]->addr = biosmap[i].addr + biosmap[i].size;
- change_point[chgidx++]->pbios = &biosmap[i];
+ if (biosmap[i].size != 0) {
+ change_point[chgidx]->addr = biosmap[i].addr;
+ change_point[chgidx++]->pbios = &biosmap[i];
+ change_point[chgidx]->addr = biosmap[i].addr + biosmap[i].size;
+ change_point[chgidx++]->pbios = &biosmap[i];
+ }
}
+ chg_nr = chgidx; /* true number of change-points */
/* sort change-point list by memory addresses (low -> high) */
still_changing = 1;
while (still_changing) {
still_changing = 0;
- for (i=1; i < 2*old_nr; i++) {
+ for (i=1; i < chg_nr; i++) {
/* if <current_addr> > <last_addr>, swap */
/* or, if current=<start_addr> & last=<end_addr>, swap */
if ((change_point[i]->addr < change_point[i-1]->addr) ||
@@ -591,7 +598,7 @@
last_type = 0; /* start with undefined memory type */
last_addr = 0; /* start with 0 as last starting address */
/* loop through change-points, determining affect on the new bios map */
- for (chgidx=0; chgidx < 2*old_nr; chgidx++)
+ for (chgidx=0; chgidx < chg_nr; chgidx++)
{
/* keep track of all overlapping bios entries */
if (change_point[chgidx]->addr == change_point[chgidx]->pbios->addr)
^ permalink raw reply
* Re: cmpci: microphone/line in not working
From: Måns Rullgård @ 2002-12-20 10:56 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1040257890.1248.62.camel@piteu>
Pierre-Marc Fournier <pmf@users.sourceforge.net> writes:
> Hello, my microphone does not work with my c-media CM8738 (builtin in
> asus a7v333 motherboard).
> Using kernel 2.4.18
Try the ALSA drivers.
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply
* Re: [PATCH 2.4] : donauboe IrDA driver (resend)
From: Dumitru Ciobarcianu @ 2002-12-20 10:55 UTC (permalink / raw)
To: jt
Cc: James McKenzie, Christian Gennerat, Martin Lucina,
Marcelo Tosatti, Linux kernel mailing list
In-Reply-To: <20021219185630.GC6703@bougret.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Jo, 2002-12-19 at 20:56, Jean Tourrilhes wrote:
> On Thu, Dec 19, 2002 at 05:05:16PM +0200, Dumitru Ciobarcianu wrote:
> >
> As I don't have this hardware, I fully depend on people trying
> the code to know if it works or not. This driver has been for 6 months
> in kernel 2.5.X and on my web page (and advertised on the IrDA mailing
> list), and it's only today that I get the first negative bug report.
[...]
> Also, would you mind sending this bug report to all three
> maintainers of the driver ? Also : would you mind sending the log
> output of the old toshoboe driver (assuming it works - does it ?).
Well, about the bug report it could be me being lazy or not having
enough time... :)
It works with the old toshoboe driver.
If I load the module with "do_probe=0" donauoboe loads on the first try,
thanks for the hint:
toshoboe: Using multiple tasks, version $Id: donauboe.c V2.17 jeu sep 12
08:50:20 2002 $
This is what I dug up from an old bootlog (for the old toshoboe
messages):
Linux version 2.4.18-5.64LNX (root@LNX.iNES.RO) (gcc version 3.1
20020620 (Red Hat Linux Rawhide 3.1-7)) #1 Wed Jul 10 00:30:01 EEST 2002
[..snip..]
IrDA: Registered device irda0
ToshOboe: Using single tasks, version $Id: toshoboe.c,v 1.91 1999/06/29 14:21:06 root Exp $
ToshOboe: setting baud to 9600
[..snip..]
Let me know if I can be of any help.
//Cioby
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* ACCEPT/DROP
From: Venkatesh Prasad Ranganath @ 2002-12-20 10:42 UTC (permalink / raw)
To: netfilter; +Cc: nf
Hi,
I was looking into the iptables implementation and was intrigued about
how iptables would handle a situation in which we have identical rules
except for their targets which are contradicting, say ACCEPT and DROP.
By looking at ipt_do_table() function it seems that the first
non-IPT_RETURN verdict from any standard target will end the traversal
of a chain of a table, which seems to be a bit odd. First, such
conflicting rules must not be allowed. Even beyond, this fails in the
situation where you have a dropping rule added after an accepting rule.
For example, a packet from m.n.o.p to a.b.c.d would be accepted at
a.b.c.d because of the first rule, although it had to be dropped
according to the second rule. And this would result because of the
order in which the rules are added to the table.
iptables -A INPUT -d a.b.c.d -j ACCEPT
iptables -A INPUT -s m.n.o.p -j DROP
Is my understanding correct? If so, I am curious to know how nf-hipac
behaves in such situations?
waiting for reply,
--
Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad
^ permalink raw reply
* 2.5.52: Many, many unresolved symbols!?
From: axel @ 2002-12-20 10:46 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi,
after kernel build of 2.5.52-bk4 snapshot, depmod results in a very long
list of unresolved symbols.
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.5.52bk4; fi
depmod: *** Unresolved symbols in
/lib/modules/2.5.52bk4/kernel/drivers/block/floppy.ko
...
...
...
I see it! All the listed files that have unresolved symbols end in .ko ?!
I believe that's not ok.
I have attached the bzipped output.
Best regards,
Axel Siebenwirth
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
[-- Attachment #2: build.log.bz2 --]
[-- Type: application/octet-stream, Size: 3452 bytes --]
^ permalink raw reply
* Re: [linux-dvb] How to compil dvb CVS with 2.5.52?
From: Holger Waechtler @ 2002-12-20 10:39 UTC (permalink / raw)
To: Gregoire Favre; +Cc: linux-dvb, linux-kernel
In-Reply-To: <20021219222730.GA3324@ulima.unil.ch>
Hi Gregoire,
Gregoire Favre wrote:
>
> It then don't compil and i have to patch with the patch sent to this
> list the Wed, 11 Dec 2002 10:53:43 +1100 from Rusty Russell:
>
> --- drivers/media/dvb/dvb-core/dvb_i2c.c 2002-12-19 23:21:07.000000000 +0100
> +++ drivers/media/dvb/dvb-core/dvb_i2c.c~ 2002-11-28 19:57:09.000000000 +0100
> @@ -64,8 +64,10 @@
> void try_attach_device (struct dvb_i2c_bus *i2c, struct dvb_i2c_device *dev)
> {
> if (dev->owner) {
> - if (!try_inc_mod_count(dev->owner))
> + if (!MOD_CAN_QUERY(dev->owner))
> return;
> +
> + __MOD_INC_USE_COUNT(dev->owner);
> }
>
> if (dev->attach (i2c) == 0) {
>
are you sure? MOD_CAN_QUERY() and __MOD_INC_USE_COUNT() are 2.4 macros,
they are deprecated now. The compatibility fake is implemented in
compat.h. Could you please check this again and tell me what exactly the
problem is?
Holger
^ permalink raw reply
* Re: [PATCH] joydev: fix HZ->millisecond transformation
From: george anzinger @ 2002-12-20 10:41 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Marcelo Tosatti, vojtech, linux-kernel
In-Reply-To: <200212161227.38764.bjorn_helgaas@hp.com>
Bjorn Helgaas wrote:
>
> * fix a problem with HZ->millisecond transformation on
> non-x86 archs (from 2.5 change by vojtech@suse.cz)
>
> Applies to 2.4.20.
>
> diff -Nru a/drivers/input/joydev.c b/drivers/input/joydev.c
> --- a/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> +++ b/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> @@ -50,6 +50,8 @@
> #define JOYDEV_MINORS 32
> #define JOYDEV_BUFFER_SIZE 64
>
> +#define MSECS(t) (1000 * ((t) / HZ) + 1000 * ((t) % HZ) / HZ)
Uh...
^^^^^^^^^^^^^^^^
by definition this is zero, is it not?
> +
> struct joydev {
> int exist;
> int open;
> @@ -134,7 +136,7 @@
> return;
> }
>
> - event.time = jiffies * (1000 / HZ);
> + event.time = MSECS(jiffies);
>
> while (list) {
>
> @@ -279,7 +281,7 @@
>
> struct js_event event;
>
> - event.time = jiffies * (1000/HZ);
> + event.time = MSECS(jiffies);
>
> if (list->startup < joydev->nkey) {
> event.type = JS_EVENT_BUTTON | JS_EVENT_INIT;
>
> -
> 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/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Russell King @ 2002-12-20 10:41 UTC (permalink / raw)
To: Dave Jones, Hanna Linder, Pete Zaitcev, linux-kernel, khoa,
mbligh
In-Reply-To: <20021220103212.GG24782@suse.de>
On Fri, Dec 20, 2002 at 10:32:12AM +0000, Dave Jones wrote:
> A periodic (once a month?) automated ping from bugzilla would be good.
> "You have these bugs assigned to you..." status report type thing.
I believe it already does that.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-20 10:40 UTC (permalink / raw)
To: John Bradford; +Cc: Martin J. Bligh, linux-kernel
In-Reply-To: <200212200948.gBK9mrXh000326@darkstar.example.net>
On Fri, Dec 20, 2002 at 09:48:53AM +0000, John Bradford wrote:
> > > I've got loads of ideas about how we could build a better bug database
> > Go ahead, knock yourself out. Come back when you're done.
> Not sure what you mean. I do intend to start coding a new bug
> database system today, and I'll announce it on the list when it's
> ready. If nobody likes it, I wasted my time.
So explain exactly what you intend to do. Maybe you're right, and there
are serious shortfallings. Right now all I see is whining about
"Bugzilla sucks, I could write a better one" with no actual facts
about why it sucks.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [PATCH]: make highmem only things enclosed in the right #ifdef
From: Juan Quintela @ 2002-12-20 10:36 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021219125246.27339I-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 19 Dec 2002, Juan Quintela wrote:
>> What do you think of this new one?
maciej> Well, you could remove the line below:
>> sizeof(pgd_t ) * USER_PTRS_PER_PGD);
>>
>> - pgd_base = swapper_pg_dir;
>>
>> #ifdef CONFIG_HIGHMEM
maciej> but that's nitpicking (and I may fix it up if Ralf applies the patch as
maciej> is) -- I've pointed you out the problem of spacing more to bring your
maciej> attention to such details than to object this particular change. The
maciej> patch looks semantically OK.
Hi
Do you preffer this way?
Later, Juan.
Index: arch/mips/mm/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/init.c,v
retrieving revision 1.38.2.7
diff -u -r1.38.2.7 init.c
--- arch/mips/mm/init.c 5 Aug 2002 23:53:35 -0000 1.38.2.7
+++ arch/mips/mm/init.c 20 Dec 2002 09:55:03 -0000
@@ -161,6 +161,7 @@
extern char _ftext, _etext, _fdata, _edata;
extern char __init_begin, __init_end;
+#ifdef CONFIG_HIGHMEM
static void __init fixrange_init (unsigned long start, unsigned long end,
pgd_t *pgd_base)
{
@@ -189,33 +190,35 @@
j = 0;
}
}
+#endif /* CONFIG_HIGHMEM */
void __init pagetable_init(void)
{
+#ifdef CONFIG_HIGHMEM
unsigned long vaddr;
- pgd_t *pgd, *pgd_base;
+ pgd_t *pgd;
pmd_t *pmd;
pte_t *pte;
+#endif
/* Initialize the entire pgd. */
pgd_init((unsigned long)swapper_pg_dir);
pgd_init((unsigned long)swapper_pg_dir +
sizeof(pgd_t ) * USER_PTRS_PER_PGD);
- pgd_base = swapper_pg_dir;
#ifdef CONFIG_HIGHMEM
/*
* Fixed mappings:
*/
vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
- fixrange_init(vaddr, 0, pgd_base);
+ fixrange_init(vaddr, 0, swapper_pg_dir);
/*
* Permanent kmaps:
*/
vaddr = PKMAP_BASE;
- fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
+ fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, swapper_pg_dir);
pgd = swapper_pg_dir + __pgd_offset(vaddr);
pmd = pmd_offset(pgd, vaddr);
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-20 10:35 UTC (permalink / raw)
To: Hanna Linder; +Cc: Martin J. Bligh, Eli Carter, Randy.Dunlap, linux-kernel
In-Reply-To: <71820000.1040349694@w-hlinder>
On Thu, Dec 19, 2002 at 06:01:34PM -0800, Hanna Linder wrote:
> > Anything in "OPEN" state isn't really assigned to anyone yet.
> > (the state would really better be named "NEW", but it's not).
> > People should move it to "ASSIGNED" if they're working on it.
> So the process is to query for all open bugs (but not
> assigned) then email each person to let them know you are
> working on it?
Why generate noise ?
Query bugs.
Find something interesting.
Fix it.
THEN email person (or better yet, add to bugzilla entry).
Flooding the database with "I'm working on this" reports
buys absolutely nothing.
> > Go to file a new bug, click on the link by the subcategories, and it'll
> > tell you (you'll have to pick the main category first).
> That is convoluted. You have to file a bug to find out who
> the subsystem maintainers are? Can you put it somewhere more
> obvious?
I think you're misunderstanding how things work.
The view you seem to have is to use bugzilla to find bugs,
and get a list of people who to email. This shuts out the
rest of the world who are watching that bug in bugzilla.
If you want to add to a bug reported in bugzilla, forget email,
just _use the tool_.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-20 10:32 UTC (permalink / raw)
To: Hanna Linder; +Cc: Pete Zaitcev, linux-kernel, khoa, mbligh
In-Reply-To: <66530000.1040346100@w-hlinder>
On Thu, Dec 19, 2002 at 05:01:41PM -0800, Hanna Linder wrote:
> Well thank you :) My argument is that there should be a
> way USING THE TOOL to determine which bugs are available to be
> worked on. Do you seriously want 2000 people emailing you privately
> asking if you are working on your bugs?
A periodic (once a month?) automated ping from bugzilla would be good.
"You have these bugs assigned to you..." status report type thing.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [PATCH]: fault.c use unblank_screen
From: Juan Quintela @ 2002-12-20 10:30 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
if CONFIG_VT is defined, this file uses unblank screen.
Later, Juan.
Index: arch/mips64/mm/fault.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/fault.c,v
retrieving revision 1.26.2.13
diff -u -r1.26.2.13 fault.c
--- arch/mips64/mm/fault.c 11 Sep 2002 12:44:29 -0000 1.26.2.13
+++ arch/mips64/mm/fault.c 20 Dec 2002 09:55:05 -0000
@@ -20,6 +20,7 @@
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/version.h>
+#include <linux/vt_kern.h>
#include <asm/branch.h>
#include <asm/hardirq.h>
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-20 10:30 UTC (permalink / raw)
To: Hanna Linder; +Cc: Pete Zaitcev, linux-kernel
In-Reply-To: <62590000.1040343543@w-hlinder>
On Thu, Dec 19, 2002 at 04:19:03PM -0800, Hanna Linder wrote:
> Im trying to help make it easier for such people to get a list
> of bugs to start working on. If it looks like everything already
> has an owner it looks like there is nothing to do.
Just because a bug is 'owned' does not stop someone else working on it.
That would be silly. All the owner field says is, "if someone is
interested in this bug, and they happen to fix before $owner does,
$owner would like to know about it." This way $owner can reject bad
fixes, or get further clues as to whats actually causing the problem.
> Hanna (obviously not a bugzilla user before)
Obviously 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [PATCH] Fix CPU bitmask truncation
From: William Lee Irwin III @ 2002-12-20 10:30 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, bjorn_helgaas
In-Reply-To: <200212161213.29230.bjorn_helgaas@hp.com>
On Mon, Dec 16, 2002 at 12:13:29PM -0700, Bjorn Helgaas wrote:
> This patch fixes some obviously incorrect bitmask truncations in 2.4.20.
Linus, this is the 2.5.x version of the same patch originally by Bjorn
for 2.4.x. This fixes an entire class of critical 64-bit bugs.
Against 2.5.52-bk as of 2:25AM 20 Dec 2002. Please apply.
Thanks,
Bill
Fix task->cpus_allowed bitmask truncations. Originally due to
Bjorn Helgaas for 2.4.x.
include/linux/init_task.h | 2 +-
kernel/module.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
===== include/linux/init_task.h 1.19 vs edited =====
--- 1.19/include/linux/init_task.h Sun Sep 29 07:02:55 2002
+++ edited/include/linux/init_task.h Fri Dec 20 02:22:04 2002
@@ -63,7 +63,7 @@
.prio = MAX_PRIO-20, \
.static_prio = MAX_PRIO-20, \
.policy = SCHED_NORMAL, \
- .cpus_allowed = -1, \
+ .cpus_allowed = ~0UL, \
.mm = NULL, \
.active_mm = &init_mm, \
.run_list = LIST_HEAD_INIT(tsk.run_list), \
===== kernel/module.c 1.31 vs edited =====
--- 1.31/kernel/module.c Sun Dec 1 22:44:11 2002
+++ edited/kernel/module.c Fri Dec 20 02:19:53 2002
@@ -210,7 +210,7 @@
struct sched_param param = { .sched_priority = MAX_RT_PRIO-1 };
setscheduler(current->pid, SCHED_FIFO, ¶m);
#endif
- set_cpus_allowed(current, 1 << (unsigned long)cpu);
+ set_cpus_allowed(current, 1UL << (unsigned long)cpu);
/* Ack: we are alive */
atomic_inc(&stopref_thread_ack);
@@ -271,7 +271,7 @@
/* FIXME: racy with set_cpus_allowed. */
old_allowed = current->cpus_allowed;
- set_cpus_allowed(current, 1 << (unsigned long)cpu);
+ set_cpus_allowed(current, 1UL << (unsigned long)cpu);
atomic_set(&stopref_thread_ack, 0);
stopref_num_threads = 0;
^ permalink raw reply
* [PATCH]: scatter list are supposed to have a int length
From: Juan Quintela @ 2002-12-20 10:27 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
length is int in: alpha, sparc64, ppc64 and s390x.
Later, Juan.
Index: include/asm-mips64/scatterlist.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/scatterlist.h,v
retrieving revision 1.4.2.5
diff -u -r1.4.2.5 scatterlist.h
--- include/asm-mips64/scatterlist.h 28 Sep 2002 18:51:41 -0000 1.4.2.5
+++ include/asm-mips64/scatterlist.h 20 Dec 2002 09:55:13 -0000
@@ -7,7 +7,7 @@
struct page * page; /* Location for highmem page, if any */
unsigned int offset;
dma_addr_t dma_address;
- unsigned long length;
+ unsigned int length;
};
#define ISA_DMA_THRESHOLD (0x00ffffff)
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ 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.