headers
Jean-Yves Migeon | 1 Oct 2010 02:35
Picon
Favicon

PAE support for kvm(3)

Hi list,

Attached is the patch required to add PAE support in kvm(3). Except for
one "major" nit (see below), it seems to be functional: I can sync a
kernel, with or without PAE enabled, and all libkvm binaries (vmstat(1),
netstat(1), ...) still work on the core files.

I am facing an interesting limitation there: some weeks ago, I added a
symbol, i386_use_pae. This variable is also exposed through a sysctl(7):
"machdep.pae".

Goal was to easily provide an indication whether a kernel is currently
using PAE mode or not, and also query its value through kvm_nlist(3) (to
select the proper kvatop function, depending on the mode).

However, I have some kind of "chicken-egg" situation there: getting
i386_use_pae value needs a go through KREAD/kvm_read, but these
functions cannot work properly until the correct kvatop function has
been selected. Downside is, this depends on i386_use_pae value...

At this late hour, I cannot think of a quick and clean solution. Adding
an element to the cpu_kcore_hdr_t will break all core dumps from before
the change (the offset of the memory segments, "memsegs", will differ);
that would need compat code to cope with that. Another possibility is to
set the last bit in pdppaddr to indicate PAE activation, but, this seems
like a dirty hack (I don't think that PDPpaddr will ever go that high
though).

Any advice for that one? Thanks in advance!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian Buhrow | 1 Oct 2010 04:03

Re: Fixes for kern/40018 -- any chance of getting these pulled into the -current and 5.x trees?

	Hello.   Just wondering if anyone else has had a chance to test these
patches.  I've now been runing quite a bit of hardware in production for
over 2 weeks and no issues at all.
	If folks are generally comfortable with these patches, could someone
commit them?  Or, perhaps, someone would be willing to work with me to give
me commit privileges?
-thanks
-Brian
On Sep 27, 10:36am, Sverre Froyen wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Mon September 27 2010 10:18:48 Brian Buhrow wrote:
} > 	Hello Sverre.  While doing your testing, also watch the output of
} > netstat -s.  Specifically, We're interested to see if you see a large
} > number of packets dropped due to checksum failures.  The patch I provided
} > affects tcp and udp packets.  Look for output similar to the following:
} 
} I'm not. It looks perfectly clean:
} 
} tcp:
} 	...
}         9268392 packets received
}                 7726606 acks (for 15646193744 bytes)
}                 0 duplicate acks
}                 0 acks for unsent data
}                 1611760 packets (2242462516 bytes) received in-sequence
}                 1454 completely duplicate packets (232 bytes)
}                 0 old duplicate packets
}                 0 packets with some dup. data (0 bytes duped)
}                 1555 out-of-order packets (0 bytes)
}                 0 packets (0 bytes) of data after window
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jean-Yves Migeon | 1 Oct 2010 10:19
Picon
Favicon

Re: PAE support for kvm(3)


On Fri, 01 Oct 2010 02:35:22 +0200, Jean-Yves Migeon
<jeanyves.migeon <at> free.fr> wrote:
> Hi list,
> 
> Attached is the patch required to add PAE support in kvm(3). Except for
> one "major" nit (see below), it seems to be functional: I can sync a
> kernel, with or without PAE enabled, and all libkvm binaries (vmstat(1),
> netstat(1), ...) still work on the core files.
> [snip]
> However, I have some kind of "chicken-egg" situation there: getting
> i386_use_pae value needs a go through KREAD/kvm_read, but these
> functions cannot work properly until the correct kvatop function has
> been selected. Downside is, this depends on i386_use_pae value...
> 
> At this late hour, I cannot think of a quick and clean solution. Adding
> an element to the cpu_kcore_hdr_t will break all core dumps from before
> the change (the offset of the memory segments, "memsegs", will differ);
> that would need compat code to cope with that. Another possibility is to
> set the last bit in pdppaddr to indicate PAE activation, but, this seems
> like a dirty hack (I don't think that PDPpaddr will ever go that high
> though).
> 
> Any advice for that one? Thanks in advance!

Replying to myself:

