On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano wrote:
> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara
> wrote:
>> Hi,
>>
>> I've prepared a patch to add core and uncore events support for
>> haswell processor.
>> I do not have the hardware to test this. It applies cleanly and
>> compiles fin
On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara
wrote:
> Hi,
>
> I've prepared a patch to add core and uncore events support for
> haswell processor.
> I do not have the hardware to test this. It applies cleanly and
> compiles fine though.
>
> http://www.strugglingcoder.info/patches/hwpmc_hw.txt
Hi,
I've prepared a patch to add core and uncore events support for
haswell processor.
I do not have the hardware to test this. It applies cleanly and
compiles fine though.
http://www.strugglingcoder.info/patches/hwpmc_hw.txt
This is initial version of patch and manpage is still missing. I will
On Thu, Jan 31, 2013 at 8:56 AM, Thomas Mueller
wrote:
> Excerpt from Andrey Fesenko :
>
>> And other problems.
>> 1) wi-fi
>> standart rtl8192cu - not work
>> change AR5B95 - work n-mode (thanks Adrian Chadd :) need hack BIOS
>> dev.acpi_ibm.0.wlan: 1 <- read only
>> hardware switch work, not sen
Hi Jim,
On Thu, Jan 31, 2013 at 3:13 PM, Jim Harris wrote:
>
>
> On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu wrote:
>>
>> Hi,
>>
>> The following patch teaches pciconf(8) to display the table and pba
>> offsets when it displays the MSI-X capability.
>>
>> The new output format will look like:
>>
On Fri, 1 Feb 2013, Olivier Smedts wrote:
2013/1/31 AN :
On Thu, 31 Jan 2013, Olivier Smedts wrote:
2013/1/30 AN :
With all due respect to developers, are these changes tested at all
before
they are added to the codebase?
Won't sound respectful if the problem is not related to that c
2013/1/31 AN :
>
>
> On Thu, 31 Jan 2013, Olivier Smedts wrote:
>
>> 2013/1/30 AN :
>>>
>>> With all due respect to developers, are these changes tested at all
>>> before
>>> they are added to the codebase?
>>
>>
>> Won't sound respectful if the problem is not related to that commit.
>>
>> Which co
On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu wrote:
> Hi,
>
> The following patch teaches pciconf(8) to display the table and pba
> offsets when it displays the MSI-X capability.
>
> The new output format will look like:
>
> cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
>
Hi,
The following patch teaches pciconf(8) to display the table and pba
offsets when it displays the MSI-X capability.
The new output format will look like:
cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
OR
cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
0
On Thu, 2013-01-31 at 18:13 +0100, Andre Oppermann wrote:
> On 28.01.2013 20:20, Alan Cox wrote:
> > On 01/28/2013 08:22, Ian Lepore wrote:
> >> On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote:
> >>> On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote:
> >>>
> I ran into a panic while attemp
I updated my Asus EEEPC netbook from sources earlier on this month
to yesterday's sources, and whenever I shut the lid it now panics with
use after free (0xcacacaca) in AcpiEvNotifyDispatch. I understand that
ACPICA was updated recently, so my guess is that this is the root
cause (was the fix f
On Thu, 31 Jan 2013, Olivier Smedts wrote:
2013/1/30 AN :
With all due respect to developers, are these changes tested at all before
they are added to the codebase?
Won't sound respectful if the problem is not related to that commit.
Which compiler are you using for the base system, and fo
On 28.01.2013 20:20, Alan Cox wrote:
On 01/28/2013 08:22, Ian Lepore wrote:
On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote:
On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote:
I ran into a panic while attempting to un-tar a large file on a
DreamPlug (arm-based system) running -current. T
Lars Eggert wrote:
> Hi,
>
> On Jan 30, 2013, at 22:43, Craig Rodrigues
> wrote:
> > What you need to do is, before the FreeBSD kernel boots, your
> > loader needs to export some environment variables. This will trigger
> > the various behaviors in the FreeBSD mount code.
>
> the loader can expo
On Jan 31, 2013, at 15:54, Daniel Braniss wrote:
> a shot in the dark, but is /usr/home/elars/dst properly exported?
Yep, the NFS mount works fine when I use BOOTP with a root-path option
Lars
___
freebsd-current@freebsd.org mailing list
http://lists.f
> On Jan 31, 2013, at 12:53, Andre Oppermann
> wrote:
> > The interface doesn't have a name during loader stage. The kernel
> > finds the interface to use based on the MAC address. You should
> > set boot.netif.hwaddr as well in the kernel environment.
>
> Done, no change. Here is what's in my
on 31/01/2013 15:29 Sergey Kandaurov said the following:
> Hi.
>
> Got this assertion on idle NFS server while `ls -la /.zfs/shares/'
> issued on NFS client.
> kern/vfs_vnops.c:_vn_lock()
> KASSERT((flags & LK_RETRY) == 0 || error == 0,
> ("LK_RETRY set with inc
Hi.
Got this assertion on idle NFS server while `ls -la /.zfs/shares/'
issued on NFS client.
kern/vfs_vnops.c:_vn_lock()
KASSERT((flags & LK_RETRY) == 0 || error == 0,
("LK_RETRY set with incompatible flags (0x%x) or
an error occured (%d)",
panic: LK_RETRY set
yes, that may be the reason.
I write a simple c++ program in the built-complete system. and compile it:
clang++ hello.cpp -std=c++11 -stdlib=libc++ -o hello
it reports undefined reference to bad_alloc errors message same as someones
discuss in this mail list.
I find that it is because -stdlib=lib
On Jan 31, 2013, at 12:53, Andre Oppermann
wrote:
> The interface doesn't have a name during loader stage. The kernel
> finds the interface to use based on the MAC address. You should
> set boot.netif.hwaddr as well in the kernel environment.
Done, no change. Here is what's in my loader enviro
On Jan 31, 2013, at 12:45, Andreas Nilsson
wrote:
> Just a shot in the dark, did you actually tell it to do the root mount ro,
> or try with the nfs share as rw?
ro
Lars
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On 31.01.2013 12:27, Eggert, Lars wrote:
Hi,
On Jan 30, 2013, at 22:43, Craig Rodrigues wrote:
What you need to do is, before the FreeBSD kernel boots, your
loader needs to export some environment variables. This will trigger
the various behaviors in the FreeBSD mount code.
the loader can e
Done. I also ripped out all the BOOTP* options from the kernel.
>
> However, this still fails:
>
> Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []...
> mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ...
> Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with
Hi,
On Jan 30, 2013, at 22:43, Craig Rodrigues wrote:
> What you need to do is, before the FreeBSD kernel boots, your
> loader needs to export some environment variables. This will trigger
> the various behaviors in the FreeBSD mount code.
the loader can export some environment variables (this
On 01/31/13 05:43, O. Hartmann wrote:
> Am 01/31/13 05:06, schrieb Jesse:
>> z
>>
>> On 1/31/13, Jesse wrote:
>>> i set these in make.conf:
>>> CXXFLAGS+=-stdlib=libc++
>>> CXXFLAGS+=-std=c++11
>>>
>>> i comment them and rebuild world ok
>>> but it works at previous revision.
>>>
>>> On 1/30/13,
On 30 Jan 2013, at 21:23, AN wrote:
> VirtualBox: dlopen("/usr/local/lib/virtualbox/VBoxRT.so",) failed:
> /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by
> /usr/local/lib/virtualbox/VBoxRT.so not found
GLIBCXX_3.4.15 is the symbol version of the libstdc++ that ships with gcc 4.6.
On 31 Jan 2013, at 04:37, O. Hartmann wrote:
> First, I suspected the c++ option "-std=c++11" I issued in /etc/src.conf
> when building the sources - I did this before without any problems.
> Then, leaving the build without "-std=c++11" option, I get the following
> error below and compilation sto
2013/1/30 AN :
> With all due respect to developers, are these changes tested at all before
> they are added to the codebase?
Won't sound respectful if the problem is not related to that commit.
Which compiler are you using for the base system, and for ports ?
(more specifically for the virtualbo
28 matches
Mail list logo
