Christoph Egger | 3 Jan 15:27 2012
Picon
Picon

Re: RFC: cpu microcode loading support

On 12/16/11 17:57, Christoph Egger wrote:
> On 12/16/11 17:12, Thor Lancelot Simon wrote:
>> On Fri, Dec 16, 2011 at 04:17:50PM +0100, Christoph Egger wrote:
>>> On 12/15/11 18:43, Christoph Egger wrote:
>>>
>>> kauth(9) is implemented as requested from tls <at>  and also
>>> uses xc_broadcast(9) to automatically apply the ucode patch on all cpus.
>>
>> Thanks!
>>
>> Maybe I am missing this by looking at the patch out of context, but it
>> looks like we're allowing microcode update if "isroot" without reference
>> to securelevel. It seems to me this operation should be allowed only at
>> securelevel< 1. Am I misreading this or is an additional check required?
>
> New version attached. Added securelevel check and manpage update.

New version attached. Changes:

- feedback from wiz <at>  regarding cpuctl.8
- feedback from jym <at> :

   * Changed ENOTSUP to EOPNOTSUPP
   * Changed __HAVE_CPU_MICROCODE into a kernel config option CPU_UCODE
   * Moved cpu_ucode_load() into sys/kern_cpu.c

Please review.

Christoph
(Continue reading)

Christoph Egger | 9 Jan 11:06 2012
Picon
Picon

Re: RFC: cpu microcode loading support

On 01/03/12 15:27, Christoph Egger wrote:
> On 12/16/11 17:57, Christoph Egger wrote:
>> On 12/16/11 17:12, Thor Lancelot Simon wrote:
>>> On Fri, Dec 16, 2011 at 04:17:50PM +0100, Christoph Egger wrote:
>>>> On 12/15/11 18:43, Christoph Egger wrote:
>>>>
>>>> kauth(9) is implemented as requested from tls <at>  and also
>>>> uses xc_broadcast(9) to automatically apply the ucode patch on all
>>>> cpus.
>>>
>>> Thanks!
>>>
>>> Maybe I am missing this by looking at the patch out of context, but it
>>> looks like we're allowing microcode update if "isroot" without reference
>>> to securelevel. It seems to me this operation should be allowed only at
>>> securelevel< 1. Am I misreading this or is an additional check required?
>>
>> New version attached. Added securelevel check and manpage update.
>
> New version attached. Changes:
>
> - feedback from wiz <at>  regarding cpuctl.8
> - feedback from jym <at> :
>
> * Changed ENOTSUP to EOPNOTSUPP
> * Changed __HAVE_CPU_MICROCODE into a kernel config option CPU_UCODE
> * Moved cpu_ucode_load() into sys/kern_cpu.c
>
> Please review.

(Continue reading)

Andrew Smallshaw | 9 Jan 18:10 2012
Picon

Determining USB product ID

What's the easiest way to determine the USB product ID for an
unregnised device?  On attachment ugen reports the VID but not the
PID.  The device in question is is an RTL8150 based ethernet
interface so I'm hoping that I only need to add appropriate entries
to the VID and PID lists and tweak the url source to recognise it.

--

-- 
Andrew Smallshaw
andrews <at> sdf.lonestar.org

Matthias Drochner | 9 Jan 18:15 2012
Picon
Picon

Re: Determining USB product ID


andrews <at> sdf.lonestar.org said:
> What's the easiest way to determine the USB product ID

usbdevs -v

best regards
Matthias

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Kennen Sie schon unsere app? http://www.fz-juelich.de/app

Patrick Welche | 12 Jan 15:54 2012
Picon
Picon

Flakey AMD box

I am trying to get to the bottom of why one of my i386 boxen is very
unreliable. It is my only 32 bit AMD CPU machine.

Symptoms are:
On boot, sometimes all is well, sometimes I get a panic - usually in uiomove
(mode=READ), then reboot, panic, reboot, all well.

