headers
Alan Cox | 25 Nov 01:13
Picon

Re: [patch] SMP alternatives

On Gwe, 2005-11-25 at 00:35 +0100, Andi Kleen wrote:
> to BIOS vendors. Perhaps a generic "BIOS writers guide for Linux"
> would be a good thing.  I have at least one other extension I would like
> BIOS vendors to support. Just would need to come up with a writeup
> for a clearly defined specification.

I wrote one for 2.2 era but it never got updated. I've probably still
got it around somewhere.
Permalink | Reply | 0 comments |
headers
Piotr Majka | 25 Nov 01:09
Picon

PROBLEM: bind-9.3.1 doesnt work with 2.6.14


After run named on 2.6.14 (I try 2.6.14-rcX too) I got in logfile:

Nov 10 18:24:57 xxx named[1845]: errno2result.c:109: unexpected error:
Nov 10 18:24:57 xxx named[1845]: unable to convert errno to isc_result: 
14: Bad address
Nov 10 18:24:57 xxx named[1845]: UDP client handler shutting down due to 
fatal receive error: unexpected error

and named dont respond to the query. I switch back to 2.6.13.2 - all 
work fine. Once again run 2.6.14 - the same error after few minutes of 
working.

# sh /home/linux-2.6.14/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux xxx 2.6.13.2-grsec #1 Sat Sep 24 18:30:11 CEST 2005 i686 
i686 i386 GNU/Linux

Gnu C                  4.0.1
Gnu make               3.80
binutils               2.16.91.0.2
util-linux             2.12p
mount                  2.12p
module-init-tools      3.1
e2fsprogs              1.38
reiserfsprogs          line
reiser4progs           line
nfs-utils              1.0.7
(Continue reading)

Permalink | Reply | 1 comment |
headers
Con Kolivas | 25 Nov 01:16

Re: PROBLEM: bind-9.3.1 doesnt work with 2.6.14

On Fri, 25 Nov 2005 11:09, Piotr Majka wrote:
> After run named on 2.6.14 (I try 2.6.14-rcX too) I got in logfile:
>
> Nov 10 18:24:57 xxx named[1845]: errno2result.c:109: unexpected error:
> Nov 10 18:24:57 xxx named[1845]: unable to convert errno to isc_result:
> 14: Bad address
> Nov 10 18:24:57 xxx named[1845]: UDP client handler shutting down due to
> fatal receive error: unexpected error
>
> and named dont respond to the query. I switch back to 2.6.13.2 - all
> work fine. Once again run 2.6.14 - the same error after few minutes of
> working.

Known problem, fixed in 2.6.14.2 onwards.

Cheers,
Con
Permalink | Reply | 0 comments |
headers
Alessandro Suardi | 25 Nov 01:20
Picon

2.6.15-rc2-git4 on Dell D610 - PCI resource allocation failure

Another one from the new Latitude D610... both the latest FC4
 kernel and 2.6.15-rc2-git4 fail to allocate PCI resources - not
 sure whether FC4 also gets the "Ignore bogus resource" one
 which is here taken from the 2.6.15-rc2-git4 dmesg ring:

[17179572.144000] PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
[17179572.144000] PCI: Failed to allocate I/O resource #7:1000 <at> 10000
for 0000:00:1e.0

[root <at> sandman ~]# lspci -v
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 03)
        Subsystem: Dell: Unknown device 0182
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation Mobile
915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00
[VGA])        Subsystem: Dell: Unknown device 0182
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at dff00000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at ec38 [size=8]
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at dfec0000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [d0] Power Management version 2

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 03)
        Subsystem: Dell: Unknown device 0182
        Flags: bus master, fast devsel, latency 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roman Zippel | 25 Nov 02:08

Re: RFC: Kill -ERESTART_RESTARTBLOCK.

Hi,

On Thu, 24 Nov 2005, David Woodhouse wrote:

> I'm looking at implementing ppoll() and pselect(), and the existing
> restartblock stuff isn't sufficient for that -- we don't get to store
> enough args, and although it could possibly be expanded, I just don't
> much like restarting syscalls that way.

What arguments do you need to store?
Instead of messing with the signal delivery it may be better to slightly 
change the restart logic. Instead of calling a separate function, we could 
call the original function with all the arguments, which would reduce the 
state required to be saved.
In the case of nanosleep this could look like this:

