Hi, I tested your patch and it didn't panic. I checked the dev.cpu
sysctl nodes to see if the CPU freq is changing or not.
I unplugged the cable :
mark...@melon ~ $ sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none
On Wed, May 12, 2010 at 3:35 PM, David DEMELIER
wrote:
> Hi, I tested your patch and it didn't panic. I checked the dev.cpu
> sysctl nodes to see if the CPU freq is changing or not.
>
It's very odd. I did nothing to prevent panic. in fact you should have
seen a panic.
did you apply the patch on a
> Date: Wed, 12 May 2010 15:35:51 +0200
> From: David DEMELIER
> Sender: owner-freebsd-sta...@freebsd.org
>
> Hi, I tested your patch and it didn't panic. I checked the dev.cpu
> sysctl nodes to see if the CPU freq is changing or not.
>
> I unplugged the cable :
> mark...@melon ~ $ sysctl dev.cp
I remove the patch, and built the kernel (I updated the src this
morning) and it does not panic now. It's really odd. If it reappears
soon I will tell you.
Thanks.
--
Demelier David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/m
2010/5/12 David DEMELIER :
> I remove the patch, and built the kernel (I updated the src this
> morning) and it does not panic now. It's really odd. If it reappears
> soon I will tell you.
I looked at the code with Giovanni and I have the feeling that the
race with the idle thread may still be fat
I would like to share a solution of a problem I faced with the current
version of OpenSSH in 8-STABLE (5.4p1).
Last upgrade of my system updated OpenSSH from 5.2p1 to 5.4p1 which has
a regression for those using a non-default AuthorizedKeysFile option set
to a relative path (".ssh/keys" in my
Or install the version from ports and deactivate the base version...
On 2010-05-12 10:42:00PM +0200, Matthieu Michaud wrote:
> I would like to share a solution of a problem I faced with the current
> version of OpenSSH in 8-STABLE (5.4p1).
>
> Last upgrade of my system updated OpenSSH from 5.2p1
nesis/archive/.zfs
> ls: snapshot: Bad file descriptor
> total 0
>
> Other file systems in the same pool work fine though..
> [cain 9:36] ~ >ll /usr/local/Genesis/MeteorData/.zfs/snapshot
> total 4
> drwxrwxr-x 32 metdata radar 38 Mar 21 03:11 20100512-0900
>
> (All oth
On Wed, May 12, 2010 at 9:41 AM, Attilio Rao wrote:
> 2010/5/12 David DEMELIER :
>> I remove the patch, and built the kernel (I updated the src this
>> morning) and it does not panic now. It's really odd. If it reappears
>> soon I will tell you.
>
> I looked at the code with Giovanni and I have th
I'm working on getting p0f integrated with amavisd-new. Everything is
great, with the exception that I can't get the neccessary commands to
execute on boot.
I started with rc.local and that didn't work. So I made this simple script
in /usr/local/etc/rc.d/p0f:
---
#!/bin/sh
# PROVIDE: p0f
#
Hi--
On May 12, 2010, at 4:46 PM, Andy Dills wrote:
> I'm working on getting p0f integrated with amavisd-new. Everything is
> great, with the exception that I can't get the neccessary commands to
> execute on boot.
The amavid-p0fanalyzer script should have been installed if you used the port:
On 13/05/2010, at 6:53, Stefan Bethke wrote:
> Am 12.05.2010 um 02:09 schrieb Daniel O'Connor:
>> [cain 9:37] ~ >ls -la /usr/local/Genesis/archive/.zfs
>> ls: snapshot: Bad file descriptor
>> total 0
>>
> This appears to be a long standing issue with no solution. I used to get
> this a lot duri
On Wed, 12 May 2010, Chuck Swiger wrote:
> Hi--
>
> On May 12, 2010, at 4:46 PM, Andy Dills wrote:
> > I'm working on getting p0f integrated with amavisd-new. Everything is
> > great, with the exception that I can't get the neccessary commands to
> > execute on boot.
>
> The amavid-p0fanalyz
13 matches
Mail list logo