Having some sleep seems to help: as the pdppaddr is at least 32 bits
aligned (least common multiple between PAE and !PAE),
that gives me some bits accessible which are not used by the translation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Doran | 1 Oct 2010 11:15
Picon

Re: PAE support for kvm(3)

On Fri, Oct 01, 2010 at 02:35:22AM +0200, Jean-Yves Migeon wrote:

> Attached is the patch required to add PAE support in kvm(3). Except for
> one "major" nit (see below), it seems to be functional: I can sync a
> kernel, with or without PAE enabled, and all libkvm binaries (vmstat(1),
> netstat(1), ...) still work on the core files.
> 
> I am facing an interesting limitation there: some weeks ago, I added a
> symbol, i386_use_pae. This variable is also exposed through a sysctl(7):
> "machdep.pae".
> 
> Goal was to easily provide an indication whether a kernel is currently
> using PAE mode or not, and also query its value through kvm_nlist(3) (to
> select the proper kvatop function, depending on the mode).
> 
> However, I have some kind of "chicken-egg" situation there: getting
> i386_use_pae value needs a go through KREAD/kvm_read, but these
> functions cannot work properly until the correct kvatop function has
> been selected. Downside is, this depends on i386_use_pae value...
> 
> At this late hour, I cannot think of a quick and clean solution. Adding
> an element to the cpu_kcore_hdr_t will break all core dumps from before
> the change (the offset of the memory segments, "memsegs", will differ);
> that would need compat code to cope with that. Another possibility is to
> set the last bit in pdppaddr to indicate PAE activation, but, this seems
> like a dirty hack (I don't think that PDPpaddr will ever go that high
> though).
> 
> Any advice for that one? Thanks in advance!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lourival Vieira Neto | 5 Oct 2010 23:24
Picon

[ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)

Hi folks,

I'm glad to announce the results of my GSoC project this year [1].
We've created the support for scripting the NetBSD kernel with Lua,
which we called Lunatik and it is composed by a port of the Lua
interpreter to the kernel, a kernel programming interface for
extending subsystems and a user-space interface for loading user
scripts into the kernel. You can see more details on [2]. I am
currently working on the improvement of its implementation, on the
documentation and on the integration between Lunatik and other
subsystems, such as npf(9), to provide a real usage scenario.

I'd like to take this space also to publicly thank Marc Balmer, for
his kind support; prof. Roberto Ierusalimschy, for his comprehension
and support; and NetBSD developers for their prompt help.

[1] http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748
[2] http://netbsd-soc.sourceforge.net/projects/luakern/

Cheers,
--
Lourival Vieira Neto
Permalink | Reply | 39 comments |
headers
KAMADA Ken'ichi | 5 Oct 2010 23:23

Re: panic: ffs_valloc: dup alloc

At Fri, 19 Mar 2010 17:51:46 -0500, myself wrote:
> 
> I'm seeing a panic: ffs_valloc: dup alloc.
> Does anyone have a similar panic?
> 
> The kernel is -current from March 15.
> I cannot repeat the panic reliably, but it seems to occur after
> suspend/resume (immediately or several minutes later).
> The panic occured in /home, which is a ffs on cgd on wd.
> "fsck -f" does not report any error on it.

I finally found a clue for this problem.
With the attached patch [1], my system seems to be stable again.
With the patch, I see "channel reset" [2] on resume.
Without the patch (i.e., unmodified -current), I see
a lot of "cgd0: error 5" messages [3] instead.

It seems to me that cgd is just passing EIO around, so I suspect that
errors are not correctly handled somewhere in FFS...

[1]
Index: sys/dev/ata/wd.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ata/wd.c,v
retrieving revision 1.384
diff -u -r1.384 wd.c
--- sys/dev/ata/wd.c	24 Feb 2010 22:37:57 -0000	1.384
+++ sys/dev/ata/wd.c	5 Oct 2010 20:46:04 -0000
 <at>  <at>  -489,9 +489,9  <at>  <at> 
 	}
(Continue reading)

Permalink | Reply | 5 comments |
headers
jean-Yves Migeon | 6 Oct 2010 11:23
Picon

Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project


