Re: Panic when starting X with Intel KMS
Al 22/07/2013 23:27, En/na Neel Natu ha escrit: Could you apply the following patch to amd64/amd64/pmap.c and see if it fixes the problem: http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch Neel came with another patch: http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch I've playing with it an the system seemed stable. Neel will commit that patch soon. Gus -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic when starting X with Intel KMS
Show me the verbose dmesg, including the i915 driver attach. Will do it tomorrow morning (I'm UTC+1). Here you have the verbose dmesg and the i915 before the panic: https://dl.dropboxusercontent.com/u/2094962/panic_r252653.tar.gz As a blind shot, try to revert r252653. r252652 works OK. r252653 panics. Any other info let me you. -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic when starting X with Intel KMS
Al 22/07/2013 13:19, En/na Konstantin Belousov ha escrit:
On Mon, Jul 22, 2013 at 12:43:56PM +0200, Gustau P??rez i Querol wrote:
As a blind shot, try to
revert r252653.
r252652 works OK. r252653 panics.
What if, instead of reverting r252653, apply the following:
diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c
index 66f3b0c..78f07f7 100644
--- a/sys/vm/vm_phys.c
+++ b/sys/vm/vm_phys.c
@@ -547,6 +547,8 @@ vm_phys_fictitious_reg_range(vm_paddr_t start, vm_paddr_t
end,
pi = atop(start);
if (pi = first_page atop(end) vm_page_array_size) {
fp = vm_page_array[pi - first_page];
+ for (i = 0; i page_count; i++)
+ fp[i].flags = 0;
malloced = FALSE;
} else
#endif
?
After applying the patch the system panics for the same reason and
the KASSERT didn't evaluate like before. The count now when the system
panics seem to have been overflowed again, you can find the core at:
https://dl.dropboxusercontent.com/u/2094962/core.txt.6
--
Salut i força,
Gustau
---
Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting
Stop top-posting : http://en.wikipedia.org/wiki/Posting_style
O O O Gustau Pérez i Querol
O O O Unitat de Gestió dels departaments
O O O Matemàtica Aplicada IV i Enginyeria Telemàtica
Universitat Politècnica de Catalunya
Edifici C3 - Despatx S101-B
UPC Campus Nord UPC
C/ Jordi Girona, 1-3
08034 - Barcelona
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic when starting X with Intel KMS
The issue happened somewhere before the process exit. Try the patch
below, the idea is that your overflow count is really big, so the
wrong-doer could cause underflow when acting.
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 19be4e0..fcdc6af 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count)
{
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
+ KASSERT(pmap-pm_stats.resident_count = count,
+ (pmap %p resident count underflow %ld %d, pmap,
+ pmap-pm_stats.resident_count, count));
pmap-pm_stats.resident_count -= count;
}
Hi,
the assert doesn't happen (that's resident_count is not bigger than
count). You can find the complete core at:
https://dl.dropboxusercontent.com/u/2094962/core.txt.5
I'm no expert on that, but would this mean that the process, while
freeying mem, causes the kernel to free more maps than the process has?
Any other info during the panic, let me know (I have a second
machine and I can connect to it via serial port).
OTOH, in puzzled because the stack gets corrupted an thus I can't
check which is the offending process (I don't know if that would be of
any use in this situation). It is my understanding that isn't the
process who should be fixed but the kernel side. In this case the stack
corruption isn't that very important (at least this is what I think),
but sometimes it is very handy.
--
Salut i força,
Gustau
---
Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting
Stop top-posting : http://en.wikipedia.org/wiki/Posting_style
O O O Gustau Pérez i Querol
O O O Unitat de Gestió dels departaments
O O O Matemàtica Aplicada IV i Enginyeria Telemàtica
Universitat Politècnica de Catalunya
Edifici C3 - Despatx S101-B
UPC Campus Nord UPC
C/ Jordi Girona, 1-3
08034 - Barcelona
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic when starting X with Intel KMS
Al 21/07/2013 20:51, En/na Konstantin Belousov ha escrit: Hi, the assert doesn't happen (that's resident_count is not bigger than count). You can find the complete core at: https://dl.dropboxusercontent.com/u/2094962/core.txt.5 I do not understand what do you mean, it seems that core.txt.5 has exactly the assertion fired which I added. I was trying to state what you suspected: the condition in the assert did not hold so the kernel paniced. Show me the verbose dmesg, including the i915 driver attach. Will do it tomorrow morning (I'm UTC+1). Did the issue started at some moment, or it is a new install which exhibit the problem from the beginning ? It was an update of a three months old head machine. A dicotomic search would be a long process (I'd say). As a blind shot, try to revert r252653. I tried 252528 (I picked that randomly, only wanting to try to avoid r252695 and r252653 because they state they had to do with pmaps) and it works fine. Tomorrow I'm gonna revert to 252653 and 252652 and see what happens. OFFTOPIC: I used to track src via gitorious but they lag behind and the github repo hasn't the svn revisionm does anyone know of any other git repo with the svn revision? I am sure that the serial console would be useful, but I did not decided yet on where to start looking. Well, if you need some testing via serial be sure it will be possible. -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic when starting X with Intel KMS
Al 17/07/2013 21:05, En/na Gustau Pérez i Querol ha escrit: Hi, I'm having panics or hard freezes when starting X with an Intel video card. The machine is able to start old X+twm without problems but when I try gnome3 (in normal or fallback mode, doesn't matter) the machine panics or hard freezes. This doesn't happen when running X with vesa. With vesa the gnome is able to start in fallback (no composition) mode. Also, an old i386 with an nvidia card is able to run that gnome3 with composition so I'd say it has to do with the intel card. These are the specs of the machine: FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 RAM: 8GB Video Card: Intel chipid=0x00468086 The debugging knobs in the kernel config are there. I can also confirm that I can break to the debugger with CTRL+ALT+ESC before starting X. The world was build without debug symbols. Because the machine runs with an Intel card, I had to use my $work dockstation to obtain a serial port and do the debug via serial port with another machine. When starting X, either the machine freezes hard (and so no CTRL+ALT+ESC) or the machine panics. It has never executed X without panics or freezes. I was able to obtain a core dump, the results are at: https://dl.dropboxusercontent.com/u/2094962/core.txt.4 I was unable to dive any further because the dump only shows the kernel side of things. The bt only seems to show the kernel side and the user side of things seems to be corrupt. Any other info I can obtain from the machine in the moment of the panic, let me know. I can easy do the debug via serial port. Gus Reading the backtrace I see this: panic: pmap_release: pmap resident count -398580 != 0 which comes from amd64/amd64/pmap.c:1936. I suspect that pmap-pm_stats.resident_count being negative is a bug. Can this be caused by a userspace process? If that's possible, any idea why I get a corrupted stack an thus I'm not able to find the root of the problem. G. -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic when starting X with Intel KMS
Hi, I'm having panics or hard freezes when starting X with an Intel video card. The machine is able to start old X+twm without problems but when I try gnome3 (in normal or fallback mode, doesn't matter) the machine panics or hard freezes. This doesn't happen when running X with vesa. With vesa the gnome is able to start in fallback (no composition) mode. Also, an old i386 with an nvidia card is able to run that gnome3 with composition so I'd say it has to do with the intel card. These are the specs of the machine: FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 RAM: 8GB Video Card: Intel chipid=0x00468086 The debugging knobs in the kernel config are there. I can also confirm that I can break to the debugger with CTRL+ALT+ESC before starting X. The world was build without debug symbols. Because the machine runs with an Intel card, I had to use my $work dockstation to obtain a serial port and do the debug via serial port with another machine. When starting X, either the machine freezes hard (and so no CTRL+ALT+ESC) or the machine panics. It has never executed X without panics or freezes. I was able to obtain a core dump, the results are at: https://dl.dropboxusercontent.com/u/2094962/core.txt.4 I was unable to dive any further because the dump only shows the kernel side of things. The bt only seems to show the kernel side and the user side of things seems to be corrupt. Any other info I can obtain from the machine in the moment of the panic, let me know. I can easy do the debug via serial port. Gus -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic when starting X with Intel KMS
Hi, I'm having panics or hard freezes when starting X with an Intel video card. The machine is able to start old X+twm without problems but when I try gnome3 (in normal or fallback mode, doesn't matter) the machine panics or hard freezes. This doesn't happen when running X with vesa. With vesa the gnome is able to start in debug mode. Also, an old i386 with an nvidia card is able to run that gnome3 with composition so I'd say it has to do with the intel card. These are the specs of the machine: FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 RAM: 8GB Video Card: Intel chipid=0x00468086 The debugging knobs in the kernel config are there. I can also confirm that I can break to the debugger with CTRL+ALT+ESC before starting X. The world was build without debug symbols. Because the machine runs with an Intel card, I had to use my $work dockstation to obtain a serial port and do the debug via serial port. When starting X, either the machine freezes hard (and so no CTRL+ALT+ESC) or the machine panics. It has never executed X without panics or freezes. I was able to obtain a core dump, the results are at: https://dl.dropboxusercontent.com/u/2094962/core.txt.4 I was unable to dive further because the dump only shows the kernel side of things. The bt only seems to show the kernel side an the user side of things seems to be corrupt. Any other info I can provide, let me know. I can easy do the debug via serial port. Gus -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: acpi resume related patch
Al 25/01/2013 09:43, En/na Andriy Gapon ha escrit: If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch Hi, the patch applies cleanly. Suspend did work in the past and seem to work now. However resume did not work and still doesn't. The problematic system is a Fujitsu laptop running AMD64 as today's head. In the past I tried the usual things (like running without X(Intel with GEM/KMS), removing all possible hardware out the kernel, etc...) without joy. My home server runs AMD64 with gemenized Intel and suspend/resume does work. For any additional info, let me know. Gustau -- Salut i força, Gustau --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MPSAFE VFS -- List of upcoming actions
Sorry fo the delay. About the ntfs support, I'd go with fuse and leave the most relevant filesystems in kernel space. In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the list is incomplete and I don't really know if all of them are yet implemenent in userspace) in my opinion. That would make them easier to maintain (changes in the kernel would only affect fuse, once fixed all the userspace filesystem would work again). As a bonus, we would get many working fs based on fuse. In the server side gluster is a desirable thing; in the desktop things like gvfs (in the linux world gvfs is used not only by gnome but also by kde or xfce) or truecrypt I'm fixing low hanging fruit for the moment (see r238411 for example) and I still have to make a throughful review. However my idea is to commit the support once: - ntfs-3g is well stress-tested and proves to be bug-free - there is no major/big technical issue pending after the reviews I'm now looking for people sticking with the branch and trying to stress-test ntfs-3g as much as they can. For example I know that Gustau (cc'ed) already had issues. It would be good if he tries to reproduce them and make a full report. I've seen ntfs-3g+fuse crashing a few times and IIRC most of the time the problem happened while unmounting the filesystem. I don't have the core dump files at hand, so I'll try to fix gnn patches to compile with my recent current (it doesn't compile, time ago I fixed fuse but I guess those patches wouldn't be enough right now) and try to panic the machine. When I do I'll do full reports of the panics. As final note, George as agreed to maintain FUSE in the long-term and of course I'll give him an hand as time permits. Any moment you need help needed coding, testing, etc let me know. Thanks, Attilio -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MPSAFE VFS -- List of upcoming actions
On 07/17/2012 22:54, Gustau Pérez i Querol wrote: In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace The list is incomplete and maybe wrong; maybe some should stay in the kernel. It was just a quick guess. If you are think the list should be reviewed, I completely agree. A big -1 here. The more native FS support we have the better off we are in terms of both people migrating from other OS', and people who need to maintain compatibility with other OS'. Well, I don't think we would lose compatibility (but I may be wrong). I think there are some fs' too complex to implement or maintain, like the ntfs one. About the ntfs case there's a complete fs implementation of it in userspace. And there are also many other fs' implementations in userspace. I think we can benefit from those implementations, removing the burden of maintaining them in the kernel (it would have been useful to have it in userspace right now because of the vfs giant lock removal deadline). The fs' staying in the kernel should be well maintained, the others in userspace would always work too as long as fuse is up to date; if anything changes in the kernel only fuse would need to be fixed to allow the many fs' in userpace to work. In the final situation we would end having a few fs in the kernel (I don't exactly know which ones to keep) and then some in userspace that could be installed via ports. We wouldn't lose compatibility with other OS', I think instead we would have more compatibility because we could benefit from the implementation of many fs' in userspace. People migrating from other OS' would have the possibility of installing the appropriate fusefs port. Of course, I don't know the exact list of fs' staying and leaving. Personally I use both msdosfs and ext2fs extensively for the latter purpose, and would not want to see either removed. Well, I don't know which ones I would remove/migrate to userspace. The msdosfs is probably one I wouldn't migrate. About the ext2 I used to use it time ago at work. Now I remember there was a GoC in 2009 to update the implementation and I would keep it in the kernel. We could even keep ext2 in the kernel and have support for it as a fusefs port; I could choose the kernel or the userspace implementation. At work I also have to deal with ext4 or exfat filesystems from time to time. Having a working fuse implementation would allow me to have a better compatibility with other OS'. -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Unable to resume amd64 machine
Hi, I've trying to suspend/resume an amd64 machine. The machine is a fujitsu S710 laptop running: FreeBSD 10.0-CURRENT #4 r237339=e61ad3a-dirty: Sat Jun 23 17:12:58 CEST 2012 I did the tests in the following conditions: - No X running. Everything in console. The machine has an Intel video card, but I did the tests without the i915kms module. - I removed all the modules I could from the kernel. The behavior is basically the machine seems to suspend fine (I see the power led blinking) but when resuming it freezes hard. I see the disk spinning for a while and then it stops. I can't ssh to it, I can't use the keyboard at all so I can issue no command at all. I've tried stripping down the kernel (everything is out except if_ath, em and usb stack). No pccard, no sdhci, no sound, no cuse4bsd, no usb hid devices (I'm using uhidd for hid devices), no acpi_video or acpi_fujitsu there but the same result. I tried enabling debug.acpi.resume_beep=1. When doing this, the laptop beeped like crazy. I tried using the serial console on the laptop. I saw the suspend process taking down some usb devices. Resume showed nothing on the serial console. With sysctl debug.acpi.suspend_bounce=1, the machine stayed alive (this is expected) but the screen went blank (this I think isn't expected). The video never came back. The three-finger-salute rebooted the machine. With acpi.reset_video I got no result. Disabling devices in the BIOS (removing wifi, bluetooth, webcam, etc ...) didn't bring me further. -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
Now let me dig into qthread_unix.cpp, see how QThreadData::current()
works:
QThreadData *QThreadData::current()
{
QThreadData *data = get_thread_data();
if (!data) {
void *a;
if
(QInternal::activateCallbacks(QInternal::AdoptCurrentThread, a)) {
QThread *adopted = static_castQThread*(a);
Q_ASSERT(adopted);
data = QThreadData::get2(adopted);
set_thread_data(data);
adopted-d_func()-running = true;
adopted-d_func()-finished = false;
static_castQAdoptedThread *(adopted)-init();
} else {
data = new QThreadData;
QT_TRY {
set_thread_data(data);
data-thread = new QAdoptedThread(data);
} QT_CATCH(...) {
clear_thread_data();
data-deref();
data = 0;
QT_RETHROW;
}
data-deref();
}
if (!QCoreApplicationPrivate::theMainThread)
QCoreApplicationPrivate::theMainThread = data-thread;
}
return data;
}
it calls get_thread_data(), if it returns NULL, it create a new
thread, and try to
set the new thread as current thread data, it calls set_thread_data().
let's see how get_thread_data() and set_thread_data() work :
static QThreadData *get_thread_data()
{
#ifdef Q_OS_SYMBIAN
return reinterpret_castQThreadData *(Dll::Tls());
#else
pthread_once(current_thread_data_once,
create_current_thread_data_key);
return reinterpret_castQThreadData
*(pthread_getspecific(current_thread_data_key));
#endif
}
static void set_thread_data(QThreadData *data)
{
#ifdef Q_OS_SYMBIAN
qt_symbian_throwIfError(Dll::SetTls(data));
#endif
pthread_once(current_thread_data_once,
create_current_thread_data_key);
pthread_setspecific(current_thread_data_key, data);
}
They just use pthread_getspecific and pthread_setspecific, the
current_thread_data_key was only
created once which is guarded by pthread_once(), but as you know, the
key has already
been deleted by Q_DESTRUCTOR_FUNCTION(destroy_current_thread_data_key)
which is a global
object which has been destructed early, the key is no longer
recreated, it is a stale key.
I was able to debug until the point where qthread_unix.cpp spawns a
new thread because the get_thread_data call returns 0. I was unable to
reach the full analysis, but now I get it. The explanation seems fine to
me, thanks.
What I don't get is why it works in stable. The functions registered
to be executed at exit (atexit_register hasn't changed) get registered
in same order in both branches (at least I checked them by printing the
two atexit structures when calling exit in both stable and head).
Wouldn't that mean that the problem of deleting the
current_thread_data_key should happen in both branches?
Gus
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
Al 30/04/2012 21:34, En/na Jason Evans ha escrit: On Apr 30, 2012, at 7:13 AM, Gustau Pérez i Querol wrote: the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is affecting the experimental cinnamon port (an alternative to gnome3, possible replacement of gnome2). The problem happens with both i386 and amd64 with empty /etc/malloc.conf and simple /etc/make.conf. Everything compiled with base gcc (no clang). The kernel was compiled with no debug support, but it can enable if needed. There are reports from avi...@freebsd.org of the same behavior with clang compiled world and kernel and with MALLOC_PRODUCTION=yes. When qdbus starts, it segfauts. The backtrace of the problem with r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting the qdbus daemon by hand in a X+twm session, we see it calls calloc many times and after a fixed number of times segfaults. We see it segfaults at rb_gen (a quite large macro defined at $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). If the daemon is started by hand, I'm able to skip all the calls qdbus makes to calloc till the one causing the segfault. At that point, at rb_gen, we don't exactly know what is going on or how to debug the macro. Ktrace are available, but we were unable to find anything new from them. With old versions of current before the jemalloc imports (as of March 30th) the daemon segfaulted at malloc.c:2426. With revisions during April 20 to 24th (can be more precise, it was during the jemalloc imports) the daemon segfaulted at malloc_init. Bts are available if needed, and if necessary I can go back to those revision and recompile world+kernel to see its behavior. Any help from freebsd-current@ (perhaps Jason Evans can help us) will be appreciated. Any additional info, like source revisions, can be provided. I would like to stress that the experimental devel/dbus-qt4 works fine with recent stable. The crash is happening in page run management, so there is some pretty bad memory corruption going on by the time of the crash. If I understand you correctly, you have reproduced the crash on a system that does *not* have MALLOC_PRODUCTION defined, which means that none of the assertions in jemalloc caught the problem. Adrian Chadd made the excellent suggestion of trying valgrind; it's likely to point out the problem almost immediately. If that doesn't work, the utrace functionality in malloc may help you figure out what activity has occurred by the time of the crash, and give you a better understanding of what happened to memory around the address that is involved in the crash. Thanks all for your suggestions. It would appear devel/dbus-qt4 has some problems with multithread management, the daemon has a problem which consists in starting a lot of threads and leading it to be finished due to stack exhaustion. Valgrind suggested to increase the stack size, doing so made things even worse; the qdbus daemon was able to spawn even more threads, causing the machine to need more memory than the physically allocated (that is, it started to use swap). So the problem seems to be not related to jemalloc or malloc. As the experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem has do to with some differences between head and stable. When we get more hints where the problem is, I will post them in a new thread in freebsd-current@. Anyhow, thanks again for your suggestions! Gus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RFC: jemalloc: qdbus sigsegv in malloc_init
Hi, the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is affecting the experimental cinnamon port (an alternative to gnome3, possible replacement of gnome2). The problem happens with both i386 and amd64 with empty /etc/malloc.conf and simple /etc/make.conf. Everything compiled with base gcc (no clang). The kernel was compiled with no debug support, but it can enable if needed. There are reports from avi...@freebsd.org of the same behavior with clang compiled world and kernel and with MALLOC_PRODUCTION=yes. When qdbus starts, it segfauts. The backtrace of the problem with r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting the qdbus daemon by hand in a X+twm session, we see it calls calloc many times and after a fixed number of times segfaults. We see it segfaults at rb_gen (a quite large macro defined at $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). If the daemon is started by hand, I'm able to skip all the calls qdbus makes to calloc till the one causing the segfault. At that point, at rb_gen, we don't exactly know what is going on or how to debug the macro. Ktrace are available, but we were unable to find anything new from them. With old versions of current before the jemalloc imports (as of March 30th) the daemon segfaulted at malloc.c:2426. With revisions during April 20 to 24th (can be more precise, it was during the jemalloc imports) the daemon segfaulted at malloc_init. Bts are available if needed, and if necessary I can go back to those revision and recompile world+kernel to see its behavior. Any help from freebsd-current@ (perhaps Jason Evans can help us) will be appreciated. Any additional info, like source revisions, can be provided. I would like to stress that the experimental devel/dbus-qt4 works fine with recent stable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
