On Wed, Jun 15, 2011 at 09:41:28AM +0400, Sergey Kandaurov wrote:
> On 15 June 2011 06:20, David Xu wrote:
> > On 2011/06/14 20:02, Sergey Kandaurov wrote:
> >> On 1 November 2010 03:42, David Xu wrote:
> >>> Author: davidxu
> >>> Date: Mon Nov 1 00:42:25 2010
> >>> New Revision: 214611
> >>> UR
On 2011/06/15 15:39, Kostik Belousov wrote:
> This patch accomodates the userland to the changed ABI. Why it was
> changed at all ? I would argue that keeping the stable ABI there is
> more important then using a 'clean' type.
>
> At least, the stable branches usermode is broken on the current ke
On Wed, Jun 15, 2011 at 04:08:34PM +0800, David Xu wrote:
> On 2011/06/15 15:39, Kostik Belousov wrote:
>
> > This patch accomodates the userland to the changed ABI. Why it was
> > changed at all ? I would argue that keeping the stable ABI there is
> > more important then using a 'clean' type.
> >
Dear all,
I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso
Today I wanted to cvsup to a later date to upgrade to ZFS v28
and compiled port /usr/ports/net/cvsup-without-gui without p
W dniu 2011-06-15 14:23, Holger Kipp pisze:
Dear all,
I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso
Today I wanted to cvsup to a later date to upgrade to ZFS v28
and compiled p
W dniu 2011-06-15 14:23, Holger Kipp pisze:
Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup
once again (seems cvsup only gives "Illegal Instruction" when a file needs to
be changed...).
Any ideas?
Whoops, I read your message too fast, apologize. Please
On 6/15/11 8:23 AM, Holger Kipp wrote:
Dear all,
I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso
Today I wanted to cvsup to a later date to upgrade to ZFS v28
and compiled por
On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote:
> On 6/15/11 8:23 AM, Holger Kipp wrote:
> >Dear all,
> >
> >I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
> >ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso
> >
>
On 6/15/11 10:46 AM, Holger Kipp wrote:
Ah, ok.
Do we have a compiler switch to force stack alignment to 16-Byte-boundaries?
Otherwise I am really concerned that we might have similar wrong pieces of code
lurking unnoticed in other binaries as well :-/
My cvsup binary is:
# file /usr/local/b
Ah, ok.
Do we have a compiler switch to force stack alignment to 16-Byte-boundaries?
Otherwise I am really concerned that we might have similar wrong pieces of code
lurking unnoticed in other binaries as well :-/
My cvsup binary is:
# file /usr/local/bin/cvsup
/usr/local/bin/cvsup: ELF 64-bit
On Tue, Jun 14, 2011 at 11:34:34AM -0400, John Baldwin wrote:
> On Tuesday, June 14, 2011 10:44:18 am Alexey Shuvaev wrote:
> > On Fri, Jun 10, 2011 at 03:11:02PM -0400, John Baldwin wrote:
> > > On Monday, May 23, 2011 10:39:02 am John Baldwin wrote:
> > > > This small patch makes the puc(4) bus d
You could try using the standard header - that has inline
functions which should cover all the SSE instructions.
On 12 June 2011 17:43, Hartmann, O. wrote:
> I use some numerical code utilizing the SIMD units of modern X86
> architectures. Code compiles well using gcc/gcc46,
> but clang does no
> > The problem I noticed first is that it takes unusually long until a
> > key press is repeated. With the default eventtimer (HPET) it seems
> > to take about 4s, which can be slightly improved by switching to
> > i8254.
> >
> > The "error beep" seems to take longer than usual, too,
> > and the s
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > The problem I noticed first is that it takes unusually long
> > > until a key press is repeated. With the default eventtimer
> > > (HPET) it seems to take about 4s, which can be slightly
> > > improved by switching to i8254.
> > >
> > >
If this was to be extended with cached global syscall information like
gettimeofday, would we want that to be in a separate page that is marked
non-executable? Is there any way to trick the kernel into leaking arbitrary
(and thus executable) code? Also, would it matter for jails? Per-process
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > The problem I noticed first is that it takes unusually long
> > > > until a key press is repeated. With the default eventtimer
> > > > (HPET) it seems to take about 4s, which ca
On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
> On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > > The problem I noticed first is that it takes unusually long
> > > > > until a key press is repeated. With the defaul
TB --- 2011-06-16 00:06:25 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 00:06:25 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2011-06-16 00:06:25 - cleaning the object tree
TB --- 2011-06-16 00:06:39 - cvsupping the source tree
TB --- 2011-06-16 00:06:39 - /usr
If this was to be extended with cached global syscall information like
gettimeofday, would we want that to be in a separate page that is marked
non-executable? Is there any way to trick the kernel into leaking arbitrary
(and thus executable) code? Also, would it matter for jails? Per-process
On 6/15/11 10:58 AM, Kostik Belousov wrote:
On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote:
On 6/15/11 8:23 AM, Holger Kipp wrote:
Dear all,
I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CUR
On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote:
>> If this was to be extended with cached global syscall information like
>> gettimeofday, would we want that to be in a separate page that is marked
>> non-executable? Is there any way to trick the kernel into leaking arbitrary
>> (and thus e
On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote:
If this was to be extended with cached global syscall information like
gettimeofday, would we want that to be in a separate page that is marked
non-executable? Is there any way to trick the kernel into leaking arbitrary
(and thus executable)
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for arm/arm
TB --- 2011-06-16 02:10:00 - cleaning the object tree
TB --- 2011-06-16 02:10:21 - cvsupping the source tree
TB --- 2011-06-16 02:10:21 - /usr/bin/csu
TB --- 2011-06-16 03:00:12 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 03:00:12 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-06-16 03:00:12 - cleaning the object tree
TB --- 2011-06-16 03:00:23 - cvsupping the source tree
TB --- 2011-06-16 03:00:23 - /usr/bin/c
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2011-06-16 02:10:00 - cleaning the object tree
TB --- 2011-06-16 02:10:23 - cvsupping the source tree
TB --- 2011-06-16 02:10:23 - /usr/bin/c
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2011-06-16 02:10:00 - cleaning the object tree
TB --- 2011-06-16 02:10:27 - cvsupping the source tree
TB --- 2011-06-16 02:10:27 - /usr/bin
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for i386/i386
TB --- 2011-06-16 02:10:00 - cleaning the object tree
TB --- 2011-06-16 02:10:28 - cvsupping the source tree
TB --- 2011-06-16 02:10:28 - /usr/bin/c
TB --- 2011-06-16 03:35:38 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 03:35:38 - starting HEAD tinderbox run for mips/mips
TB --- 2011-06-16 03:35:38 - cleaning the object tree
TB --- 2011-06-16 03:35:46 - cvsupping the source tree
TB --- 2011-06-16 03:35:46 - /usr/bin/c
TB --- 2011-06-16 04:08:45 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 04:08:45 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2011-06-16 04:08:45 - cleaning the object tree
TB --- 2011-06-16 04:08:48 - cvsupping the source tree
TB --- 2011-06-16 04:08:48 - /usr
TB --- 2011-06-16 04:02:52 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 04:02:52 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2011-06-16 04:02:52 - cleaning the object tree
TB --- 2011-06-16 04:03:04 - cvsupping the source tree
TB --- 2011-06-16 04:03:04 - /u
TB --- 2011-06-16 04:02:21 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 04:02:21 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2011-06-16 04:02:21 - cleaning the object tree
TB --- 2011-06-16 04:02:32 - cvsupping the source tree
TB --- 2011-06-16 04:02:32 - /usr
TB --- 2011-06-16 05:40:01 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-16 05:40:01 - starting HEAD tinderbox run for arm/arm
TB --- 2011-06-16 05:40:01 - cleaning the object tree
TB --- 2011-06-16 05:40:08 - cvsupping the source tree
TB --- 2011-06-16 05:40:08 - /usr/bin/csu
Jung-uk Kim wrote:
> On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > Can you please show me verbose boot messages *without* your
> > > patch? Does "sysctl kern.timecounter.hardware=HPET" help
> > > *without* touching eventtimers?
> >
> > I have the same issue with my system (Atom N27
33 matches
Mail list logo
