On Wednesday 01 June 2011 01:07:29 m...@freebsd.org wrote:
> I am looking into potentially MFC'ing r212367 and related, that adds
> drains to sbufs. The reason for MFC is that several pieces of new
> code in CURRENT are using the drain functionality and it would make
> MFCing those changes much ea
On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
> On 02/06/12 18:01, Alexander Best wrote:
>> On Mon Feb 6 12, Alexander Motin wrote:
>>> I've analyzed scheduler behavior and think found the problem with HTT.
>>> SCHED_ULE knows about HTT and when doing load balancing once a second,
>>>
On 21-08-2012 17:04, Dan McGregor wrote:
> My solution is certainly fairly hacky, I just took inspiration from
> NetBSD. I wanted to see if it could be done. While I was there I did
> identify several files that should be common between i386 and amd64,
> such as exec.h.
>
> Since reading your em
On 20-02-2013 16:48, Konstantin Belousov wrote:
> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
>> Hi
>>
>> Wine needs some of its libraries to be loaded at specific base
>> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently
>> lacks.
>>
>> I've written a pat
On 21-02-2013 16:44, Konstantin Belousov wrote:
> On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote:
>> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote:
>>> On 20-02-2013 16:48, Konstantin Belousov wrote:
>>>> On Wed, Feb 20, 2013 at 05:29:01PM
While working on Wine I hit on a race between a ptrace PT_DETACH and
subsequent PT_ATTACH which causes the SIGSTOP of this attach to get
lost and never delivered. Attached are a test program and a proposed
patch.
The test program forks a child and loops attaching and detaching to it.
It can hang d
On Sunday 18 November 2007 14:39:41 [EMAIL PROTECTED] wrote:
> Tijl Coosemans <[EMAIL PROTECTED]> a écrit :
>> On Saturday 17 November 2007 17:03:51 nikita kozlov wrote:
>>> I'm a student and we are working on FreeBSD.
>>> My problem is i don't underst
On Saturday 17 November 2007 17:03:51 nikita kozlov wrote:
> I'm a student and we are working on FreeBSD.
> My problem is i don't understand how to use SA_SIGINFO and siginfo_t.
> The following code caught my SIGUSR1 with a "kill -30 my_server_pid"
> from my shell.
> but siginfo_t is empty when i'm
On Thursday 01 July 2010 03:07:09 Sam Fourman Jr. wrote:
>> i386 32bit-mode page table has no NX bit - the PAE page table has...
>
> You are correct, I went in my BIOS, and disabled execute bit.
>
> Then when I run the test C code, the get "trapped" just as expected
> on both 8.1 amd64 and CURREN
On Wednesday 30 June 2010 01:54:11 Sam Fourman Jr. wrote:
> Last Tuesday blizzard release World of Warcraft 3.3.5, and with this
> patch World of warcraft stopped working in FreeBSD 8.1 amd64, it
> crashes right after login.
>
> I have been playing World of Warcraft on FreeBSD amd64 since December
On Thursday 16 September 2010 10:41:07 Oliver Fromme wrote:
> Alexander Best wrote:
>> On Wed Sep 15 10, Oliver Fromme wrote:
>>> The patch below will work with the new CAM ATA driver
>>> (i.e. ada(4) disks). It adds a sysctl, so you can switch
>>> the spin-down off if you're going to just reboot:
On Thursday 16 September 2010 16:10:22 Oliver Fromme wrote:
> Tijl Coosemans wrote:
>> I would just spin down the disk in case of a halt. An unwanted spin
>> down is harmless compared to an emergency shutdown and usually the
>> intention is to power off rather than reboot
On Friday 22 October 2010 00:32:54 Paul Wootton wrote:
> Actually, the green series does spin all the way down, well at least
> the drive I have does.
> Here is the output from one of my drives, that I do not think has
> long left to live.
>
> === START OF INFORMATION SECTION ===
> Model Family:
On Sunday 24 October 2010 18:47:57 Alexander Motin wrote:
> I am not sure, but have feeling that tape drives (for example) may
> also benefit from head parking before powering down.
USB hard disks would benefit as well I think. Although, ideally it
should happen after unmounting the last file syst
On Friday 31 October 2008 20:30:46 Steve Franks wrote:
> Let's backup. What's the 'right' way to get a bloody linux program
> that expects all it's headers in /usr/include to compile on freebsd
> where all the headers are in /usr/local/include? That's all I'm
> really asking. Specifically, it's
On Thursday 05 March 2009 22:22:09 Daniel Thiele wrote:
> Looking at the numbers in the Hitachi drive specifications Tobias an I
> dug out from the Hitachi website (see replies in the Joerg Sonnenberger
> branch of this thread) the normal Load/Unload count is about 30 times
> higher than the Emerge
On Thursday 05 March 2009 20:03:45 Tobias Blersch wrote:
> http://www.hitachigst.com/tech/techlib.nsf/techdocs/28DCCB17E0EEC5A086256F4E006E2F5B
>
> Thats the specification for my notebooks hard drive. Section 6.6
> Reliability gives data about how to power-off the disk. It also
> contains numbers
On Friday 10 April 2009 20:31:33 Robert Noland wrote:
> On Fri, 2009-04-10 at 18:59 +0100, xorquew...@googlemail.com wrote:
>> The system doesn't seem to have frozen since DRI/DRM was disabled.
>>
>> I did have one crash/reboot whilst building a large number of
>> packages with tinderbox. I've cur
On Monday 13 July 2009 20:28:08 John Baldwin wrote:
> On Sunday 05 July 2009 3:32:25 am Alexander Best wrote:
>> so mmap differs from the POSIX recommendation right. the malloc.conf
>> option seems more like a workaround/hack. imo it's confusing to have
>> mmap und munmap deal differently with len=
On Friday 27 November 2009 22:17:31 Maxim Sobolev wrote:
> I am trying to figure out why java fails to start with 1024MB of heap
> on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are
> set to 2GB. Here is my limits:
>
> Resource limits (current):
>cputime infinity se
On Tuesday 26 January 2010 20:17:23 Alexander Best wrote:
> because of kern/140752 i looked through a discussion back in 2009
> (http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027879.html)
> concerning freebsd's hdd spin down procedure. right now
> ATA_FLUSHCACHE is being used althou
On Sunday 23 July 2006 11:18, Divacky Roman wrote:
> On Sat, Jul 22, 2006 at 07:15:35PM -0400, Daniel Eischen wrote:
> > I think it is because WINE stomps on or TLS. Nothing we can
> > do about that except patch wine so it doesn't. Look at the
> > console messages for:
> >
> > Warning: pid XXX
On Sunday 23 July 2006 11:18, Divacky Roman wrote:
> On Sat, Jul 22, 2006 at 07:15:35PM -0400, Daniel Eischen wrote:
> > I think it is because WINE stomps on or TLS. Nothing we can
> > do about that except patch wine so it doesn't. Look at the
> > console messages for:
> >
> > Warning: pid XXX
On Saturday 22 July 2006 19:14, Michael Nottebrock wrote:
> WINE does have certain requirements regarding memory allocation. In
> particular it (or Windows, rather) really wants a few memory ranges
> for itself:
>
> (from wine-0.9.17/loader/preloader.c):
>
> * 0x - 0x0011 the DOS are
On Monday 24 July 2006 17:39, Daniel Eischen wrote:
> On Mon, 24 Jul 2006, Tijl Coosemans wrote:
> > I've attached two patches that accomplish this, but this seems to
> > trigger other problems, so use at your own risk. If you want to try
> > them, place them in the port&
On Monday 24 July 2006 18:49, Daniel Eischen wrote:
> On Mon, 24 Jul 2006, Tijl Coosemans wrote:
> > On Monday 24 July 2006 17:39, Daniel Eischen wrote:
> >> On Mon, 24 Jul 2006, Tijl Coosemans wrote:
> >>> I've attached two patches that accomplish this, bu
On Thursday 27 July 2006 17:21, John Baldwin wrote:
> On Monday 24 July 2006 21:58, Tijl Coosemans wrote:
> > However, Wine/Windows uses %fs for TLS and it appears that the
> > FreeBSD kernel doesn't preserve it. It always ends up pointing to
> > GUDATA_SEL.
>
>
On Thursday 27 July 2006 23:53, Julian Elischer wrote:
> Tijl Coosemans wrote:
> > On Thursday 27 July 2006 17:21, John Baldwin wrote:
> > > The kernel should preserve %fs across syscalls, traps, and faults.
> > > Can you point to a specific case where %fs is not prese
I'm refering to the following two lines in sys/i386/i386/trap.c
/* kludge to pass faulting virtual address to sendsig */
frame->tf_err = eva;
Isn't there some other way to do this? Wouldn't the address still be
available in %cr2 inside sendsig? Or could there have been other page
faults by then
On Saturday 29 July 2006 21:57, Kip Macy wrote:
> Looking at siginfo it isn't clear that there is a "right way" to
> provide SIGSEGV, eva, and the error code.
>
> _fault._trapno should contain the machine's error code and si_signo
> should contain SIGSEGV, and si_addr contains the faulting pc. Mayb
On Sunday 30 July 2006 21:30, Kip Macy wrote:
> > si_addr doesn't contain the faulting pc, it contains the address
> > that
>
> So either the comment is wrong, or that is a technically incorrect
> kludge. However, given that a number of the other fields are not
> filled out at all, the real objecti
On Fri, 5 Mar 2004 17:58:26 +0100 (MET), Helge Oldach wrote:
> So yes: some machines require a kernel with PNPBIOS even when sound
> modules can be kldload'ed. I presume these are typically boxen without
> knob to disable the PnP BIOS.
>
> Still I wonder whether sound on -CURRENT will do on such
32 matches
Mail list logo