Re: [patch] Wine DLL base address patches

[Tijl Coosemans]

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 +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 patch to the dynamic loader (/libexec/ld-elf.so.1) that
>>>>> loads libraries at their preferred base addresses
>>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port
>>>>> of Prelink to FreeBSD which Wine uses to set base addresses
>>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-),
>>>>> the changed dynamic loader doesn't show any problems in a few days of
>>>>> testing, and prelink works with the --reloc-only option as used by
>>>>> Wine.
>>>>>
>>>>> Please review/test/comment/commit.
>>>>
>>>> Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings
>>>> which could exist at the specified address.
>>>
>>> I've simplified the rtld patch to a single line. The second patch makes
>>> Wine use -Ttext-segment linker flag instead of prelink. This requires
>>> binutils from ports, but it's easier than porting prelink.
>>>
>>
>> All of that occurred to me as well.
>>
>> The problem with that one-line rtld patch is that loading an
>> application will now fail if any of its libraries cannot be loaded at
>> their requested address.
> But this is intended behaviour. Also, the default virtaddr base for the
> shared libraries is 0, so the existing binaries should be not affected.
> 
>>
>> The problem with -Ttext-segment (and isn't it just -Ttext?) is that it
>> doesn't seem to work: the base_vaddr seen by rtld will remain 0, and
>> the address listed in /proc/.../map is different from what it should
>> be. Also run "readelf -l" on a library compiled that way and compare
>> with the output of one run through "prelink --reloc-only", you'll see
>> the lowest VirtAddr and PhysAddr in LOAD headers change only with
>> prelink. I really ported prelink because there was no other choice.
> The -Ttext-segment does work. As indicated by Tijl, you need recent
> binutils.  I just verified that ld 2.32.1 obeys -Ttext-segment.
> 
> You can also take a look at the default linker script to see how
> -Ttext-segment is used, look for SEGMENT_START("text-segment").

Yes, -Ttext sets the address of the .text section and -Ttext-segment
that of the text segment. It does work for me. The output of /proc/.../map
looks correct as does the output of "info share" in winedbg, but to be
sure I've asked on wine-devel mailing list if they see any problem with
this approach.



signature.asc
Description: OpenPGP digital signature

Re: [patch] Wine DLL base address patches

[Tijl Coosemans]

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 patch to the dynamic loader (/libexec/ld-elf.so.1) that
>> loads libraries at their preferred base addresses
>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port
>> of Prelink to FreeBSD which Wine uses to set base addresses
>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-),
>> the changed dynamic loader doesn't show any problems in a few days of
>> testing, and prelink works with the --reloc-only option as used by
>> Wine.
>>
>> Please review/test/comment/commit.
> 
> Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings
> which could exist at the specified address.

I've simplified the rtld patch to a single line. The second patch makes
Wine use -Ttext-segment linker flag instead of prelink. This requires
binutils from ports, but it's easier than porting prelink.