On Tue, 5 Oct 2010 18:24:48 -0300, Lourival Vieira Neto
<lourival.neto <at> gmail.com> wrote:
> I'm glad to announce the results of my GSoC project this year [1].
> We've created the support for scripting the NetBSD kernel with Lua,
> which we called Lunatik and it is composed by a port of the Lua
> interpreter to the kernel, a kernel programming interface for
> extending subsystems and a user-space interface for loading user
> scripts into the kernel. You can see more details on [2]. I am
> currently working on the improvement of its implementation, on the
> documentation and on the integration between Lunatik and other
> subsystems, such as npf(9), to provide a real usage scenario.
> 
> I'd like to take this space also to publicly thank Marc Balmer, for
> his kind support; prof. Roberto Ierusalimschy, for his comprehension
> and support; and NetBSD developers for their prompt help.
> 
> [1]
>
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748
> [2] http://netbsd-soc.sourceforge.net/projects/luakern/
> 
> Cheers,

Heh, impressive :) Who would have imagined that NetBSD could end up with a
"scripting" language inside kernel :o

Is there any sort of "limitation" between the "in-kernel" and a "userland"
lua, when you adapted it to kernel's limited API?
(Continue reading)

Permalink | Reply | 25 comments |
headers
Martin Husemann | 6 Oct 2010 17:04
Picon

Re: Fixes for kern/40018 -- any chance of getting these pulled into the -current and 5.x trees?

I'm testing the patch in -current with these hardware:

bge0 at pci2 dev 0 function 0: Broadcom BCM57780 Fast Ethernet
bge0: interrupting at ioapic0 pin 16
adjust device control 0x192000 -> 0x195000
bge0: ASIC BCM57780 A1 (0x57780001), Ethernet address 00:26:2d:90:46:d1
bge0: setting short Tx thresholds
ukphy0 at bge0 phy 1: OUI 0x001be9, model 0x0019, rev. 1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

and:

bge0 at pci0 dev 2 function 0: Broadcom BCM5704C Dual Gigabit Ethernet
bge0: interrupting at ivec 37c8
bge0: ASIC BCM5704 A3 (0x2003), Ethernet address 00:03:ba:45:d5:ed
brgphy0 at bge0 phy 1: BCM5704 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

I found no problems so far.

Martin
Permalink | Reply | 1 comment |
headers
Matthias Kretschmer | 6 Oct 2010 18:17
Picon
Favicon

Realtek 8110SC

Hello,

according to re(4) the re? driver supports the 8169 realtek family of
network adapters including the 8110S network chip.  I'm wondering if the
8110SC is different from 8110S?  Is the 8110SC supported by NetBSD?

--
Matthias Kretschmer
Permalink | Reply | 1 comment |
headers
Lourival Vieira Neto | 6 Oct 2010 22:48
Picon

Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project

On Wed, Oct 6, 2010 at 6:23 AM, jean-Yves Migeon <jym <at> netbsd.org> wrote:
>
> On Tue, 5 Oct 2010 18:24:48 -0300, Lourival Vieira Neto
> <lourival.neto <at> gmail.com> wrote:
>> I'm glad to announce the results of my GSoC project this year [1].
>> We've created the support for scripting the NetBSD kernel with Lua,
>> which we called Lunatik and it is composed by a port of the Lua
>> interpreter to the kernel, a kernel programming interface for
>> extending subsystems and a user-space interface for loading user
>> scripts into the kernel. You can see more details on [2]. I am
>> currently working on the improvement of its implementation, on the
>> documentation and on the integration between Lunatik and other
>> subsystems, such as npf(9), to provide a real usage scenario.
>>
>> I'd like to take this space also to publicly thank Marc Balmer, for
>> his kind support; prof. Roberto Ierusalimschy, for his comprehension
>> and support; and NetBSD developers for their prompt help.
>>
>> [1]
>>
> http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748
>> [2] http://netbsd-soc.sourceforge.net/projects/luakern/
>>
>> Cheers,
>
> Heh, impressive :) Who would have imagined that NetBSD could end up with a
> "scripting" language inside kernel :o

=D
(Continue reading)

Permalink | Reply | 24 comments |

Gmane