headers
David Weinehall | 1 Jul 2003 01:14
Picon
Picon
Picon
Favicon

Re: Dell vs. GPL

On Sun, Jun 29, 2003 at 09:42:10PM +0100, Jamie Lokier wrote:
> Ricardo Galli wrote:
> > 3.3 In general, the author of a computer programme is the natural or
> > legal person or group of natural persons who created it. Where
> > collective works are recognized by the legislation of a Member
> > State, the person considered by the legislation of that Member State
> > to have created the work is deemed to be its author. In the case of
> > a programme created by a group of natural persons, the exclusive
> > rights are owned jointly. Where a computer programme is created by
> > an employee in the execution of his duties or following the
> > instructions given by his employer, the employer alone will be
> > entitled to exercise all economic rights in the programme, unless
> >                          ^^^^^^^^^^^^^^^
> > otherwise provided for by contract.
> >
> > Note that it only mentions "economic rights".
> 
> I was thinking of UK law.  Excerpts from the Copyright, Designs and
> Patents Act 1988:

Laws passed by the EU stands over the national laws, hence the citizens
can always appeal, and have the national laws declared void. This has
happened a few times already in other areas, afaik.

[snip]

Regards: David Weinehall
--

-- 
 /) David Weinehall <tao <at> acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
(Continue reading)

Permalink | Reply | 0 comments |
headers
Con Kolivas | 1 Jul 2003 01:44

[PATCH] O1int 0307010922 for 2.5.73 interactivity

Here is an evolution of the O1int design to minimise audio skips/smooth X. 
I've been forced to work with even less sleep than usual because of this but 
I'm getting quite happy with it now.

Changes:
Reintroduction of the child penalty set at 95, but normalised to work for a 2 
second average to work with the new system.
Long sleepers classified as idle again like previous incarnations instead of 
being reset, but over a 2 second average.

This should impact on a lot of the corner cases.

More thrashing please. I know these had been coming out frequently but I 
needed to assess every small increment. I hope not to need to do too much 
from here.

Con
Attachment (patch-O1int-0307010922): text/x-diff, 3609 bytes
Permalink | Reply | 8 comments |
headers
Con Kolivas | 1 Jul 2003 01:52

Re: [PATCH] O1int 0307010922 for 2.5.73 interactivity

On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> Here is an evolution of the O1int design to minimise audio skips/smooth X.
> I've been forced to work with even less sleep than usual because of this
> but I'm getting quite happy with it now.
>
> Changes:
> Reintroduction of the child penalty set at 95, but normalised to work for a
> 2 second average to work with the new system.
> Long sleepers classified as idle again like previous incarnations instead
> of being reset, but over a 2 second average.
>
> This should impact on a lot of the corner cases.
>
> More thrashing please. I know these had been coming out frequently but I
> needed to assess every small increment. I hope not to need to do too much
> from here.

The sleep thing is definitely affecting me.

Here is a small bugfix.
Attachment (patch-O1int-0307010949): text/x-diff, 3609 bytes
Permalink | Reply | 7 comments |
headers
Jeff Garzik | 1 Jul 2003 01:59
Picon
Favicon

ata-scsi driver update

maintenance update, nothing terribly new or exciting.  mostly error 
handling improvements and cleanups (and some bug fixes just for fun).

GNU diff, versus 2.4.21 release:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.21-atascsi1.patch.bz2

BK repos:
bk://kernel.bkbits.net/jgarzik/atascsi-2.[45]

The 2.5 repo is a bit out of date WRT the latest scsi api, but the 
ata-scsi driver itself is 100% in sync with its 2.4 counterpart.  (due 
to the large number of changes in 2.5 scsi, the 2.5 driver is a fork of 
the 2.4 driver)