Index: libexec/rtld-elf/map_object.c
===
--- libexec/rtld-elf/map_object.c   (revision 246986)
+++ libexec/rtld-elf/map_object.c   (working copy)
@@ -175,7 +175,7 @@ map_object(int fd, const char *path, const struct
 base_vaddr = trunc_page(segs[0]->p_vaddr);
 base_vlimit = round_page(segs[nsegs]->p_vaddr + segs[nsegs]->p_memsz);
 mapsize = base_vlimit - base_vaddr;
-base_addr = hdr->e_type == ET_EXEC ? (caddr_t) base_vaddr : NULL;
+base_addr = (caddr_t) base_vaddr;
 
 mapbase = mmap(base_addr, mapsize, PROT_NONE, MAP_ANON | MAP_PRIVATE |
   MAP_NOCORE, -1, 0);
Index: Makefile
===
--- Makefile(revision 312556)
+++ Makefile(working copy)
@@ -28,7 +28,7 @@
 LATEST_LINK=   wine-devel
 CPPFLAGS+= -I${LOCALBASE}/include
 LDFLAGS+=  -L${LOCALBASE}/lib
-USE_GCC=   any
+USE_GCC=   4.7
 GNU_CONFIGURE= yes
 CONFIGURE_ARGS+=--verbose --disable-tests \
--without-alsa --without-capi --without-dbus \
Index: files/patch-tools-winegcc-utils.h
===
--- files/patch-tools-winegcc-utils.h   (revision 0)
+++ files/patch-tools-winegcc-utils.h   (working copy)
@@ -0,0 +1,12 @@
+--- tools/winegcc/utils.h.orig
 tools/winegcc/utils.h
+@@ -42,7 +42,8 @@
+ 
+ enum target_platform
+ {
+-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS, 
PLATFORM_CYGWIN
++PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SOLARIS,
++PLATFORM_WINDOWS, PLATFORM_CYGWIN
+ };
+ 
+ void error(const char* s, ...) DECLSPEC_NORETURN;
Index: files/patch-tools-winegcc-winegcc.c
===
--- files/patch-tools-winegcc-winegcc.c (revision 0)
+++ files/patch-tools-winegcc-winegcc.c (working copy)
@@ -0,0 +1,32 @@
+--- tools/winegcc/winegcc.c.orig
 tools/winegcc/winegcc.c
+@@ -172,6 +172,7 @@
+ {
+ { "macos",   PLATFORM_APPLE },
+ { "darwin",  PLATFORM_APPLE },
++{ "freebsd", PLATFORM_FREEBSD },
+ { "solaris", PLATFORM_SOLARIS },
+ { "cygwin",  PLATFORM_CYGWIN },
+ { "mingw32", PLATFORM_WINDOWS },
+@@ -232,6 +233,8 @@
+ 
+ #ifdef __APPLE__
+ static enum target_platform build_platform = PLATFORM_APPLE;
++#elif defined(__FreeBSD__)
++static enum target_platform build_platform = PLATFORM_FREEBSD;
+ #elif defined(__sun)
+ static enum target_platform build_platform = PLATFORM_SOLARIS;
+ #elif defined(__CYGWIN__)
+@@ -1020,6 +1023,12 @@
+ if (opts->strip)
+ strarray_add(link_args, "-Wl,-x");
+ break;
++case PLATFORM_FREEBSD:
++if (opts->image_base)
++{
++strarray_add(link_args, strmake("-Wl,-Ttext-segment=%s", 
opts->image_base));
++}
++break;
+ case PLATFORM_SOLARIS:
+ {
+ char *mapfile = get_temp_file( output_name, ".map" );


signature.asc
Description: OpenPGP digital signature

Re: Build 32 bit binaries on amd64

[Tijl Coosemans]

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 email I started looking at the x86 common code,
> and have made some more code common; specifically asm.h ans
> ucontext.h.  I'll be putting that on github shortly.
> 
> Since it does look like tijl hasn't committed anything since March,
> I would like to co-operate and see what his plans were.  The idea of
> merging the i386 and amd64 headers into a common area seems like a
> better idea to me.

For now my goal was to merge headers that can be used by user code so
it can be compiled with -m32. Eventually, I think it would be nice to
merge all headers and install x86/ as machine/ for both i386 and amd64.
That would make the x86 headers similar to powerpc and mips headers
(and arm when 64bit support is added there).

I think I still have one or two (untested) patches. I'll have a look at
it during the weekend.



signature.asc
Description: OpenPGP digital signature

Re: [RFT][patch] Scheduling for HTT and not only

[Tijl Coosemans]

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,
>>> it does right things. Unluckily, if some other thread gets in the way,
>>> process can be easily pushed out to another CPU, where it will stay for
>>> another second because of CPU affinity, possibly sharing physical core
>>> with something else without need.
>>>
>>> I've made a patch, reworking SCHED_ULE affinity code, to fix that:
>>> http://people.freebsd.org/~mav/sched.htt.patch
>>>
>>> This patch does three things:
>>>   - Disables strict affinity optimization when HTT detected to let more
>>> sophisticated code to take into account load of other logical core(s).
>>>   - Adds affinity support to the sched_lowest() function to prefer
>>> specified (last used) CPU (and CPU groups it belongs to) in case of
>>> equal load. Previous code always selected first valid CPU of evens. It
>>> caused threads migration to lower CPUs without need.
>>>   - If current CPU group has no CPU where the process with its priority
>>> can run now, sequentially check parent CPU groups before doing global
>>> search. That should improve affinity for the next cache levels.
>>>
>>> Who wants to do independent testing to verify my results or do some more
>>> interesting benchmarks? :)
>>
>> i don't have any benchmarks to offer, but i'm seeing a massive increase in
>> responsiveness with your patch. with an unpatched kernel, opening xterm while
>> unrar'ing some huge archive could take up to 3 minutes!!! with your patch the
>> time it takes for xterm to start is never>  10 seconds!!!
> 
> Thank you for the report. I can suggest explanation for this. Original 
> code does only one pass looking for CPU where the thread can run 
> immediately. That pass limited to the first level of CPU topology (for 
> HTT systems it is one physical core). If it sees no good candidate, it 
> just looks for the CPU with minimal load, ignoring thread priority. I 
> suppose that may lead to priority violation, scheduling thread to CPU 
> where higher-priority thread is running, where it may wait for a very 
> long time, while there is some other CPU with minimal priority thread. 
> My patch does more searches, that allows to handle priorities better.

But why would unrar have a higher priority?


signature.asc
Description: This is a digitally signed message part.

Re: sizeof(function pointer)

[Tijl Coosemans]

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 easier.
> 
> The problem is that r212367 added a pointer to a drain function in the
> sbuf (it replaced a pointer to void).  The C standard doesn't
> guarantee that a void * and a function pointer have the same size,
> though its true on amd64, i386 and I believe PPC.  What I'm wondering
> is, though not guaranteed by the standard, is it *practically* true
> that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't
> break binary compatibility for any supported architecture?

It's guaranteed by POSIX.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
Section 2.12.3


signature.asc
Description: This is a digitally signed message part.

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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 system.


signature.asc
Description: This is a digitally signed message part.

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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: Western Digital Caviar Green family
> Device Model: WDC WD5000AADS-00M2B0
> Serial Number:WD-WMAV51882791
> Firmware Version: 01.00A01
> User Capacity:500,107,862,016 bytes
> Device is:In smartctl database [for details use: -P show]
> ATA Version is:   8
> ATA Standard is:  Exact ATA specification draft version not indicated
> Local Time is:Thu Oct 21 23:31:35 2010 BST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
> UPDATED  WHEN_FAILED RAW_VALUE
>1 Raw_Read_Error_Rate 0x002f   200   200   051Pre-fail  
> Always   -   0
>3 Spin_Up_Time0x0027   111   104   021Pre-fail  
> Always   -   7425
>4 Start_Stop_Count0x0032   100   100   000Old_age   
> Always   -   98
>5 Reallocated_Sector_Ct   0x0033   200   200   140Pre-fail  
> Always   -   0
>7 Seek_Error_Rate 0x002e   100   253   000Old_age   
> Always   -   0
>9 Power_On_Hours  0x0032   093   093   000Old_age   
> Always   -   5295
>   10 Spin_Retry_Count0x0032   100   253   000Old_age   
> Always   -   0
>   11 Calibration_Retry_Count 0x0032   100   253   000Old_age   
> Always   -   0
>   12 Power_Cycle_Count   0x0032   100   100   000Old_age   
> Always   -   96
> 192 Power-Off_Retract_Count 0x0032   200   200   000Old_age   
> Always   -   95
> 193 Load_Cycle_Count0x0032   001   001   000Old_age   
> Always   -   781014
> 194 Temperature_Celsius 0x0022   120   102   000Old_age   
> Always   -   27
> 196 Reallocated_Event_Count 0x0032   200   200   000Old_age   
> Always   -   0
> 197 Current_Pending_Sector  0x0032   200   200   000Old_age   
> Always   -   0
> 198 Offline_Uncorrectable   0x0030   200   200   000Old_age   
> Offline  -   0
> 199 UDMA_CRC_Error_Count0x0032   200   200   000Old_age   
> Always   -   0
> 200 Multi_Zone_Error_Rate   0x0008   200   200   000Old_age   
> Offline  -   0
> 
> 
> The datasheet for these drive 
> http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf
>  
> says
> "Reliability/Data Integrity
> Load/unload cycles (3) 300,000
> Limited Warranty (years) (4)
> (3) Controlled unload at ambient condition
> (4) The term of the limited warranty my vary by region"
> 
> Also 
> http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357
> "(drive has been validated to 1 million load/unload cycles without issue)"
> 
> Im already at 781014 load cycles, yet the drive is only about 7 months 
> old. Doing the math, I am getting a load/unload cycle about every 24.5 
> seconds
> Another 2 months and I will be knocking on for 1 million load/unload 
> cycles
> 
> As DES has already said, for most people the extra load/unload cycles 
> when rebooting a computer will not be an issue at all and is far more 
> desirable than an emergency park when powering down

FreeBSD frequently accesses hard disks (log files, flushing dirty
memory pages every 30s,...) and laptop drives tend to have aggressive
power saving settings by default. That's why your load cycle is so high.

To deal with this you should consider installing sysutils/ataidle and
adding these lines to /etc/rc.conf:

ataidle_enable="YES"
ataidle_devices="ad0"
ataidle_ad0="-P 0"

An alternative is to use atacontrol(8).

If you don't mind the spin down when rebooting you can solve the
emergency park at shutdown with a simple patch like this:

--- sys/dev/ata/ata-disk.c
+++ sys/dev/ata/ata-disk.c
@@ -193,6 +193,8 @@
 
 if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE)
 ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0);
+if (atadev->param.support.command1 & ATA_SUPPORT_POWERMGT)
+ata_controlcmd(dev, ATA_STANDBY_IMMEDIATE, 0, 0, 0);
 return 0;
 }
 


signature.asc
Description: This is a digitally signed message part.

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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.
> 
> Is it?  When I intend to power-off, I use shutdown -p, not
> shutdown -h.  Quite often (but not always) when I halt a
> machine, I'm going to reboot to multi-user, not power off.

Hmm, I suppose support for power off is ubiquitous nowadays. It used to
be that halt meant: bring the system in a state where we can safely cut
the power. In that case it makes sense to let halt spin down the disks.
If you intend to reboot why not explicitly reboot rather than halt?
Also, to go from single to multi user mode you can just exit(1) the
shell.

> In that case I certainly wouldn't want to spin the drives
> down and have them spun up immediately afterwards.  I don't
> think that wear&tear caused by that procedure is completely
> insignificant (although it's certainly less of a problem
> than emergency unloads).
> 
> For that reason I definitely want to have a way to disable
> the spindown function manually.

Ok, I'm soft on the sysctl really, it wouldn't hurt anyone. Although,
if the intention is to just override the default behaviour at the time
of shutdown you might as well just add an option to halt(8). A "don't
spin down disks" option would fit in with the other options there.


signature.asc
Description: This is a digitally signed message part.

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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:
>>> # sysctl kern.cam.ada.spindown_shutdown=0
>>
>> the hdd should spindown when a shutdown has been issued and not spindown,
>> if a reboot has been issued.
>
> Right.  That's why my shutdown wrapper script sets the sysctl
> to 0 when the -r option is present (I've got that wrapper
> script for ages, for different reasons).
> 
> Also, there are cases where it is completely impossible to
> decide automatically whether the disks should be spun down
> or not.  For example, if the admin issues a shutdown -h
> (halt), there's no way for the OS to know in advance whether
> the admin is going to switch the machine off or reboot to
> multi-user.  So there must be a way for the user to forcibly
> enable/disable the spindown feature.  I think a sysctl is
> the most appropriate way to do that, isn't it?

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.

Part of your patch modifies ada_shutdown. That function already gets
the reboot(2) howto flags passed to it, so you could test for
(howto & (RB_HALT | RB_POWEROFF)) != 0 before issuing the STANDBY
command. There's no need to make this more complicated with a sysctl
that can override this in my opinion.

Also command2 should be command1 in this line:

+   if (cgd->ident_data.support.command2 & ATA_SUPPORT_POWERMGT)


signature.asc
Description: This is a digitally signed message part.

Re: kernel patch needed for wine?

[Tijl Coosemans]

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
> of 2009 using the beta Nvidia 64bit drivers and this wine how-to
>
> http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d
>
> I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post
> 3.3.5 so far as I can tell it is only broken on amd64.

Could you give the attached patch a try?