This is nasty: files which are built correctly into /usr/obj are then
corrupt when installed. Several times fate rolled a double 6 and
/usr/obj/lib/libc.i386/libc.so.12.179 was fine, but
/lib/libc.so.12.179 was a file with the same name, length, timestamp, but
containing "data" rather than a shared object. (Last round it happened
to both libc and libgcc_s which was fun.)
It isn't just those files, though it is immediately obvious when it
happens to them. (Happened again with yesterday's -current)

I thought it must be flakey hardware, but I have now replaced the
disks with a known working pair of IDE raidframe mirrored disks
plugged into hptide.  They (disks and controller card) come out of
a NetBSD/i386 server that has been rock solid for years.

I also changed the Sempron 2200+ and 512MB DDR400 memory, to a
?Athlon XP 3000+? (from memory) and 3x512MB DDR333 memory.  Two
iterations of memtest86 4.0a were happy. The motherboard is an ASUS
A7V600-X, so VIA chipset (eg VT8377).

Same flakiness - all I didn't change are the motherboard and power supply,
and a sata drive is still connected but not mounted anywhere special.

During builds, with that much memory, /usr/obj/* must be in the
(Continue reading)

Thomas Klausner | 15 Jan 23:31 2012
Picon

PR 45814: changing x86/lock.h

Any opinions on the suggested change here?
(I'm not subscribed to port-i386, please cc me)
 Thomas

----- Forwarded message from noud4 <at> home.nl -----

Date: Tue, 10 Jan 2012 19:00:00 +0000 (UTC)
From: noud4 <at> home.nl
To: pkg-manager <at> netbsd.org, gnats-admin <at> netbsd.org, pkgsrc-bugs <at> netbsd.org
Subject: pkg/45814: lang/gcc45 doesn't build on 5.99.5x/i386

>Number:         45814
>Category:       pkg
>Synopsis:       lang/gcc45 doesn't build on 5.99.5x/i386
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 10 19:00:00 +0000 2012
>Originator:     B.ICT A.P. deBROUWER Jr.
>Release:        5.99.59
>Organization:
-none-
>Environment:
NetBSD 10.0.2.17 5.99.59 NetBSD 5.99.59 (MONOLITHIC) #0: Tue Dec 27 01:19:12 UTC 2011 
builds <at> b8.netbsd.org:/home/builds/ab/HEAD/i386/201112261820Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/MONOLITHIC i386
>Description:
(Continue reading)

Joerg Sonnenberger | 16 Jan 00:09 2012
Picon

Re: PR 45814: changing x86/lock.h

On Sun, Jan 15, 2012 at 11:31:05PM +0100, Thomas Klausner wrote:
> Any opinions on the suggested change here?

That file shouldn't be included by userland code in first place. So I'm
kind of opposed to any changes until it is understood where and why that
is needed.

Joerg

Greg A. Woods | 16 Jan 07:08 2012
X-Face
Picon

ongoing major problems with NetBSD-5 and LOCKDEBUG on multi-core system

So I was finally able to get a new server, and its a nice big Dell
PE2950 with 32GB RAM, lots-o-disk on a PERC-6/i, and a pair of zippy
Intel Xeon E5440 CPUs (quad-cores x2).

It's the first real hardware I've tried to do anything serious with
netbsd-5 on -- previously I'd only run netbsd-5 in VirtualBox (though
with two CPUs, on my iMac).

Everything looked OK during initial install of NetBSD-5, but during the
first real load test (build.sh -j 4) it crashed:  PR# 45827.

I've since seen this a bunch more times.  The machine is basically
useless because it seems to crash almost immediately under any decent
load.

Most recently I've been trying to use it to run sysinst to install to a
CF card that's connected via a USB reader.  The first attempt ended in
the middle of unpacking the man.tgz set with a similar crash to PR#
45827, and the second attempt ended in the middle of comp.tgz with:

panic: WARNING: SPL NOT LOWERED ON SYSCALL EXIT
LOCKDEBUGWARNING: SPL NOT LOWERED ON SYSCALL EXIT

WARNING: SPL NOT LOWERED ON TRAP EXIT
fatal breakpoint trapWARNING: SPL NOT LOWERED ON TRAP EXIT
 in supervisor mode
WARNING: SPL NOT LOWERED ON SYSCALL EXIT
trap type 1 code 0 eip c05cc4ac cs 8 eflags 246 cr2 bbb90000 ilevel 0
Stopped in pid 2751.1 (systat) at       netbsd:breakpoint+0x4:  popl    %ebp
db{4}> trace
(Continue reading)

Gary Duzan | 16 Jan 13:55 2012

Re: ongoing major problems with NetBSD-5 and LOCKDEBUG on multi-core system

In Message <m1RmfkI-001ECGC <at> once.weird.com>,
   "Greg A. Woods" <woods <at> planix.ca>wrote:

=>So, I've been wondering, is anyone else running netbsd-5 on a many-core
=>system with a LOCKDEBUG + DIAGNOSTICS + DEBUG kernel?

   It has been a while, but as of a few years ago LOCKDEBUG simply
was incompatible with multiprocessor systems. I don't recall seeing
anything explicit to indicate that it was working again, so I would
hesitate to attempt it again.

					Gary Duzan

Thor Lancelot Simon | 16 Jan 15:49 2012
Picon

Re: ongoing major problems with NetBSD-5 and LOCKDEBUG on multi-core system

On Mon, Jan 16, 2012 at 07:55:21AM -0500, Gary Duzan wrote:
> 
>    It has been a while, but as of a few years ago LOCKDEBUG simply
> was incompatible with multiprocessor systems. I don't recall seeing
> anything explicit to indicate that it was working again, so I would
> hesitate to attempt it again.

Uh, no.

Thor


Gmane