detailed changes:
* add autogenerated docbook docs
* add atapi (ifdef'd out, due to lack of err handling)
* better ata probing, including better err handling during probe
* more piix pci ids.  bump up ich5 sata max speed to udma6.
* beginnings of SYNCHRONIZE CACHE support for ATA drives
* better SCSI emulation for ATA drives
* cleanups, simplifications, minor bug fixes
* a huge search-n-replace job, s/ata_host/ata_port/

A couple new host drivers coming next, along with atapi error handling...

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mel Gorman | 1 Jul 2003 02:02
Picon

Re: [BUG] 2.5.73 Scheduling while atomic with taskfile IO and high memory

On Mon, 30 Jun 2003, Zwane Mwaikambo wrote:

> Could you try selecting your specific IDE chipset (or all), it doesn't
> look like PIO is getting along famously with various other bits. I also
> noticed TCQ, do you have any TCQ capable IDE devices?
>

Tried many things, in no particular order

o PCI chipsets disabled
o Disabled TCQ (device doesn't support it anyway)
o DMA disabled and ide_setup_dma() stub function added so it'll compile
o PCI Generic chipset support enabled
o Intel PIIX chipset support enabled
o All chipset under the sun supported

All come up with the same errors. The following workarounds let it
boot

o Removing inc_preempt_count() and dec_preempt_count() from kmap_atomic()
  and kunmap_atomic()
o Disabling high memory
o Disabling taskfile IO

A quickie patch to sched.c shows that preempt_count() keeps incrementing
for each time the sleeping while atomic message is printed by the
cpu_idle() thread

--

-- 
Mel Gorman
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Salmon | 1 Jul 2003 02:25
Favicon

negative tcp_tw_count and other TIME_WAIT weirdness?


I have several fairly busy servers reporting a negative value
for tcp_tw_count.  For example:

bash-2.05a# cat /proc/net/sockstat
sockets: used 121
TCP: inuse 50 orphan 0 tw -65048 alloc 81 mem 26
UDP: inuse 15
RAW: inuse 1
FRAG: inuse 0 memory 0
bash-2.05a# 

When I look at netstat -n, I see many (hundreds) connections 
stuck in TIME_WAIT.  They've been there for at least a few hours,
and probably much longer (days).

Is this expected behavior?  A known bug?

FWIW, I'm using a RedHat kernel, 2.4.18-24.7.xsmp on a 2-processor Athlon
system.   If this looks like a bug I'll try to reproduce it with
an unmodified kernel.

Thanks,
John Salmon

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 8 comments |
headers
john stultz | 1 Jul 2003 02:25
Picon
Favicon

Re: 2.5.73-mm2 - odd audio problem, bad intel8x0/ac97 clocking.

On Sat, 2003-06-28 at 14:31, Valdis.Kletnieks <at> vt.edu wrote:
> 2.5.73-mm1 is fine.
> 
> This is *not* the "clock runs really really fas"t issue - I left -mm2 running overnight and
> in some 8 hours the system clock only drifted a few seconds versus wall clock (and it's
> possible it was off a few seconds when it booted, as it didn't get an NTP sync at boot).
> 
> Audio plays "too fast" - a 4 minute .ogg goes through in about 3:40, sounding a bit
> high-pitched in the process.

> Any ideas?

Hrmmm. Are you seeing something like:

Loosing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?)
Falling back to a sane timesource.

in your dmesg?

I just realized that in clock_fallback() from my lost-tick-speedstep-fix
we don't re-calibrate loops_per_jiffies. The conversion from cycles to
loops should be pretty close, but that might need some additional work. 

Hrmmm..
-john
Permalink | Reply | 1 comment |
headers
Mel Gorman | 1 Jul 2003 02:32
Picon

Re: [BUG] 2.5.73 Scheduling while atomic with taskfile IO and high memory

On Mon, 30 Jun 2003, Paul Larson wrote:

> This sounds similar to what I was seeing with bug #800, only I don't
> think I had taskfile IO enabled.  Another person I talked to had some
> success by enabling PIIX I think, but that did not work for me.  The
> only workaround that worked for me was to disable highmem support.

I'm pretty sure we're looking at the same bug, at least they are
remarkably similar for a co-incidence. If you have the time, it might be
worth checking if commenting out inc_preempt_count() and
dec_preempt_count() from kmap_atomic() and kunmap_atomic() masks the bug
for you. It's not a workaround but it might help narrow down where things
are going wrong

--

-- 
Mel Gorman
MSc Student, University of Limerick
http://www.csn.ul.ie/~mel
Permalink | Reply | 0 comments |
headers
William Lee Irwin III | 1 Jul 2003 02:39

Re: 2.5.73-mm2

On Fri, Jun 27, 2003 at 08:21:30PM -0700, Andrew Morton wrote:
> Just bits and pieces.

It was suggested during my last round of OOM killer fixes that one of
my patches, which just checked nr_free_buffer_pages() > 0, should also
consider userspace (i.e. reclaimable at will) memory free.

This patch implements that suggestion. Lightly tested, and expected to
fall within the "relatively trivial" category.

We're still not out of hot water here yet, since the minimum thresholds
will still send all processes into perpetual torpor under persistent
low memory conditions while fooling the OOM heuristics. But this is at
least better than complete ignorance of ZONE_NORMAL exhaustion.

-- wli

diff -prauN wli-2.5.73-31/include/linux/mm.h wli-2.5.73-32/include/linux/mm.h
--- wli-2.5.73-31/include/linux/mm.h	2003-06-29 01:39:42.000000000 -0700
+++ wli-2.5.73-32/include/linux/mm.h	2003-06-30 16:42:28.000000000 -0700
 <at>  <at>  -605,7 +605,8  <at>  <at>  static inline struct vm_area_struct * fi

 extern struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr);

-extern unsigned int nr_used_zone_pages(void);
+unsigned int nr_used_low_pages(void);
+unsigned int nr_used_zone_pages(void);

 extern struct page * vmalloc_to_page(void *addr);
 extern struct page * follow_page(struct mm_struct *mm, unsigned long address,
(Continue reading)

Permalink | Reply | 14 comments |
headers
Valdis.Kletnieks | 1 Jul 2003 02:41
Picon
Favicon

Re: 2.5.73-mm2 - odd audio problem, bad intel8x0/ac97 clocking.

On Mon, 30 Jun 2003 17:25:48 PDT, john stultz said:
> On Sat, 2003-06-28 at 14:31, Valdis.Kletnieks <at> vt.edu wrote:
> > 2.5.73-mm1 is fine.
> > 
> > This is *not* the "clock runs really really fas"t issue - I left -mm2 runni
ng overnight and
> > in some 8 hours the system clock only drifted a few seconds versus wall clo
ck (and it's
> > possible it was off a few seconds when it booted, as it didn't get an NTP s
ync at boot).
> > 
> > Audio plays "too fast" - a 4 minute .ogg goes through in about 3:40, soundi
ng a bit
> > high-pitched in the process.
> 
> > Any ideas?
> 
> Hrmmm. Are you seeing something like:
> 
> Loosing too many ticks!
> TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> Falling back to a sane timesource.

Nope, it's a pretty clear bug in the Speedstep code leaving loops_per_jiffies bogus.

I posted a follow-up note explaining in more detail...
Permalink | Reply | 0 comments |

Gmane