questions on nonsleepable lock
Hello All, Can someone point me out or explain the technical details of this kernel panic: sleeping thread (tid 100093, pid 2676) owns nonsleepable lock panic: sleeping thread -- -- Is this caused by incorrect use of mutex or semaphores? Is this related to kernel scheduling? Can this be addressed at the user process? I've tried looking throught the freebsd mailing list archives and documentations but coudn't find a real good answer to solve or prevent this problem. Im using freebsd 6.1 with SMP enabled on a Xeon dual core hardware. The system has several busy applications running, But the load average is very minimal, around 8.55 and no process hogging the CPU. So I expect my system should be running smoothly without in problem. I appreciate any help. Thanks a lot, Mon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How stable is 7 now? How to cvs it?
Hello! I have heard that 7 is very stable since november and much better (perfomance wise since GIANT lock have been deleted completely) since that time. Is it true? Also, how to cvsup the sources? I tried RELENG_7 and HEAD tags and no sources and docs fetched at all. Which is the correct tag? -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How stable is 7 now? How to cvs it?
Artem Kuchin wrote: Also, how to cvsup the sources? I tried RELENG_7 and HEAD tags and no sources and docs fetched at all. Which is the correct tag? Use the following string in your csup file: *default release=cvs tag=. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
Tijl Coosemans wrote:
On Wednesday 01 August 2007 16:58:46 Anish Mistry wrote:
On Tuesday 31 July 2007, Tijl Coosemans wrote:
On Friday 13 July 2007 20:08:59 Volker wrote:
On 07/11/07 20:42, John Baldwin wrote:
This patch attempts to remove a gross hack with a slightly less
gross hack in order to avoid clobbering data in signal info that
Wine needs. In 7 this was fixed by a major change to how the
kernel manages signals internally, and that change is too large
to be MFC'd, hence this lighter weight patch. It has already
been tested by the folks working on Wine, but I would like a bit
more widespread testing before I commit it. Please test this
patch and let me know if anything breaks. Note that this patch
is only for i386.
http://www.FreeBSD.org/~jhb/patches/sig_eva.patch
I've patched and recompiled world + kernel using your patch. I
can confirm it does not hurt but what does it good (my wine
already ran fine despite some DDE and performance issues)? What
to look for especially - any specific test procedures?
Could you try Mozilla Firefox (for Windows) with and without this
patch?
I applied the patch and recompiled my kernel. The Firefox install
worked fine, but when I go to launch it I get:
wine firefox.exe
fixme:actctx:parse_depend_manifests Could not find dependent assembly
LMicrosoft.Windows.Common-Controls
fixme:iphlpapi:NotifyAddrChange (Handle 0xbf6db5e8, overlapped
0xbf6db5cc): stub
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59}
not registered
err:ole:CoGetClassObject no class object
{4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for context
0x1
err:seh:segv_handler Got unexpected trap 0
Bus error (core dumped)
Does the patch require 6-STABLE?
No, if it applies cleanly, it's ok. If you're interested, there are
more patches at http://wiki.freebsd.org/Wine.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Hi,
I just tried patch-fbsd-7 and patch-wine-0.9.43. Macromedia Flash8
works, however Dreamweaver8 doesn't.
It shows splash screen and then crashes.
...
file_set_error: Bad address
file_set_error: Bad address
wine: Unhandled page fault on read access to 0x at address
0x95fa37 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit
code (0x0095fa37).
file_set_error: Bad address
file_set_error: Bad address
Register dump:
CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b
EIP:0095fa37 ESP:0034f2dc EBP: EFLAGS:00010206( - 00 - RIP1)
EAX: EBX:000c ECX:0034f590 EDX:0001
ESI:0174c1e0 EDI:015cc378
Stack dump:
0x0034f2dc: 30e0
0x0034f2ec:
0x0034f2fc: 015cc378 0008
0x0034f30c: 012699c0
0x0034f31c: 017320e8 017320dc 0002 017320f4
0x0034f32c: 017320d8 000a 01269a30 02cf33a8
0200: sel=1007 base=00112000 limit=1fff 32-bit rw-
Backtrace:
0x0095fa37: movl0x0(%eax),%ecx
Modules:
Module Address Debug info Name (114 modules)
PE35- 3a6000 Deferredmsvcr71
PE3b- 42b000 Deferredmsvcp71
PE43- 501000 Deferredlibeay32
PE51- 537000 Deferredssleay32
PE54- 642000 Deferredmfc71u
PE80- 1609000 Export dreamweaver
PE 1000-10283000 Deferredfireworks library
PE 1200-121ae000 Deferredxerces-c_2_6
PE 1300-13191000 Deferredmmxptresources
PE 3000-3002 Deferredlibcurl
PE 3010-3012 Deferredcoretypes
PE 3090-30912000 Deferrednetio
PE 30e0-3113e000 Deferredresources
PE 3210-32181000 Deferredworkspace
PE 4a80-4a893000 Deferredicuuc30
PE 4ad0-4b52d000 Deferredicudt30
PE 70d0-70ea Deferredgdiplus
ELF 7bf0-7bf03000 Deferredwine-loader
ELF 7df02000-7df2d000 Deferredld-elf.so.1
ELF 7df35000-7e049000 Deferredlibwine.so.1
ELF 7e049000-7e05c000 Deferredlibthr.so.3
ELF 7e05c000-7e159000 Deferredlibc.so.7
ELF 7e162000-7e1fe000 Deferredntdllelf
\-PE 7e17-7e1fe000 \ ntdll
ELF 7e30-7e315000 Deferredlibm.so.5
ELF 7e315000-7e437000 Deferredkernel32elf
\-PE 7e33-7e437000 \ kernel32
ELF 7e437000-7e572000 Deferreduser32elf
\-PE 7e45-7e572000 \ user32
ELF 7e572000-7e609000
Re: Call for testing: patch that helps Wine on 6.x
On Wednesday 15 August 2007 12:54:50 Ganbold wrote: I just tried patch-fbsd-7 and patch-wine-0.9.43. Macromedia Flash8 works, however Dreamweaver8 doesn't. It shows splash screen and then crashes. I think this is because of copy/crack protection code failing. At least that seems to be the cause for similar problems with other programs. There's no solution yet. Any idea how to resolve this issue? Will the patch on http://bugs.winehq.org/show_bug.cgi?id=4139 help to this issue? No, that was due to a problem in FreeBSD, which has been fixed now in both current and stable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Static linking and memory usage
In response to the original post: The kernel's ELF linker/loader for executables will share the text and read-only segments for static executables. Thanks, this is what I was looking for - I kind of thought it worked that way but just wanted to check, (because if not I am wasting a lot of memory!) cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
On Wednesday 15 August 2007 12:54:50 Ganbold wrote: I just tried patch-fbsd-7 and patch-wine-0.9.43. Macromedia Flash8 works, however Dreamweaver8 doesn't. It shows splash screen and then crashes. Could you send me the output of: env WINEDEBUG=+module wine /path/to/dreamweaver.exe outfile ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
twa is giant locked in 7-Current or everywhere?
Hi! When i installed twas driver on 6.2-STABLE it said [FAST] i presumed that it measn that twa is giant-lock free. Now, after installing 7-CURRENT i see Aug 15 17:00:02 omni3 kernel: 3ware device driver for 9000 series storage controllers, version: 3.70.03.007 Aug 15 17:00:02 omni3 kernel: twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0x8800-0x89ff,0x8a20-0x8a200fff irq 16 at devic Aug 15 17:00:02 omni3 kernel: twa0: [GIANT-LOCKED] Aug 15 17:00:02 omni3 kernel: twa0: [ITHREAD] So, it says GIANT-LOCKED and then ITHREAD. Apparently, i have no real understaning what those words mean. COuld anyone explain the meaning of FAST ITHREAD Giant-locked is self explanatory and.. bad. Thank you. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa is giant locked in 7-Current or everywhere?
On Wed, Aug 15, 2007 at 09:09:33PM +0400, Artem Kuchin wrote: Hi! When i installed twas driver on 6.2-STABLE it said [FAST] i presumed that it measn that twa is giant-lock free. Now, after installing 7-CURRENT i see Aug 15 17:00:02 omni3 kernel: 3ware device driver for 9000 series storage controllers, version: 3.70.03.007 Aug 15 17:00:02 omni3 kernel: twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0x8800-0x89ff,0x8a20-0x8a200fff irq 16 at devic Aug 15 17:00:02 omni3 kernel: twa0: [GIANT-LOCKED] Aug 15 17:00:02 omni3 kernel: twa0: [ITHREAD] So, it says GIANT-LOCKED and then ITHREAD. Apparently, i have no real understaning what those words mean. COuld anyone explain the meaning of FAST ITHREAD Giant-locked is self explanatory and.. bad. I think 6.x doesn't display the GIANT-LOCKED messages because users were freaking out too much after they were added at an earlier point in 6.x development (Q: why is this driver suddenly giant locked? A: It's always been giant locked, now this fact is displayed as a note to developers.). While it's true that a non-giant locked driver would be better, it's not as bad as you might think because almost nothing else requires giant for most workloads thesedays (see http://wiki.freebsd.org/SMPTODO), so in those workloads performance will not be worse because of it. If you are really bothered by this you can enable mutex profiling to check how much of a problem it is for you. Kris pgpuvJUaJzZNh.pgp Description: PGP signature
Re: How stable is 7 now? How to cvs it?
On Wed, Aug 15, 2007 at 11:07:42AM +0400, Artem Kuchin wrote: Hello! I have heard that 7 is very stable since november and much better (perfomance wise since GIANT lock have been deleted completely) since that time. Is it true? No, it is still lurking in some corners of the kernel, but almost all workloads no longer require it. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How stable is 7 now? How to cvs it?
On Wed, 15 Aug 2007, Artem Kuchin wrote: Hello! I have heard that 7 is very stable since november and much better (perfomance wise since GIANT lock have been deleted completely) since that time. Partially. It is pretty stable right now for the most part since we're in a code freeze, but you might want to wait for the first beta before you jump in. Also, GIANT is still there in some places, but a LOT fewer now than before. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa is giant locked in 7-Current or everywhere?
The TWA driver uses an INTR_FAST handler, meaning that it forgoes the traditional interrupt-thread model in FreeBSD. There are good and bad tradeoffs with doing that, and I'm always happy to discuss the topic in detail with those who are interested. In any case, most of the codepaths inside of the driver were still covered by Giant, just not the low-level interrupt handler. In 7-CURRENT, I changed the CAM (SCSI) layer API a bit, and the TWA driver was an unfortunate victim of the change. The easy fix was to revert the interrupt handler to being fully Giant-covered. There should be very little difference in actual performance unless the interrupt is being shared with another device. Even then the difference should be minor. Pushing the TWA source forward so that it is Giant-free would be an interesting task. Unfortunately, the existing code relies heavily on spin locks, while CAM requires that Giant-free drivers use sleep locks. Since this code is actively maintained by AMCC/3Ware, some amount of coordination would be needed with them to ensure the changes are accepted. Scott Artem Kuchin wrote: Hi! When i installed twas driver on 6.2-STABLE it said [FAST] i presumed that it measn that twa is giant-lock free. Now, after installing 7-CURRENT i see Aug 15 17:00:02 omni3 kernel: 3ware device driver for 9000 series storage controllers, version: 3.70.03.007 Aug 15 17:00:02 omni3 kernel: twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0x8800-0x89ff,0x8a20-0x8a200fff irq 16 at devic Aug 15 17:00:02 omni3 kernel: twa0: [GIANT-LOCKED] Aug 15 17:00:02 omni3 kernel: twa0: [ITHREAD] So, it says GIANT-LOCKED and then ITHREAD. Apparently, i have no real understaning what those words mean. COuld anyone explain the meaning of FAST ITHREAD Giant-locked is self explanatory and.. bad. Thank you. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa is giant locked in 7-Current or everywhere?
Kris Kennaway wrote: On Wed, Aug 15, 2007 at 09:09:33PM +0400, Artem Kuchin wrote: Hi! When i installed twas driver on 6.2-STABLE it said [FAST] i presumed that it measn that twa is giant-lock free. Now, after installing 7-CURRENT i see Aug 15 17:00:02 omni3 kernel: 3ware device driver for 9000 series storage controllers, version: 3.70.03.007 Aug 15 17:00:02 omni3 kernel: twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0x8800-0x89ff,0x8a20-0x8a200fff irq 16 at devic Aug 15 17:00:02 omni3 kernel: twa0: [GIANT-LOCKED] Aug 15 17:00:02 omni3 kernel: twa0: [ITHREAD] So, it says GIANT-LOCKED and then ITHREAD. Apparently, i have no real understaning what those words mean. COuld anyone explain the meaning of FAST ITHREAD Giant-locked is self explanatory and.. bad. I think 6.x doesn't display the GIANT-LOCKED messages because users were freaking out too much after they were added at an earlier point in 6.x development (Q: why is this driver suddenly giant locked? A: It's always been giant locked, now this fact is displayed as a note to developers.). While it's true that a non-giant locked driver would be better, it's not as bad as you might think because almost nothing else requires giant for most workloads thesedays (see http://wiki.freebsd.org/SMPTODO), so in those workloads performance will not be worse because of it. If you are really bothered by this you can enable mutex profiling to check how much of a problem it is for you. Just to set the facts straight, the TWA driver has always been covered by Giant, as I explained in another part of this thread. The indication was just hidden because it used an INTR_FAST handler. As for performance, having Giant-free drivers is still highly important. Not having to compete with the tty subsystem or the USB stack is very important. My recent change to make ATAPI-CAM Giant-free made CD burning a lot more pleasant for people. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please note that we have a mailing list setup at [EMAIL PROTECTED]
dedicated to discussing issues with Wine on FreeBSD, on which we have both
FreeBSD *and* Wine developers ...
- --On Wednesday, August 15, 2007 18:54:50 +0800 Ganbold [EMAIL PROTECTED]
wrote:
Tijl Coosemans wrote:
On Wednesday 01 August 2007 16:58:46 Anish Mistry wrote:
On Tuesday 31 July 2007, Tijl Coosemans wrote:
On Friday 13 July 2007 20:08:59 Volker wrote:
On 07/11/07 20:42, John Baldwin wrote:
This patch attempts to remove a gross hack with a slightly less
gross hack in order to avoid clobbering data in signal info that
Wine needs. In 7 this was fixed by a major change to how the
kernel manages signals internally, and that change is too large
to be MFC'd, hence this lighter weight patch. It has already
been tested by the folks working on Wine, but I would like a bit
more widespread testing before I commit it. Please test this
patch and let me know if anything breaks. Note that this patch
is only for i386.
http://www.FreeBSD.org/~jhb/patches/sig_eva.patch
I've patched and recompiled world + kernel using your patch. I
can confirm it does not hurt but what does it good (my wine
already ran fine despite some DDE and performance issues)? What
to look for especially - any specific test procedures?
Could you try Mozilla Firefox (for Windows) with and without this
patch?
I applied the patch and recompiled my kernel. The Firefox install
worked fine, but when I go to launch it I get:
wine firefox.exe
fixme:actctx:parse_depend_manifests Could not find dependent assembly
LMicrosoft.Windows.Common-Controls
fixme:iphlpapi:NotifyAddrChange (Handle 0xbf6db5e8, overlapped
0xbf6db5cc): stub
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59}
not registered
err:ole:CoGetClassObject no class object
{4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for context
0x1
err:seh:segv_handler Got unexpected trap 0
Bus error (core dumped)
Does the patch require 6-STABLE?
No, if it applies cleanly, it's ok. If you're interested, there are
more patches at http://wiki.freebsd.org/Wine.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Hi,
I just tried patch-fbsd-7 and patch-wine-0.9.43. Macromedia Flash8 works,
however Dreamweaver8 doesn't.
It shows splash screen and then crashes.
...
file_set_error: Bad address
file_set_error: Bad address
wine: Unhandled page fault on read access to 0x at address 0x95fa37
(thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x0095fa37).
file_set_error: Bad address
file_set_error: Bad address
Register dump:
CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b
EIP:0095fa37 ESP:0034f2dc EBP: EFLAGS:00010206( - 00 - RIP1)
EAX: EBX:000c ECX:0034f590 EDX:0001
ESI:0174c1e0 EDI:015cc378
Stack dump:
0x0034f2dc: 30e0
0x0034f2ec:
0x0034f2fc: 015cc378 0008
0x0034f30c: 012699c0
0x0034f31c: 017320e8 017320dc 0002 017320f4
0x0034f32c: 017320d8 000a 01269a30 02cf33a8
0200: sel=1007 base=00112000 limit=1fff 32-bit rw-
Backtrace:
0x0095fa37: movl0x0(%eax),%ecx
Modules:
Module Address Debug info Name (114 modules)
PE35- 3a6000 Deferredmsvcr71
PE3b- 42b000 Deferredmsvcp71
PE43- 501000 Deferredlibeay32
PE51- 537000 Deferredssleay32
PE54- 642000 Deferredmfc71u
PE80- 1609000 Export dreamweaver
PE 1000-10283000 Deferredfireworks library
PE 1200-121ae000 Deferredxerces-c_2_6
PE 1300-13191000 Deferredmmxptresources
PE 3000-3002 Deferredlibcurl
PE 3010-3012 Deferredcoretypes
PE 3090-30912000 Deferrednetio
PE 30e0-3113e000 Deferredresources
PE 3210-32181000 Deferredworkspace
PE 4a80-4a893000 Deferredicuuc30
PE 4ad0-4b52d000 Deferredicudt30
PE 70d0-70ea Deferredgdiplus
ELF 7bf0-7bf03000 Deferredwine-loader
ELF 7df02000-7df2d000 Deferredld-elf.so.1
ELF 7df35000-7e049000 Deferredlibwine.so.1
ELF 7e049000-7e05c000 Deferredlibthr.so.3
ELF 7e05c000-7e159000 Deferredlibc.so.7
ELF 7e162000-7e1fe000 Deferredntdllelf
\-PE 7e17-7e1fe000
6.2 w/ gjournal missing gjournal binary
I built a machine with 6.2 snapshot from April (May/June would not boot). I used the original src with the gjournal patch. I had to manually patch mount.h and vnode.h to complete the patch. everything built and installed fine and my gjournal seems to be working (gjournal loaded and gstats confirm I'm using the journal device). However I just noticed I have no gjournal binary to do my status. I copied a binary from a working 6.2S host running gjournal and the binary seg faults on this host. How can I build just the binary? -- -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