sys_nanosleep()
{
	...
	if (restart_block) {
		expire = restart_block->arg0;
	} else {
		if (copy_from_user(&t, rqtp, sizeof(t)))
		...
	}
	expire = schedule_timeout_interruptible(expire);
	if (expire) {
		...
		restart_block->arg0 = expire;
		ret = -ERESTART_RESTARTBLOCK;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Woithe | 25 Nov 02:15
Picon
Picon

2.6.14-rt13: high res timer problem?

Hi guys

I noticed an odd problem with 2.6.14-rt13 this past week.  If the new-ish
high resolution timer is enabled (not HPET), sleeps take far too long.
For example, "sleep 1" from bash actually delays 38 seconds, not 1 second
as expected.  I've also noticed that the clock on the computer seems to
run slow, but I haven't looked into that in any detail yet.

At the present moment I am running Ingo's rt13 patch with 2.6.14.  I have
not yet had a chance to test an unpatched 2.6.14 - I will try to get to
that soon.  I've also got 2.6.14-rt15 now and I'll test that too.

This is on a Centrino laptop with an i915 chipset.  I can confirm that the
effect persists irrespective of whether any or all of the APIC options are
selected.  The presence or absence of various timer-related options
(ktimers, HPET, PM timer) also don't appear to make any difference.

Please CC replies to me to ensure I see them.  Thanks.

Regards
  jonathan
Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 25 Nov 02:33
Favicon

Re: [patch] SMP alternatives

Andi Kleen wrote:
> 
> IMHO it's time that Linux gets more proactive regarding talking
> to BIOS vendors. Perhaps a generic "BIOS writers guide for Linux"
> would be a good thing.  I have at least one other extension I would like
> BIOS vendors to support. Just would need to come up with a writeup
> for a clearly defined specification.
> 

BIOS, and hardware.  I think Alan wrote something up way long ago, but 
it hasn't really been updated.

	-hpa
Permalink | Reply | 0 comments |
headers
Roman Zippel | 25 Nov 02:48

Re: [PATCH] make miniconfig (take 2)

Hi,

On Thu, 24 Nov 2005, Rob Landley wrote:

> > On Mon, 21 Nov 2005, Rob Landley wrote:
> > > Add "make miniconfig", plus documentation, plus the script that creates a
> > > minimal mini.config from a normal .config file.
> >
> > The difference between miniconfig and allnoconfig is IMO too small to be
> > really worth it right now.
> 
> I disagree, fairly strongly.  The technical difference may be small, but the 
> conceptual difference is huge.

I don't really disagree, a proper implementation of the concept would also 
be technically quite different. Hacking it into conf.c is the wrong to go 
(or to even start).

> > which is only read by kconfig.
> 
> So it would be different from the format of the busybox .config file, the 
> uClibc .config file, or anybody else out there who's adopted the kernel's 
> format over the past decade-plus?

Did I say it would go away? No.
It actually makes quite some sense to separate the .config used by kbuild 
from the config used by kconfig.
.config isn't always correctly reread after a manual edit. The syntax 
rules needed by kbuild are more strict than needed for kconfig. The "is 
not set" syntax is not exactly user friendly and all the derived symbols
(Continue reading)

Permalink | Reply | 9 comments |
headers
Hirokazu Takata | 25 Nov 02:57
Favicon

[PATCH 2.6.15-rc2] m32r: Fix sys_tas() syscall

Hello,

This patch fixes a deadlock problem of the m32r SMP kernel.

In the m32r kernel, sys_tas() system call is provided as a test-and-set
function for userspace, for backward compatibility.  

In some multi-threading application program, deadlocks were rarely caused
at sys_tas() funcion.
Such a deadlock was caused due to a collision of __pthread_lock() and
__pthread_unlock() operations.

The "tas" syscall is repeatedly called by pthread_mutex_lock() to get
a lock, while a lock variable's value is not 0. 
On the other hand, pthead_mutex_unlock() sets the lock variable to 0
for unlocking.

In the previous implementation of sys_tas() routine, there was a possibility
that a unlock operation was ignored in the following case:

- Assume a lock variable (*addr) was equal to 1 before sys_tas() execution.
- __pthread_unlock() operation is executed by the other processor
  and the lock variable (*addr) is set to 0, between a read operation
  ("oldval = *addr;") and the following write operation ("*addr = 1;")
  during a execution of sys_tas().

In this case, the following write operation ("*addr = 1;") overwrites
the __pthread_unlock() result, and sys_tas() fails to get a lock in the
next turn and after that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Scott Kasten | 25 Nov 03:04
Picon
Favicon

Re: [OT] 1500 days uptime.


Impressive indeed.  I had a SPARC LX running Red Hat 6.1 or 6.2 I think it 
was, stripped down for a web server and I got 585 days out of it before I 
had to pull the plug to relocate it.  It weathered NIMBDA, an FTP exploit 
and numberous other things for nearly 2 years.

-Scott-

On Thu, 24 Nov 2005, Nick Warne wrote:

> Date: Thu, 24 Nov 2005 21:47:45 +0000
> From: Nick Warne <nick <at> linicks.net>
> To: linux-kernel <at> vger.kernel.org
> Subject: [OT] 1500 days uptime.
> 
> Hi all,
>
> BrrrrrrrrrrrrBrrrr
>
> That was me blowing my own trumpet again :-)
>
> Re:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0651.html
>
> Now just hit 1500 days:
>
> -
> [nick <at> 486Linux nick]$ last -xf /var/run/utmp runlevel
> runlevel (to lvl 3)                    Sun Oct 14 16:07 - 21:41 (1502+06:34)
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane