On Mon, Oct 31, 2011 at 3:01 AM, Garrett Cooper wrote:
> On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote:
>
>> On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky
>> wrote:
>>
>>> On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:
>>
I don't recall this case happening
On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote:
> On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky wrote:
>
>> On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:
>
>>> I don't recall this case happening some time ago. But now, this
>
>>> happens with and without the
On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky wrote:
> On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:
>> I don't recall this case happening some time ago. But now, this
>> happens with and without the NEW_PCIB option. I mention this because
>> ``acpi0: on motherboard'
On 2011-10-30 17:55, David Marec wrote:
Le 30.10.2011 08:52, Roman Divacky a écrit :
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote:
This is a bug in clang, llvm supports "amdfam10" but the clang counterpart
wasnt updated. Thank you for the report!
fwiw, I fixed it in clang r
On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:
> If a USB mass storage device was connected when the computer was
> turned on or reset and the device is left connected, then the system
> locks up somewhere around the ``acpi0: on
> motherboard'' line (not exactly deterministically
On Sunday 30 October 2011 01:31:21 Daniel O'Connor wrote:
> I'm not sure what would load it automatically - it may be built into the
> kernel though. Anyway, as you say it should work with ulpt loaded anyway.
Hi,
ulpt is autoloaded by /etc/devd/usb.conf
--HPS
Assume we are running on the single-package X86 machine, how to answer
the question: what is the possible maximum tsc frequency ?
I read tsc_levels_changed(), is it the right way to query the max
frequency for the general purpose driver ? If yes, could the code be
made into the utility function ?
Le 30.10.2011 08:52, Roman Divacky a écrit :
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote:
This is a bug in clang, llvm supports "amdfam10" but the clang counterpart
wasnt updated. Thank you for the report!
fwiw, I fixed it in clang r143305, so in the next import this will w
Hello, Kostik.
You wrote 30 октября 2011 г., 19:03:39:
> See taskqueue(9). On the other hand, waiting for the enqueued task to
> finish is itself the sleepable action.
I'll not wait for finishing. Task will put result to volatile atomic
field, and it's all.
--
// Black Lion AKA Lev Serebryako
On Sun, Oct 30, 2011 at 06:54:51PM +0400, Lev Serebryakov wrote:
> So, I have question: what should I do if I need to perofrm ONE
> action, which could block for some time (for example, open file or
> create ALQ)?
>
> I could create thread for this. But it looks strange and too heavy: create
>
Hello, Current.
It was explained to me, that all three GEOM threads (up, down and
ctl) could not execute code, which should sleep. It looks sound for
up and down, but not for ctl, but it is so now.
So, I have question: what should I do if I need to perofrm ONE
action, which could block for so
Le 30.10.2011 08:28, David Marec a écrit :
>> I have a similar problem..
Le 30.10.2011 08:28, David Marec a écrit :
>> I have a similar problem..
A new behavior occurs since I updated the world & kernel this morning.
`devd` now executes the entry for hplip, as I defined it inside
/usr/local/e
Le 30.10.2011 10:04, Jakub Lach a écrit :
Or "just" extend hplip section in handbook.
http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html
It should be a good idea, I agree.
Especially in this case, where nobody now knows how and where HPLIP
rights have to be settled.
It co
Or "just" extend hplip section in handbook.
http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html
It could be roughly based upon this:
http://freebsd.kde.org/howtos/hplip.php
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-th
It would be nice, If somebody would write updated
manual documenting whole process of setting up hplip.
In past, I could only get it to the point of printing
test pages (sigh...)
Before release preferably?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-U
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote:
> This is a bug in clang, llvm supports "amdfam10" but the clang counterpart
> wasnt updated. Thank you for the report!
fwiw, I fixed it in clang r143305, so in the next import this will work just
fine :)
roman
___
Le 29.10.2011 21:58, Jilles Tjoelker a écrit :
> On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote:
>> So, what's should be the news group&user's rights required by HPLIP/cups
>> on FreeBSD 9 ?
>
>> And, how to handle them with devd ?
>
> Use devfs rules.
Doing this, device rights becom
This is a bug in clang, llvm supports "amdfam10" but the clang counterpart
wasnt updated. Thank you for the report!
On Sat, Oct 29, 2011 at 03:44:30PM +0200, David Marec wrote:
> hi list,
>
>
> Running FreebSD 9.0 RC-1, the "make buildworld" processing failed on the
> following error on its att
On 30/10/2011, at 17:22, John-Mark Gurney wrote:
> How am I suppose to detach an ata controller with the new ATA_CAM layer?
> On the old layer when pulling drives like CF cards, I would always detach,
> to ensure that nothing would be going on when I pulled the drive, but a
> quick glance through
Le 30.10.2011 01:31, Daniel O'Connor a écrit :
On 30/10/2011, at 24:40, David Marec wrote:
But, now running FreeBSD 9, I get new usb/devd behavior issues.
First, the ulpt module is always loaded. Is there any elegant way to get rid of
this 'self loading' behavior, except to remove it from /bo
How am I suppose to detach an ata controller with the new ATA_CAM layer?
On the old layer when pulling drives like CF cards, I would always detach,
to ensure that nothing would be going on when I pulled the drive, but a
quick glance through camcontrol's man page I don't see a way to do that.
Anyon
21 matches
Mail list logo