cd /usr/src
patch -p1 < /path/to/patch-amd64-dr7
make buildkernel installkernel
diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index cfb4204..6b5c663 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -243,13 +243,13 @@ store_dr:
movq%dr2,%r13
movq%dr3,%r12
movq%dr6,%r11
-   andq$0xfc00, %rax   /* disable all watchpoints */
movq%r15,PCB_DR0(%r8)
movq%r14,PCB_DR1(%r8)
movq%r13,PCB_DR2(%r8)
movq%r12,PCB_DR3(%r8)
movq%r11,PCB_DR6(%r8)
movq%rax,PCB_DR7(%r8)
+   andq$0xfc00, %rax   /* disable all watchpoints */
movq%rax,%dr7
jmp done_store_dr
 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kernel patch needed for wine?

[Tijl Coosemans]

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 CURRENT amd64 however World of warcraft still
> segfaults even though execute bit is disabled in BIOS.
> 
> I guess I am just confused on how linux fixed this with this patch
> 
> http://bugs.winehq.org/attachment.cgi?id=29155

Wine translates signals and their siginfo into windows exceptions.
In the test case you posted earlier you should try install the
sighandler with sigaction(2) and the SA_SIGINFO flag. Then print
the siginfo struct when you receive the signal and compare that to
Linux or FreeBSD/i386.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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 although the hitachi hdd specs
> referenced in the pr say that this will not cause proper load/unload
> and thus an emergency unload will occur which reduces the life
> expectancy of hdds dramatically (20.000 shutdowns vs. 600.000
> shutdowns). unfortunately the discussion back then didn't come up
> with any sort of decision/patch.
> 
> attached you'll find a very simple patch which issues
> ATA_STANDBY_IMMEDIATE instead of ATA_FLUSHCACHE during hdd spin down.
> 
> could somebody with hdd knowledge comment on this? this matter seems
> quite important since there may be a chance that the current spin
> down mechanism in freebsd damages hdds!

> Index: sys/dev/ata/ata-disk.c
> ===
> --- sys/dev/ata/ata-disk.c  (revision 202848)
> +++ sys/dev/ata/ata-disk.c  (working copy)
> @@ -191,8 +191,9 @@
>  {
>  struct ata_device *atadev = device_get_softc(dev);
>  
> -if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE)
> -   ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0);
> +if (atadev->param.support.command2 & ATA_SUPPORT_STANDBY)

This is the wrong bit. ATA_SUPPORT_STANDBY indicates whether a drive
can be powered up straight into standby mode.

The ATA_STANDBY_IMMEDIATE command is part of the standard power
management feature set, so this line should be:

if (atadev->param.support.command1 & ATA_SUPPORT_POWERMGT)

> +   ata_controlcmd(dev, ATA_STANDBY_IMMEDIATE, 0, 0, 0);
> +
>  return 0;
>  }

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: heap limits: mmap(2) vs. break(2) on i386

[Tijl Coosemans]

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 secs
>filesize infinity kB
>datasize  2097152 kB
>stacksize   65536 kB
>coredumpsize infinity kB
>memoryuseinfinity kB
>memorylocked infinity kB
>maxprocesses 5547
>openfiles   2
>sbsize   infinity bytes
>vmemoryuse   infinity kB
> 
> Running ktrace I see:
> 
>9154 java CALL  
> mmap(0,0x4400,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0x,0,0)
>9154 java RET   mmap -1 errno 12 Cannot allocate memory
>9154 java CALL  write(0x1,0xbf9fe378,0x2b)
>9154 java GIO   fd 1 wrote 43 bytes
> "Error occurred during initialization of VM

On i386 a process has only 3GiB of address space. If you reserve 2GiB
for datasize (sbrk), there's less than 1GiB available for mmap. Unless
you have a program that still uses sbrk and needs 2GiB you should make
maxdsiz much smaller. Since FreeBSD 7 malloc can use mmap besides sbrk
so you can set maxdsiz to a really small value if you want to.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mmap/munmap with zero length

