yeah let's not fix this before it's a decade old. not much longer to
wait!
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kdegraphics in ubuntu.
https://bugs.launchpad.net/bugs/176902
Title:
kpdf locks sound output
--
kubuntu-bugs
yeah let's not fix this before it's a decade old. not much longer to
wait!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/102408
Title:
Helper apps inherit open file descriptors
--
ubuntu-bugs
yeah let's not fix this before it's a decade old. not much longer to
wait!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
https://bugs.launchpad.net/bugs/159258
Title:
Helper applications launched by Firefox inherit ALL file
this is a fairly serious regression.
-dean
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: iproute
Version: 20080725-2
i did:
sudo apt-get build-dep iproute
apt-get source iproute
cd iproute-20080725-2
fakeroot ./debian/rules binary
and it fails:
...
/usr/share/texmf-texlive/dvips/base/texps.pro
/usr/share/texmf-texlive/dvips/base/special.pro
package: netbase
version: 4.33
spot the bug in /etc/init.d/networking:
process_options() {
[ -e /etc/network/options ] || return 0
log_warning_msg /etc/network/options still exists and it will be IGNORED!
Read README.Debian of netbase.
}
there should be a return 0 after the
On Tue, 20 May 2008, Richard Salz wrote:
on the other hand it may be a known plaintext attack.
Using those words in this context makes it sound that you not only don't
understand what is being discussed right here and now, but also that you
don't understand the term you just used. Are
On Thu, 15 May 2008, Geoff Thorpe wrote:
I forgot to mention something;
On Thursday 15 May 2008 12:38:24 John Parker wrote:
It is already possible to use openssl and valgrind - just build
OpenSSL with -DPURIFY, and it is quite clean.
Actually on my system, just -DPURIFY
On Thu, 15 May 2008, Bodo Moeller wrote:
On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
[EMAIL PROTECTED] wrote:
Goetz Babin-Ebell wrote:
But here the use of this uninitialized data is intentional
and the programmer are very well aware of what they did.
The use of
On Mon, 19 May 2008, David Schwartz wrote:
any special case changes for testing means you're not testing the REAL
CODE.
You mean you're not testing *all* of the real code. That's fine, you can't
debug everythign at once.
if you haven't tested your final production binary then you
Package: fail2ban
Version: 0.8.2-3
fail2ban 0.6 supported a syslog-facility config option which controlled
the facility for syslog messages... 0.8.2-3 does not support this. i had
to edit /usr/share/fail2ban/server/server.py in order to change LOG_DAEMON
to LOG_AUTH.
-dean
--
To
Package: fail2ban
Version: 0.8.2-3
when connecting with ssh keys, no password, sshd logs:
May 18 05:08:45 twinlark sshd[5681]: Failed none for dean from 10.1.1.1 port
37262 ssh2
May 18 05:08:45 twinlark sshd[5681]: Found matching RSA key:
May 18 05:08:45 twinlark sshd[5681]: Found matching
Package: apt-listchanges
Version: 2.82
when apt-listchanges encounters an error (such as the now infamous
database /var/lib/apt/listchanges.db failed to load. error) it continues
without confirmation even if confirm=1 is in the etc file. i think
apt-listchanges should always ask for
one of the more important details in evaluating these changes would be the
family/model/stepping of the processors being microbenchmarked... could
you folks include /proc/cpuinfo with the results?
also -- please drop the #define for R16 to %rsp ... it obfuscates more
than it helps anything.
actually yeah i've seen this... in a bizarre failure situation in a system
which physically had RAM in the boot node but it was never enumerated for
the kernel (other nodes had RAM which was enumerated).
so technically there was boot node RAM but the kernel never saw it.
-dean
On Wed, 30 Jan
why do we need another kernel cpuid reading method when sched_setaffinity
exists and cpuid is available in ring3?
-dean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 29 Jan 2008, Andi Kleen wrote:
> > SRAT is essentially just a two dimensional table with node distances.
>
> Sorry, that was actually SLIT. SRAT is not two dimensional, but also
> relatively simple. SLIT you don't really need to implement.
yeah but i'd heartily recommend implementing
On Tue, 29 Jan 2008, Andi Kleen wrote:
SRAT is essentially just a two dimensional table with node distances.
Sorry, that was actually SLIT. SRAT is not two dimensional, but also
relatively simple. SLIT you don't really need to implement.
yeah but i'd heartily recommend implementing SLIT
why do we need another kernel cpuid reading method when sched_setaffinity
exists and cpuid is available in ring3?
-dean
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
actually yeah i've seen this... in a bizarre failure situation in a system
which physically had RAM in the boot node but it was never enumerated for
the kernel (other nodes had RAM which was enumerated).
so technically there was boot node RAM but the kernel never saw it.
-dean
On Wed, 30 Jan
On Mon, 14 Jan 2008, Dave Kempe wrote:
Lexje wrote:
I'm completely new to rdiff-backup.
I'm trying to backup a complete server over the internet. Is it possible to
pause, stop / restart rdiff-backup? (To free up / respect
bandwith limitations)
You could do a Ctrl-Z and then start it
On Thu, 17 Jan 2008, Patrick J. LoPresti wrote:
> I need to copy large (> 100GB) files between machines on a fast
> network. Both machines have reasonably fast disk subsystems, with
> read/write performance benchmarked at > 800 MB/sec. Using 10GigE cards
> and the usual tweaks to tcp_rmem etc.,
On Thu, 17 Jan 2008, Patrick J. LoPresti wrote:
I need to copy large ( 100GB) files between machines on a fast
network. Both machines have reasonably fast disk subsystems, with
read/write performance benchmarked at 800 MB/sec. Using 10GigE cards
and the usual tweaks to tcp_rmem etc., I am
On Tue, 15 Jan 2008, Andrew Morton wrote:
> On Tue, 15 Jan 2008 21:01:17 -0800 (PST) dean gaudet <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, 14 Jan 2008, NeilBrown wrote:
> >
> > >
> > > raid5's 'make_request' function calls generic_make_request
elayed is only called at unplug time, never in
> raid5. This seems to bring back the performance numbers. Calling it
> in raid5d was sometimes too soon...
>
> Cc: "Dan Williams" <[EMAIL PROTECTED]>
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
probably doesn't
the performance numbers. Calling it
in raid5d was sometimes too soon...
Cc: Dan Williams [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
probably doesn't matter, but for the record:
Tested-by: dean gaudet [EMAIL PROTECTED]
this time i tested with internal and external bitmaps
On Tue, 15 Jan 2008, Andrew Morton wrote:
On Tue, 15 Jan 2008 21:01:17 -0800 (PST) dean gaudet [EMAIL PROTECTED]
wrote:
On Mon, 14 Jan 2008, NeilBrown wrote:
raid5's 'make_request' function calls generic_make_request on
underlying devices and if we run out of stripe heads
the performance numbers. Calling it
in raid5d was sometimes too soon...
Cc: Dan Williams [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
probably doesn't matter, but for the record:
Tested-by: dean gaudet [EMAIL PROTECTED]
this time i tested with internal and external bitmaps
On Tue, 15 Jan 2008, Andrew Morton wrote:
On Tue, 15 Jan 2008 21:01:17 -0800 (PST) dean gaudet [EMAIL PROTECTED]
wrote:
On Mon, 14 Jan 2008, NeilBrown wrote:
raid5's 'make_request' function calls generic_make_request on
underlying devices and if we run out of stripe heads
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
still disables TSC :)
Marking TSC unstable due to TSCs unsynchronized
this is an opteron 2xx box which does have two cpus and no clock-divide in
halt or cpufreq enabled so TSC should be fine with only one cpu.
pretty sure
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
still disables TSC :)
Marking TSC unstable due to TSCs unsynchronized
this is an opteron 2xx box which does have two cpus and no clock-divide in
halt or cpufreq enabled so TSC should be fine with only one cpu.
pretty sure
On Fri, 11 Jan 2008, dean gaudet wrote:
> On Fri, 11 Jan 2008, Ingo Molnar wrote:
>
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > Cached requires the cache line to be read first before you can write
> > > it.
> >
> > nons
On Fri, 11 Jan 2008, Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Cached requires the cache line to be read first before you can write
> > it.
>
> nonsense, and you should know it. It is perfectly possible to construct
> fully written cachelines, without reading the
On Fri, 11 Jan 2008, Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
Cached requires the cache line to be read first before you can write
it.
nonsense, and you should know it. It is perfectly possible to construct
fully written cachelines, without reading the cacheline
On Fri, 11 Jan 2008, dean gaudet wrote:
On Fri, 11 Jan 2008, Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
Cached requires the cache line to be read first before you can write
it.
nonsense, and you should know it. It is perfectly possible to construct
fully
On Thu, 10 Jan 2008, Neil Brown wrote:
On Wednesday January 9, [EMAIL PROTECTED] wrote:
On Sun, 2007-12-30 at 10:58 -0700, dean gaudet wrote:
i have evidence pointing to d89d87965dcbe6fe4f96a2a7e8421b3a75f634d1
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
On Fri, 11 Jan 2008, Neil Brown wrote:
Thanks.
But I suspect you didn't test it with a bitmap :-)
I ran the mdadm test suite and it hit a problem - easy enough to fix.
damn -- i lost my bitmap 'cause it was external and i didn't have things
set up properly to pick it up after a reboot :)
if
On Tue, 8 Jan 2008, Bill Davidsen wrote:
Neil Brown wrote:
On Monday January 7, [EMAIL PROTECTED] wrote:
Problem is not raid, or at least not obviously raid related. The problem
is that the whole disk, /dev/hdb is unavailable.
Maybe check /sys/block/hdb/holders ? lsof
On Sat, 29 Dec 2007, Dan Williams wrote:
On Dec 29, 2007 1:58 PM, dean gaudet [EMAIL PROTECTED] wrote:
On Sat, 29 Dec 2007, Dan Williams wrote:
On Dec 29, 2007 9:48 AM, dean gaudet [EMAIL PROTECTED] wrote:
hmm bummer, i'm doing another test (rsync 3.5M inodes from another box
On Sun, 30 Dec 2007, Thiemo Nagel wrote:
stripe_cache_size (currently raid5 only)
As far as I have understood, it applies to raid6, too.
good point... and raid4.
here's an updated patch.
-dean
Signed-off-by: dean gaudet [EMAIL PROTECTED]
Index: linux/Documentation/md.txt
On Sun, 30 Dec 2007, dean gaudet wrote:
On Sun, 30 Dec 2007, Thiemo Nagel wrote:
stripe_cache_size (currently raid5 only)
As far as I have understood, it applies to raid6, too.
good point... and raid4.
here's an updated patch.
and once again with a typo fix. oops.
-dean
On Sat, 29 Dec 2007, [EMAIL PROTECTED] wrote:
> On Sat, 29 Dec 2007 12:40:47 PST, dean gaudet said:
>
> > the main worry i have is some user maliciously hardlinks everything
> > under /var/log somewhere else and slowly fills up the file system with
> > old rotated logs
On Sun, 30 Dec 2007, David Newall wrote:
> dean gaudet wrote:
> > > Pffuff. That's what volume managers are for! You do have (at least) two
> > > independent spindles in your RAID1 array, which give you less need to
> > > worry
>
On Sat, 29 Dec 2007, David Newall wrote:
> dean gaudet wrote:
> > On Wed, 19 Dec 2007, David Newall wrote:
> >
> > > Mark Lord wrote:
> > >
> > > > But.. pity there's no mount flag override for smaller systems,
> > > > where bind
to (chunk_size * raid_disks * stripe_cache_size) or (chunk_size *
raid_disks * stripe_cache_active)?
-dean
On Thu, 27 Dec 2007, dean gaudet wrote:
hmm this seems more serious... i just ran into it with chunksize 64KiB and
while just untarring a bunch of linux kernels in parallel... increasing
On Tue, 25 Dec 2007, Bill Davidsen wrote:
The issue I'm thinking about is hardware sector size, which on modern drives
may be larger than 512b and therefore entail a read-alter-rewrite (RAR) cycle
when writing a 512b block.
i'm not sure any shipping SATA disks have larger than 512B sectors
On Sat, 29 Dec 2007, Dan Williams wrote:
On Dec 29, 2007 9:48 AM, dean gaudet [EMAIL PROTECTED] wrote:
hmm bummer, i'm doing another test (rsync 3.5M inodes from another box) on
the same 64k chunk array and had raised the stripe_cache_size to 1024...
and got a hang. this time i grabbed
Document the amount of memory used by the stripe cache and the fact that
it's tied down and unavailable for other purposes (right?). thanks to Dan
Williams for the formula.
-dean
Signed-off-by: dean gaudet [EMAIL PROTECTED]
Index: linux/Documentation/md.txt
On Sat, 29 Dec 2007, Justin Piszcz wrote:
Curious btw what kind of filesystem size/raid type (5, but defaults I assume,
nothing special right? (right-symmetric vs. left-symmetric, etc?)/cache
size/chunk size(s) are you using/testing with?
mdadm --create --level=5 --chunk=64 -n7 -x1 /dev/md2
On Sat, 29 Dec 2007, dean gaudet wrote:
On Sat, 29 Dec 2007, Justin Piszcz wrote:
Curious btw what kind of filesystem size/raid type (5, but defaults I
assume,
nothing special right? (right-symmetric vs. left-symmetric, etc?)/cache
size/chunk size(s) are you using/testing
On Sat, 29 Dec 2007, David Newall wrote:
dean gaudet wrote:
On Wed, 19 Dec 2007, David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I
On Sun, 30 Dec 2007, David Newall wrote:
dean gaudet wrote:
Pffuff. That's what volume managers are for! You do have (at least) two
independent spindles in your RAID1 array, which give you less need to
worry
about head-stack contention.
this system is write intensive
On Sat, 29 Dec 2007, [EMAIL PROTECTED] wrote:
On Sat, 29 Dec 2007 12:40:47 PST, dean gaudet said:
the main worry i have is some user maliciously hardlinks everything
under /var/log somewhere else and slowly fills up the file system with
old rotated logs.
Doctor, it hurts when I do
On Sat, 29 Dec 2007, Jan Engelhardt wrote:
>
> On Dec 28 2007 18:53, dean gaudet wrote:
> >p.s. in retrospect i probably could have arranged it more like this:
> >
> > mount /dev/md1 $tmpmntpoint
> > mount --bind $tmpmntpoint/var /var
> > mount --bind
On Wed, 19 Dec 2007, David Newall wrote:
> Mark Lord wrote:
> > But.. pity there's no mount flag override for smaller systems,
> > where bind mounts might be more useful with link(2) actually working.
>
> I don't see it. You always can make hard link on the underlying filesystem.
> If you need
On Wed, 19 Dec 2007, David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying filesystem.
If you need to make
On Sat, 29 Dec 2007, Jan Engelhardt wrote:
On Dec 28 2007 18:53, dean gaudet wrote:
p.s. in retrospect i probably could have arranged it more like this:
mount /dev/md1 $tmpmntpoint
mount --bind $tmpmntpoint/var /var
mount --bind $tmpmntpoint/home /home
umount $tmpmntpoint
hmm this seems more serious... i just ran into it with chunksize 64KiB and
while just untarring a bunch of linux kernels in parallel... increasing
stripe_cache_size did the trick again.
-dean
On Thu, 27 Dec 2007, dean gaudet wrote:
hey neil -- remember that raid5 hang which me and only one
... in this case it's with a workload which is
untarring 34 copies of the linux kernel at the same time. it's a variant
of doug ledford's memtest, and i've attached it.
-dean#!/usr/bin/perl
# Copyright (c) 2007 dean gaudet [EMAIL PROTECTED]
#
# Permission is hereby granted, free of charge, to any
On Thu, 6 Dec 2007, Michael Tokarev wrote:
I come across a situation where external MD bitmaps
aren't usable on any standard linux distribution
unless special (non-trivial) actions are taken.
First is a small buglet in mdadm, or two.
It's not possible to specify --bitmap= in assemble
On Fri, 23 Nov 2007, Arne Georg Gleditsch wrote:
> dean gaudet <[EMAIL PROTECTED]> writes:
> > on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16
> > bytes. the penalty is a mere 3 cycles if an access crosses the specified
> > boundar
On Fri, 23 Nov 2007, Arne Georg Gleditsch wrote:
dean gaudet [EMAIL PROTECTED] writes:
on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16
bytes. the penalty is a mere 3 cycles if an access crosses the specified
boundary.
Worth noting though, is that atomic
On Fri, 23 Nov 2007, Alan Cox wrote:
> Its usually faster if you don't misalign on x86 as well.
i'm not sure if i agree with "usually"... but i know you (alan) are
probably aware of the exact requirements of the hw.
for everyone else:
on intel x86 processors an access is unaligned only if it
On Fri, 23 Nov 2007, Alan Cox wrote:
Its usually faster if you don't misalign on x86 as well.
i'm not sure if i agree with usually... but i know you (alan) are
probably aware of the exact requirements of the hw.
for everyone else:
on intel x86 processors an access is unaligned only if it
On Tue, 20 Nov 2007, dean gaudet wrote:
> On Tue, 20 Nov 2007, Metzger, Markus T wrote:
>
> > +__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c)
> > +{
> > + switch (c->x86) {
> > + case 0x6:
> > + switch (c->x86_model) {
>
On Tue, 20 Nov 2007, Metzger, Markus T wrote:
> +__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c)
> +{
> + switch (c->x86) {
> + case 0x6:
> + switch (c->x86_model) {
> +#ifdef __i386__
> + case 0xD:
> + case 0xE: /* Pentium M */
> +
On Mon, 19 Nov 2007, Ingo Molnar wrote:
>
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > I do see a problem, because some readers will take your example as a
> > reference, as it will probably sit in a page that
> > google^Wsearch_engines will bring at the top of search results for
> >
On Mon, 19 Nov 2007, Ingo Molnar wrote:
* Eric Dumazet [EMAIL PROTECTED] wrote:
I do see a problem, because some readers will take your example as a
reference, as it will probably sit in a page that
google^Wsearch_engines will bring at the top of search results for
next ten years
On Tue, 20 Nov 2007, dean gaudet wrote:
On Tue, 20 Nov 2007, Metzger, Markus T wrote:
+__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c)
+{
+ switch (c-x86) {
+ case 0x6:
+ switch (c-x86_model) {
+#ifdef __i386__
+ case 0xD:
+ case
On Tue, 20 Nov 2007, Metzger, Markus T wrote:
+__cpuinit void ptrace_bts_init_intel(struct cpuinfo_x86 *c)
+{
+ switch (c-x86) {
+ case 0x6:
+ switch (c-x86_model) {
+#ifdef __i386__
+ case 0xD:
+ case 0xE: /* Pentium M */
+
On Fri, 16 Nov 2007, Ulrich Drepper wrote:
> dean gaudet wrote:
> > honestly i think there should be a per-task flag which indicates whether
> > fds are by default F_CLOEXEC or not. my reason: third party libraries.
>
> Only somebody who thinks exclusively about ap
you know... i understand the need for FD_CLOEXEC -- in fact i tried
petitioning for CLOEXEC options to all the fd creating syscalls something
like 7 years ago when i was banging my head against the wall trying to
figure out how to thread apache... but even still i'm not convinced that
On Fri, 16 Nov 2007, Andi Kleen wrote:
> I didn't see a clear list.
- cross platform extensible API for configuring perf counters
- support for multiplexed counters
- support for virtualized 64-bit counters
- support for PC and call graph sampling at specific intervals
- support for reading
On Fri, 16 Nov 2007, Ulrich Drepper wrote:
dean gaudet wrote:
honestly i think there should be a per-task flag which indicates whether
fds are by default F_CLOEXEC or not. my reason: third party libraries.
Only somebody who thinks exclusively about applications as opposed to
runtimes
On Fri, 16 Nov 2007, Andi Kleen wrote:
I didn't see a clear list.
- cross platform extensible API for configuring perf counters
- support for multiplexed counters
- support for virtualized 64-bit counters
- support for PC and call graph sampling at specific intervals
- support for reading
you know... i understand the need for FD_CLOEXEC -- in fact i tried
petitioning for CLOEXEC options to all the fd creating syscalls something
like 7 years ago when i was banging my head against the wall trying to
figure out how to thread apache... but even still i'm not convinced that
On Thu, 15 Nov 2007, Paul Mackerras wrote:
> dean gaudet writes:
>
> > actually multiplexing is the main feature i am in need of. there are an
> > insufficient number of counters (even on k8 with 4 counters) to do
> > complete stall accounting or to get a general over
On Wed, 14 Nov 2007, Andi Kleen wrote:
> Later a syscall might be needed with event multiplexing, but that seems
> more like a far away non essential feature.
actually multiplexing is the main feature i am in need of. there are an
insufficient number of counters (even on k8 with 4 counters) to
On Wed, 14 Nov 2007, Andi Kleen wrote:
Later a syscall might be needed with event multiplexing, but that seems
more like a far away non essential feature.
actually multiplexing is the main feature i am in need of. there are an
insufficient number of counters (even on k8 with 4 counters) to do
On Thu, 15 Nov 2007, Paul Mackerras wrote:
dean gaudet writes:
actually multiplexing is the main feature i am in need of. there are an
insufficient number of counters (even on k8 with 4 counters) to do
complete stall accounting or to get a general overview of L1d/L1i/L2 cache
hit
fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubscribe from
fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/netdev@vger.kernel.org/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubscribe
fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubscribe from
On Sun, 21 Oct 2007, Jeremy Fitzhardinge wrote:
> dean gaudet wrote:
> > On Mon, 15 Oct 2007, Nick Piggin wrote:
> >
> >
> >> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
> >> because it generally has to invalidate
On Mon, 15 Oct 2007, Nick Piggin wrote:
> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
> because it generally has to invalidate TLBs on all CPUs.
why is that? ignoring 32-bit archs we have heaps of address space
available... couldn't the kernel just burn address space
On Mon, 15 Oct 2007, Nick Piggin wrote:
Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
because it generally has to invalidate TLBs on all CPUs.
why is that? ignoring 32-bit archs we have heaps of address space
available... couldn't the kernel just burn address space
On Sun, 21 Oct 2007, Jeremy Fitzhardinge wrote:
dean gaudet wrote:
On Mon, 15 Oct 2007, Nick Piggin wrote:
Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
because it generally has to invalidate TLBs on all CPUs.
why is that? ignoring 32-bit archs we
Package: zsh
Version: 4.3.4-23
upgrading from 4.3.4-19 to 4.3.4-23 caused zsh to be removed from
/etc/shells... i have a nightly cron job which looks for users with
invalid shells and it picked up this change last night after i did the
aforementioned upgrade yesterday.
-dean
--
To
Package: alpine
Version: 0.+dfsg-1
this is a pine 4.64 - alpine 0. regression. when a message with long
lines is piped through an external command the lines are truncated. i see
no options for scrolling the display or avoiding the truncation. note
that regular message viewing wraps
i rebuilt 0.11.7-1 from source (fetched from snapshot.debian.org) and it
seems not to be crashing (crashes were occuring in under a day before and
i've had 0.11.7-1 going for 2 days)... so this really is a 0.11.7-1 -
0.11.8-1 regression. i'm going to upgrade my gcc/etc to latest bleeding
edge
damn... -fno-strict-aliasing isn't enough to fix the crash i started
seeing in 0.11.8. i built my own package, but saw a crash within 24h.
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libtorrent10
Version: 0.11.8-1
between 0.11.7 and 0.11.8-1 i started getting regular crashes starting
with:
** glibc detected *** /usr/bin/rtorrent: double free or corruption
(!prev): 0x0b0952b0 ***
this is on amd64.
i looked at the known issues page and it requires
On Fri, 28 Sep 2007, martin f krafft wrote:
also sprach dean gaudet [EMAIL PROTECTED] [2007.09.28.0230 +0100]:
it is EXEPTIONALLY DANGEROUS to replace EVERY SINGLE initrd when mdadm is
installed/upgraded.
Please STOP SCREAMING and look at the existing bugs before you reply
new ones
Package: mdadm
Version: 2.6.2-2
it is EXEPTIONALLY DANGEROUS to replace EVERY SINGLE initrd when mdadm is
installed/upgraded.
you pretty much guarantee that any problem will produce an unbootable
system -- especially if root is on md.
as has just occured to me.
in the past in this situation
On Sat, 8 Sep 2007, Petr Vandrovec wrote:
> dean gaudet wrote:
> > On Sun, 9 Sep 2007, Nick Piggin wrote:
> >
> > > I've also heard that string operations do not follow the normal ordering,
> > > but
> > > that's just with respect to individual
On Sun, 9 Sep 2007, Nick Piggin wrote:
> I've also heard that string operations do not follow the normal ordering, but
> that's just with respect to individual loads/stores in the one operation, I
> hope? And they will still follow ordering rules WRT surrounding loads and
> stores?
see section
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
see section 7.2.3
On Sat, 8 Sep 2007, Petr Vandrovec wrote:
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering,
but
that's just with respect to individual loads/stores in the one operation,
I
hope
On Fri, 13 Jul 2007, greg wrote:
dean gaudet dean at arctic.org writes:
if you've got any other workload you'd like me to throw at it,
let me know.
I've had a few problems with the driver in 2.6.20 (fc6xen x86_64). The
machine
tended to lock up after a random period of time (from
it's so very unfortunate the PCI standard has no feature bit to indicate
the presence of ECS.
FWIW in my testing on a range of machines spanning 7 or 8 years i could
read config space reg 256... and get 0x when the device didn't
support ECS, and get valid data when the device did
1 - 100 of 1643 matches
Mail list logo