[Tijl Coosemans]

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=0. being able to
>> succesfully alocate memory which cannot be removed doesn't seem
>> logical to me.
> 
> This should fix it:
> 
> --- //depot/user/jhb/acpipci/vm/vm_mmap.c
> +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c
> @@ -229,7 +229,7 @@
> 
> fp = NULL;
> /* make sure mapping fits into numeric range etc */
> -   if ((ssize_t) uap->len < 0 ||
> +   if ((ssize_t) uap->len <= 0 ||
> ((flags & MAP_ANON) && uap->fd != -1))
> return (EINVAL);

Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause
an error.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: diagnosing freezes (DRI?)

[Tijl Coosemans]

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 currently got both tinderbox and a
>> make -j 16 buildworld going on a loop in the hope that I can trigger
>> it again.
>> 
>> Being the idiot I am, I had encrypted swap enabled and so savecore
>> didn't save anything. Won't make that mistake twice.
>> 
>> I'm currently using a world compiled WITH_DEBUG but is there
>> anything else I can do?
> 
> If it is locking the whole system, then a core is really our best
> shot. If you can extract anything useful from xorg.log or setting
> hw.dri.0.debug that also might be of use.
> 
> I'm running on 2 cores, but it is possible that some locking issue
> exists.  All of the driver specific ioctls are run under a lock
> though.

I have the same problem with a Radeon Mobility 9700 (r300) on 7-STABLE.
The entire system freezes, but it happens very rarely. I took a quick
look at the drm code for locking issues and found one thing that seems
suspicious. Patch attached. I'm not familiar with the code, so I don't
know if it's correct or even related this problem.
--- sys/dev/drm/drm_bufs.c.orig 2009-04-11 15:10:56.0 +0200
+++ sys/dev/drm/drm_bufs.c  2009-04-11 15:11:33.0 +0200
@@ -173,7 +173,6 @@
/* Prevent a 2nd X Server from creating a 2nd lock */
DRM_LOCK();
if (dev->lock.hw_lock != NULL) {
-   DRM_UNLOCK();
free(map->handle, DRM_MEM_MAPS);
free(map, DRM_MEM_MAPS);
return EBUSY;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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 of supported load/unloads and emergency unloads.
> Emergency unloads are invoked when the heads are still loaded and
> power fails.

Quoting that document:

10.4.1 Emergency unload

(...)

Emergency unload is intended to be invoked in rare situations. Because
this operation is inherently uncontrolled, it is more mechanically
stressful than a normal unload.

A single emergency unload operation is more stressful than 100 normal
unloads. Use of emergency unload reduces the start/stop life of the HDD
at a rate at least 100X faster than that of normal unload, and may
damage the HDD.

10.4.2 Required power-off sequence

(...)

You may then turn off the HDD in the following order:
  • Issue Standby Immediate or sleep command.
  • Wait until COMMAND COMPLETE STATUS is returned. (It may take up to
350ms in typical case).
  • Terminate power to HDD.
This power-down sequence should be followed for entry into any system
power-down state, or system suspend state, or system hibernation state.
In a robustly designed system, emergency unload is limited to rare
scenarios such as battery removal during operation.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

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 Emergency Unload count. So even if an
> ATA_STANDBY_IMMEDIATE command may introduce additional Load/Unload
> stress on reboot it is not as bad as the stress causes by an Emergency
> Unload on shutdown. Of course this only applies if the "click" sound is
> really caused by an Emergency Unload. Is there a way to figure out?
> Maybe the S.M.A.R.T. feature records the two kinds of power-offs.

Emergency Unload is called Power-Off_Retract_Count in SMART output.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders

[Tijl Coosemans]

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 looking for libusb & libftdi.  If
> I just type gmake, it can't find it, but if I manually edit the
> Makefiles to add -I/usr/local/include, it can.  Obviously, manually
> editing the makefiles is *not* the right way to fix it (plus it's
> driving me crazy).

./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib"

They should consider using pkg-config in their configure script to
locate libusb and libftdi.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: need help with sigaction and siginfo_t

[Tijl Coosemans]

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 debugging my program with gdb.
> my output is :
> > pid 0
> and in gdb i have :
> {
> si_signo = 30,
> si_errno = 0,
> si_code = 0,
> si_pid = 0,
> si_uid = 0,
> si_status = 0,
> si_addr = 0x2,
> si_value = {sigval_int = 0,sigval_ptr = 0x0},
> si_band = 0,
> __spare__ = {0, 0, 0, 0, 0, 0, 0}
> }
> 
> anyone have an idea why my siginfo_t is empty please ?

Well, it isn't empty. It's just that the si_pid field usually isn't
set. It probably should be, but either way, your code should work if
you send signals with sigqueue(2) instead of kill(2).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: need help with sigaction and siginfo_t

[Tijl Coosemans]

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 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 debugging my program with gdb.
>>> my output is :
>>> > pid 0
>>> and in gdb i have :
>>> {
>>> si_signo = 30,
>>> si_errno = 0,
>>> si_code = 0,
>>> si_pid = 0,
>>> si_uid = 0,
>>> si_status = 0,
>>> si_addr = 0x2,
>>> si_value = {sigval_int = 0,sigval_ptr = 0x0},
>>> si_band = 0,
>>> __spare__ = {0, 0, 0, 0, 0, 0, 0}
>>> }
>>>
>>> anyone have an idea why my siginfo_t is empty please ?
>>
>> Well, it isn't empty. It's just that the si_pid field usually isn't
>> set. It probably should be, but either way, your code should work if
>> you send signals with sigqueue(2) instead of kill(2).
> 
> Thank you for the reply,
> i have tried to use sigqueue but after a "undefined reference to
> `sigqueue'" compilation error i have opened signal.h and found this
> define : 
> 
> #if 0
> /*
>   * PR: 35924
>   * XXX we don't actually have these.  We set _POSIX_REALTIME_SIGNALS to 
>   * -1 to show that we don't have them, but this symbol is not necessarily
>   * in scope (in the current implementation), so we can't use it here.
>   */
> int sigqueue(__pid_t, int, const union sigval);
> #endif
> 
> I'm working on FreeBSD 5.5-RELEASE-p14, do you have any idea ?

Hmm, looks like it has only been added in FreeBSD 7. If you can't
upgrade, you'll have to use some more advanced IPC mechanism I'm
afraid.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ptrace(2) race testcase + proposed patch

[Tijl Coosemans]

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 during the wait4 call.

The problem occurs when the stopped child process returns from the
ptracestop() call in sys/kern/kern_sig.c:issignal() after the parent
has already returned from the next PT_ATTACH. Then the signal that
caused the process to stop is taken off the sigqueue, but this may
already be a new SIGSTOP from the next PT_ATTACH. The solution is to
take the signal off the queue before calling ptracestop().

A second cause for the problem is in sys/kern/sys_process.c:kern_ptrace()
where PT_ATTACH sets td_xsig of a thread to SIGSTOP. If this thread
then returns from ptracestop() (returning td_xsig) and it was previously
stopped by a SIGSTOP, the new SIGSTOP is ignored and deleted at the end
of issignal(). The solution is to deliver the signal via td_xsig only
when the process is currently stopped (and now continuing) and
otherwise (PT_ATTACH) using psignal(). This is similar to equivalent
code in NetBSD.

I was hoping if someone could review this to make sure I did the right
thing, because I'm not entirely familiar with this code.
#include 
#include 
#include 
#include 
#include 
#include 

int main( void ) {

pid_t pid;
int status;

/* fork dummy child process */
pid = fork();
if( pid == 0 ) {
/* child does nothing */
for( ; ; ) {
sleep( 1 );
}
} else {
/* parent */
sleep( 1 );
for( ; ; ) {
/* loop: attach, wait, detach */
printf( "attach " );
fflush( stdout );
ptrace( PT_ATTACH, pid, ( caddr_t ) 0, 0 );

printf( "wait " );
fflush( stdout );
wait4( pid, &status, 0, NULL );

printf( "detach " );
fflush( stdout );
ptrace( PT_DETACH, pid, ( caddr_t ) 1, 0 );

printf( "\n" );
fflush( stdout );
}
}

return 0;
}
--- sys/kern/kern_sig.c.orig2007-07-19 10:49:16.0 +0200
+++ sys/kern/kern_sig.c 2007-07-26 01:37:22.0 +0200
@@ -2543,6 +2543,20 @@
continue;
}
if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) {
+   ksiginfo_t ksi;
+
+   /*
+* clear old signal.
+* XXX shrug off debugger, it causes siginfo to
+* be thrown away.
+*/
+   ksiginfo_init( &ksi );
+   sigqueue_get(&td->td_sigqueue, sig, &ksi);
+#ifdef KSE
+   if (td->td_pflags & TDP_SA)
+   SIGADDSET(td->td_sigmask, sig);
+#endif
+
/*
 * If traced, always stop.
 */
@@ -2550,20 +2564,7 @@
newsig = ptracestop(td, sig);
mtx_lock(&ps->ps_mtx);
 
-#ifdef KSE
-   if (td->td_pflags & TDP_SA)
-   SIGADDSET(td->td_sigmask, sig);
-
-#endif
if (sig != newsig) {
-   ksiginfo_t ksi;
-   /*
-* clear old signal.
-* XXX shrug off debugger, it causes siginfo to
-* be thrown away.
-*/
-   sigqueue_get(&td->td_sigqueue, sig, &ksi);
-
/*
 * If parent wants us to take the signal,
 * then it will leave it in p->p_xstat;
@@ -2585,6 +2586,9 @@
if (SIGISMEMBER(td->td_sigmask, sig))
continue;
signotify(td);
+   } else {
+   /* Add old signal back. */
+   sigqueue_add(&td->td_sigqueue, sig, &ksi);
}
 
/*
--- sys/kern/sys_process.c.orig 2007-08-02 15:53:10.0 +0200
+++ sys/kern/sys_process.c  2007-08-02 19:49:56.0 +0200
@@ -779,14 +779,15 @@
sx_xunlock(&proctree_lock);
proctree_locked = 0;
}
-   /* deliver or queue signal */
-   thread_lock(td2);
-   td2->td_flags &= ~TDF_XSI

Re: i386 page fault clobbers error code in trap frame

[Tijl Coosemans]

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 objective should be to keep applications
> working.

Well, the comment is correct except in case of a page fault. But this is 
different from stable. In stable si_addr is a copy of tf_err, which, 
because of the kludge, holds the fault address in case of a page 
fault... I'm glad to see this code has been cleaned up.


pgpE7JYOK18bJ.pgp
Description: PGP signature

Re: i386 page fault clobbers error code in trap frame

[Tijl Coosemans]

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. Maybe
> one could abuse si_code to contain eva. Sorry for asking a question
> that has already been answered but where is eva being put currently?

si_addr doesn't contain the faulting pc, it contains the address that 
caused the page fault (i.e. eva). pc at the time of the fault is stored 
in the sigcontext as sc_eip.

But siginfo is ok. The problem is in sigcontext (mostly a copy of 
trapframe), where sc_err is incorrect. However, it appears that all the 
relevant code has changed significantly in CURRENT to the point that 
the offending line can simply be removed. It would be nice if somebody 
could review/verify/test this, because I don't have CURRENT installed 
at the moment.

--- sys/i386/i386/trap.c.orig   Sun Jul 30 18:27:21 2006
+++ sys/i386/i386/trap.cSun Jul 30 18:27:56 2006
@@ -777,9 +777,6 @@
return (-1);
}

-   /* kludge to pass faulting virtual address to sendsig */
-   frame->tf_err = eva;
-
return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV);
 }


pgpIK9jSHF9jK.pgp
Description: PGP signature

i386 page fault clobbers error code in trap frame

[Tijl Coosemans]

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?

The reason I'm asking this is that Wine wants to know the error code in 
case of a page fault (the No eXec bit (AMD) and the read/write bit 
specifically).


pgpeKHupw8FpA.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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 preserved?  It
> > > sounds like %fs is never set to a value in Wine.
> >
> > Yes, it was a combination of compiler optimizations and an inline
> > assembly block missing __volatile__.
>
> does this mean that wine will work from now on?
> i.e. is the fix being fed back into wine sources?

Not yet. Windows9x mode should work again as well as threading and TLS, 
but there are still some open issues, mainly with exception handling 
and file access. Exception handling was completely broken and is now 
mostly working, but sometimes gets stuck in a loop generating 
exceptions and eventually overflowing the stack.

I'll submit patches once Wine passes the most important unit tests, 
unless someone already wants to have a look at them of course...


pgpeDoM6mVXmd.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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.
>
> The kernel should preserve %fs across syscalls, traps, and faults. 
> Can you point to a specific case where %fs is not preserved?  It
> sounds like %fs is never set to a value in Wine.

Yes, it was a combination of compiler optimizations and an inline 
assembly block missing __volatile__.



pgpwq6J5daZJN.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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, but this seems to
> >>> trigger other problems, so use at your own risk. If you want to
> >>> try them, place them in the port's files/ directory and add a
> >>> line containing "USE_AUTOTOOLS= autoconf:259" to the Makefile.
> >>> This seems to break wine+libpthread, so I've also changed the
> >>> port to use libthr instead.
> >>>
> >>> For the libpthread experts, I haven't investigated that much
> >>> further yet, but libpthread seems to fail in create_stack() from
> >>> _pthread_create() from _thr_start_sig_daemon().
> >>
> >> See my response to this in a previous reply to this thread. 
> >> libthr and libpthread use LDT's for TLS.  WINE is stomping on them
> >> because it doesn't properly create LDTs.  This is not a problem
> >> with either of the thread libraries and this issue has been known
> >> ever since we implemented TLS years ago.
> >
> > And as I stated later on in that thread, I don't see where
> > libpthread and libthr still use LDT entries. As far as I understand
> > the code, instead of using an LDT entry per thread (as it sure used
> > to be), only one single GDT entry is used whose base address is
> > updated during a context switch. Looking at the cvs history, it has
> > been working like this since a couple commits of Peter Wemm about a
> > year ago.
> >
> > And if nothing but Wine uses the LDT, Wine's static allocation of
> > LDT entries can't be the problem.
>
> Look, we use %gs for TLS, period.  Go see
> libpthread/arch/i386/i386/pthread_md.c for how libpthread does it. 
> TLS would not work without setting aside a register for the threads
> library (and rtld) to use.

Aaagghhh :)

What you say is true of course, but %gs points to a GDT entry, not LDT. 
libpthread and libthr no longer use LDT entries...

There would be a problem of course if Wine or Windows programs 
change %gs. Wine does seem to touch %gs but I've never actually seen it 
change. It's always 0x001B, which is the correct value (GUGS_SEL).

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.


pgpMV6kS6NpT4.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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's files/ directory and add a line
> > containing "USE_AUTOTOOLS= autoconf:259" to the Makefile. This
> > seems to break wine+libpthread, so I've also changed the port to
> > use libthr instead.
> >
> > For the libpthread experts, I haven't investigated that much
> > further yet, but libpthread seems to fail in create_stack() from
> > _pthread_create() from _thr_start_sig_daemon().
>
> See my response to this in a previous reply to this thread.  libthr
> and libpthread use LDT's for TLS.  WINE is stomping on them because
> it doesn't properly create LDTs.  This is not a problem with either
> of the thread libraries and this issue has been known ever since we
> implemented TLS years ago.

And as I stated later on in that thread, I don't see where libpthread 
and libthr still use LDT entries. As far as I understand the code, 
instead of using an LDT entry per thread (as it sure used to be), only 
one single GDT entry is used whose base address is updated during a 
context switch. Looking at the cvs history, it has been working like 
this since a couple commits of Peter Wemm about a year ago.

And if nothing but Wine uses the LDT, Wine's static allocation of LDT 
entries can't be the problem.


pgpgxQgPdEMne.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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 area
>  *  0x8000 - 0x8100  the shared heap
>  *  ???- ??? the PE binary load address (usually
> starting at 0x0040)
>
> The first two are particularly important for WINE running in win98
> (or earlier) emulation mode, which is currently completely broken on
> FreeBSD, since those two memory ranges tend to be unavailable.

The reason for the second range is that wine is located way at the end 
of the 2G range (0x7bf0). FreeBSD's mmap preserves heap space after 
that (for brk(2) style allocations). This is about 512Mb by default so 
everything in 0x7bf0-0x9bf0 is unavailable (unless MAP_FIXED is 
used of course).

The DOS area should be available but can't be allocated by wine because 
of a FreeBSD specific quirk in its code to work arround another mmap 
related problem.

Both problems can be solved by locating wine at say 0x2000 instead 
of 0x7bf0. That leaves plenty of space for the windows executable 
and allows us to remove mmap related freebsd quirks from wine's code.

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's files/ directory and add a line 
containing "USE_AUTOTOOLS= autoconf:259" to the Makefile. This seems to 
break wine+libpthread, so I've also changed the port to use libthr 
instead.

For the libpthread experts, I haven't investigated that much further 
yet, but libpthread seems to fail in create_stack() from 
_pthread_create() from _thr_start_sig_daemon().

> The preloader bit from which this is quoted is WINE's "own shared
> object loader that reserves memory that is important to Wine, and
> then loads the main binary and its ELF interpreter", and obviously
> does not work right on FreeBSD. I'm not sure whether it can be made
> to or not, perhaps somebody familiar with both our VM and runtime
> linker could take a look.

The preloader isn't used on FreeBSD. You either run wine-kthread or 
wine(-pthread) directly. The reason for the preloader in linux is 
mainly exec-shield which makes the mapping of DSOs unpredictable.

> http://bugs.winehq.org/show_bug.cgi?id=5732

Do the above mentioned patches solve your second issue here (PE exec 
location)?

> The other big issue with WINE on FreeBSD seems to be our threading
> support. WINE quite reliably manages to confuse libpthread, see
> http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/100701. On SMP
> machines, I've even been able to trigger kernel panics with WINE (in
> win2k+ emulation mode) by merely hitting the close button on a
> windows application (and WINE subsequently shutting down):
> 
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/026219.html. 
>
> WINE's threads interface can be found in loader/pthread.c and
> loader/kthread.c - again, it would be great, if someone to whom that
> sort of code means more than just random gibberish could take a look.

Wine does some freaky stack manipulations. I think that may interfere 
with the way our threading libs handle the stack (allocation etc.). But 
I am just guessing here really.
--- configure.ac.orig   Mon Jul 10 18:01:07 2006
+++ configure.acMon Jul 24 15:42:41 2006
@@ -149,7 +149,7 @@
 dnl Check for -lresolv for Mac OS X/Darwin
 AC_CHECK_LIB(resolv,res_9_init)
 dnl Check for -lpthread
-AC_CHECK_LIB(pthread,pthread_create,AC_SUBST(LIBPTHREAD,"-lpthread"))
+AC_CHECK_LIB(thr,pthread_create,AC_SUBST(LIBPTHREAD,"-lthr"))
 
 AC_SUBST(XLIB,"")
 AC_SUBST(XFILES,"")
@@ -1116,18 +1116,18 @@
ac_cv_ld_rpath="yes",ac_cv_ld_rpath="no")])
 if test "$ac_cv_ld_rpath" = "yes"
 then
-  AC_SUBST(LDEXERPATH,["-Wl,--rpath,\\\$\$ORIGIN/\`\$(RELPATH) 
\$(bindir) \$(libdir)\`"])
-  AC_SUBST(LDDLLRPATH,["-Wl,--rpath,\\\$\$ORIGIN/\`\$(RELPATH) 
\$(dlldir) \$(libdir)\`"])
+  AC_SUBST(LDEXERPATH,["-Wl,--rpath,${libdir}"])
+  AC_SUBST(LDDLLRPATH,["-Wl,--rpath,${libdir}"])
 fi
 
 case $host_cpu in
   *i[[3456789]]86* | x86_64)
-AC_CACHE_CHECK([whether we can relocate the executable to 
0x7bf0], ac_cv_ld_reloc_exec,
-  [WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x7bf00400],
+AC_CACHE_CHECK([whether we can relocate the executable to 
0x2000], ac_cv_ld_reloc_exec,
+  [WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x2400],
ac_cv_ld_reloc_exec="yes", 
ac_cv_ld_reloc_exec="no")])
 if test "$ac_cv_ld_reloc_exec" = "yes"
 then
-  LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x7bf00400"
+  LDEXECFLAGS="$

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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 used static ldt allocation

Wine's LDT code could probably be improved to bring in LDT_AUTO_ALLOC 
and/or use the GDT entry for %fs through i386_set_fsbase() for TLS 
instead of allocating an LDT entry (per thread). But, I don't think 
this is currently a problem. As far as I can see FreeBSD's TLS support 
doesn't use the LDT (anymore) so wine's static ldt allocation can't 
possibly interfere with it.

> I dont know details but judging from what linux does I think it might
> be that wine requires more then one GDT entry for TLS areas. at least
> comment in linux sources suggests so.
>
> linux has 3 GDT entries for TLS while fbsd just 1.

Wine on FreeBSD doesn't use the GDT (yet?). It allocates LDT entries for 
TLS which should work just as well.

In any case, FreeBSD and Linux don't differ that much in this.

FreeBSD has 2 GDT entries available, one for %gs which is used by the 
threading libs (following http://people.redhat.com/drepper/tls.pdf I 
suppose) and one for %fs which is used by win32 code so wine could use 
this instead of the LDT way. The related (undocumented) libc functions 
are i386_get_fsbase, i386_set_fsbase, i386_get_gsbase and 
i386_set_gsbase.

Linux reserves 3 GDT entries, that can be manipulated through one 
syscall (set_thread_area) and then it's up to the user to point %fs 
or %gs (or some other selector?) to one of these entries.


pgpohNessjd2G.pgp
Description: PGP signature

Re: WINE vs. FreeBSD

[Tijl Coosemans]

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 used static ldt allocation

Wine's LDT code could probably be improved to bring in LDT_AUTO_ALLOC 
and/or use the GDT entry for %fs through i386_set_fsbase() for TLS 
instead of allocating an LDT entry (per thread). But, I don't think 
this is currently a problem. As far as I can see FreeBSD's TLS support 
doesn't use the LDT (anymore) so wine's static ldt allocation can't 
possibly interfere with it.

> I dont know details but judging from what linux does I think it might
> be that wine requires more then one GDT entry for TLS areas. at least
> comment in linux sources suggests so.
>
> linux has 3 GDT entries for TLS while fbsd just 1.

Wine on FreeBSD doesn't use the GDT (yet?). It allocates LDT entries for 
TLS which should work just as well.

In any case, FreeBSD and Linux don't differ that much in this.

FreeBSD has 2 GDT entries available, one for %gs which is used by the 
threading libs (following http://people.redhat.com/drepper/tls.pdf I 
suppose) and one for %fs which is used by win32 code so wine could use 
this instead of the LDT way. The related (undocumented) libc functions 
are i386_get_fsbase, i386_set_fsbase, i386_get_gsbase and 
i386_set_gsbase.

Linux reserves 3 GDT entries, that can be manipulated through one 
syscall (set_thread_area) and then it's up to the user to point %fs 
or %gs (or some other selector?) to one of these entries.


pgpGNTlDMyfSU.pgp
Description: PGP signature

Re: Standard sbc and pcm support in GENERIC kernel?

[Tijl Coosemans]

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 a box...

I have an old toshiba which also needs PNPBIOS in 4-STABLE and
when I tried 5-CURRENT sound just worked. Of course that doesn't say
anything about your setup...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"