Debugging UMA allocation
Hi
One of the changes introduced after the 27/05 causes a panic in the initial
boot phases in the
The panic occurs on my Dell Lattitude C640 when using both my own kernel and
the GENERIC kernel.
The panic is
_mtx_lock_sleep: Recursed on non-recursive mutex in system map
I have traced the trigger panic to the first call to uma_zcreate in procinit
called from proc0_init - I have just cvs-supped again but the error is still
there
Unfortunately because it happend before anything is up and running I have no
way of producing a kernel dump and as the problem does not seem to be widely
reported I assume it is specific to this Dell Laptop type
The dmesg included are provided as reference only for the last good
compilation of the that I know off e.g. the kernel I know that boots - I have
been trying for about 2-3 days which should narrow down the time
Can anybody give any advise on how to progress?
/*
RSD PTR: OEM=DELL, ACPI_Rev=1.0x (0)
RSDT=0x000fde64, cksum=47
*/
/*
RSDT: Length=40, Revision=1, Checksum=165,
OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d4010c,
Creator ID=ASL, Creator Revision=0x61
Entries={ 0x000fde90 }
*/
/*
FACP: Length=116, Revision=1, Checksum=188,
OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d4010c,
Creator ID=ASL, Creator Revision=0x61
FACS=0x3800, DSDT=0xfffe4000
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0x70, ACPI_DISABLE=0x71, S4BIOS_REQ=0x97
PSTATE_CNT=0x80
PM1a_EVT_BLK=0x800-0x803
PM1a_CNT_BLK=0x804-0x805
PM2_CNT_BLK=0x820-0x820
PM_TMR_BLK=0x808-0x80b
GPE0_BLK=0x828-0x82b
GPE1_BLK=0x82c-0x82f, GPE1_BASE=16
P_LVL2_LAT=50 us, P_LVL3_LAT=2000 us
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=0, MON_ALRM=0, CENTURY=0
IAPC_BOOT_ARCH=
Flags={WBINVD,PROC_C1,PWR_BUTTON,SLP_BUTTON,DCK_CAP}
*/
/*
FACS: Length=64, HwSig=0x00ff, Firm_Wake_Vec=0x
Global_Lock=
Flags=S4BIOS
Version=0
*/
/*
DSDT: Length=12700, Revision=1, Checksum=38,
OEMID=INT430, OEM Table ID=SYSFexxx, OEM Revision=0x1001,
Creator ID=MSFT, Creator Revision=0x10e
*/
0 255 N 0 9 10 11
pci_link1: ACPI PCI Link LNKB irq 11 on acpi0
pci_link1: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7
pci_link1: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7
pci_link1: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7
pci_link2: ACPI PCI Link LNKC irq 11 on acpi0
pci_link2: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 9 10 11
pci_link2: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 11 N 0 9 10 11
pci_link2: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 9 10 11
pci_link3: ACPI PCI Link LNKD irq 11 on acpi0
pci_link3: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7 9 10 11
pci_link3: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7 9 10 11
pci_link3: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7 9 10 11
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 - 10
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
cpu0: ACPI CPU port 0x530-0x537 on acpi0
acpi_perf0: ACPI CPU Frequency Control on cpu0
acpi_throttle0: ACPI CPU Throttling on cpu0
acpi_throttle0: P_CNT from P_BLK 0x8e0
acpi_acad0: AC Adapter on acpi0
acpi_cmbat0: Control Method Battery on acpi0
acpi_cmbat1: Control Method Battery on acpi0
acpi_lid0: Control Method Lid Switch on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: physical bus=0
found- vendor=0x8086, dev=0x1a30, revid=0x04
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
map[10]: type 3, range 32, base e800, size 26, enabled
found- vendor=0x8086, dev=0x1a31, revid=0x04
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords)
lattimer=0x20 (960 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns)
found- vendor=0x8086, dev=0x2482, revid=0x02
bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
map[20]: type 4,
Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot
Yes, oh lordie yes. I guess we aren't going to have a new logo in time for FreeBSD6-RELEASE in August, are we? On 6/3/05, Scott Long [EMAIL PROTECTED] wrote: All, The long anticipated and much feared 6.0 code freeze is about to begin! I'll cut to the chase: June 10 - Feature freeze + code slush ^^^ July 10 - RELENG_6 branch August 1 - RELENG_6_0 branch August 15 - 6.0-RELEASE From June 10 until the release, the number one priority is fixing bugs. All of the dates after June 10 are somewhat fluid and subject to change depending on where we are with stability. We won't release 6.0 until it is ready, but I'm pretty confident that we'll have it ready by August. Since SMPVFS is on by default on i386 and amd64, we need as much testing and bug fixing there as is possible. Jeff has been doing a fantastic job on this, but I'm sure that more help would be appreciated. Also, now is the time to start tracking down whatever strange panics or poor performance anyone might be seeing; the system is pretty stable at the 80% level, but there are a lot of edge cases that we need to work on to make it a good release. A stroll through the mailing lists and PR database would be a good place to start for anyone that wants to help. Again, the plan is for 6.0 to be a modest replacement for 5.x. We do plan on a 5.5 release in September to tie up the branch and help people move to 6.0/6.1, but 6.x is truly just a much improved 5.x at this point. For those with bosses who are fainting at the thought of there being a 7-CURRENT around the corner and 5-STABLE coming to a close, please keep in mind that migrating from 5.x to 6.x is trivial and is worthwhile. However, we need to do the branch now so that we can keep things like SMPVFS under control and produce a high-quality series of releases with it. For those who have already adopted 5.x and cannot spend the time/money to migrate again, RELENG_5 will still have secteam support into at least 2007 (going by their normal formula), and I expect there to be normal feature and bug-fix commits to it for at least another year from now. To jump-start the testing, I've posted a new set of 6.0-CURRENT snapshots to ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Jun_2005. Once the freeze starts, I expect a new snapshot to be posted every 1-2 weeks until we get close to the release. So, please help test, report, and fix bugs! Thanks, Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Jawed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot
On Sat, 4 Jun 2005, John Jawed wrote: On 6/3/05, Scott Long [EMAIL PROTECTED] wrote: The long anticipated and much feared 6.0 code freeze is about to begin! I'll cut to the chase: June 10 - Feature freeze + code slush ^^^ July 10 - RELENG_6 branch August 1 - RELENG_6_0 branch August 15 - 6.0-RELEASE Yes, oh lordie yes. I guess we aren't going to have a new logo in time for FreeBSD6-RELEASE in August, are we? Coordinating the release with the new logo would be really nifty! My $0.02, Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot
On Sun, 5 Jun 2005, Andre Guibert de Bruet wrote: Yes, oh lordie yes. I guess we aren't going to have a new logo in time for FreeBSD6-RELEASE in August, are we? Coordinating the release with the new logo would be really nifty! Mabe im living under a rock... but what new logo? ~NVX ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging UMA allocation
On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote: Ups - two useless files included - please ignore the plugins.txt and the dmesg - it should have been Hi One of the changes introduced after the 27/05 causes a panic in the initial boot phases in the The panic occurs on my Dell Lattitude C640 when using both my own kernel and the GENERIC kernel. The panic is _mtx_lock_sleep: Recursed on non-recursive mutex in system map I have traced the trigger panic to the first call to uma_zcreate in procinit called from proc0_init - I have just cvs-supped again but the error is still there Unfortunately because it happend before anything is up and running I have no way of producing a kernel dump and as the problem does not seem to be widely reported I assume it is specific to this Dell Laptop type The dmesg included are provided as reference only for the last good compilation of the that I know off e.g. the kernel I know that boots - I have been trying for about 2-3 days which should narrow down the time Can anybody give any advise on how to progress? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help me with C languaje please, re: files.
On Sun, Jun 05, 2005 at 01:35:21AM -0400, Pablo Mora wrote:
#include stdio.h
#include stdlib.h
int main(void) {
FILE *p_to_f;
char buf[1024];
int i, j = 0;
p_to_f = fopen(test,r);
if(p_to_f == NULL) {
perror(fopen);
exit(EXIT_FAILURE);
}
for(i = 0; i 4 !feof(p_to_f); i++) {
fgets(buf,1024,p_to_f);
printf(%s, buf);
}
fclose(p_to_f);
return 0;
}
I expect that be well what I did. Thanks Victor.
PD Corrigeme Si hay algo malo. :D
You don't use j, in the for should be || instead of and you don't
check for errors in fgets.
Btw, i think that this is not the best place for ask this questions,
you should ask in a c programming list.
--
La prueba mas fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Vesa
Hello, I'd like to do some research on framebuffer GUIs (without Xorg) in FreeBSD. My background is C/C++ programming, Win32 and a bit of xlib. I've read the developer handbook but it didn't seem to have enough information for me. Can you please point me to more information about framebuffer development for FreeBSD (if any exists), or about how I can start doing a video driver for example? I have no idea if this should be done in kernel or userland, and if in userland, what must I do to have access to video hardware. Thank you very much for the attention. Cesar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vesa
On Sun, Jun 05, 2005 at 10:45:02AM -0300, Cesar Mello wrote: I'd like to do some research on framebuffer GUIs (without Xorg) in FreeBSD. My background is C/C++ programming, Win32 and a bit of xlib. I've read the developer handbook but it didn't seem to have enough information for me. Can you please point me to more information about framebuffer development for FreeBSD (if any exists), or about how I can start doing a video driver for example? I have no idea if this should be done in kernel or userland, and if in userland, what must I do to have access to video hardware. The framebuffer support in FreeBSD is pretty weak, look at the VESA part of syscons. You might want to have a look at KGI too, but I'm not sure if that is still actively supported. If you want to do more work in that area, you might want to talk with Sascha Wildner from DragonFly, he's been improving syscons lately. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging UMA allocation
On Sunday 05 June 2005 13:17, Thomas Sparrevohn wrote: Ok - After a hand held trace - here are what happens In the call to uma_zcreate for the PROC object the slab_zalloc ends up being called twice - it in turn calls vm_map_lock and establishes the first time a exclusive sleep mutex on the region 0xc1059144 through a call to vm_map_lock in the startup_alloc - however that lock are nover released so when the second call to slab_zalloc is executed it in turns again calls startup_alloc which in turn again calls page_alloc-kmem_malloc-vm_map_lock with the same region which by now holds an exclusive lock that the first call established and the kernel panics Could it be because the booted vairable holds the value 1 or it that a long shot? On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote: Ups - two useless files included - please ignore the plugins.txt and the dmesg - it should have been Hi One of the changes introduced after the 27/05 causes a panic in the initial boot phases in the The panic occurs on my Dell Lattitude C640 when using both my own kernel and the GENERIC kernel. The panic is _mtx_lock_sleep: Recursed on non-recursive mutex in system map I have traced the trigger panic to the first call to uma_zcreate in procinit called from proc0_init - I have just cvs-supped again but the error is still there Unfortunately because it happend before anything is up and running I have no way of producing a kernel dump and as the problem does not seem to be widely reported I assume it is specific to this Dell Laptop type The dmesg included are provided as reference only for the last good compilation of the that I know off e.g. the kernel I know that boots - I have been trying for about 2-3 days which should narrow down the time Can anybody give any advise on how to progress? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening raw disk while mounted in 5.x?
Hi list,
I don't want to start the bikeshed again, but would this be ok to create
a kern.geom.allow_foot_shooting sysctl wrapper for this and reference
it in geom(4) manual page (and anywhere else it is relevant), at least
temporaly until a decision is made ?
I can't find where this is documented and this question goes back
regularly.
I made the small attached patch which creates the
kern.geom.allow_foot_shooting
sysctl.
It's no more than an explicit representation of the fifth bit of
debugflags (remember the famous value 16).
If needed, I would be pleased to make a modification to the geom(4)
manual page and also to drop a note about this in fdisk(8) and
boot0cfg(8).
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
--- geom_kern.c.origSun Jun 5 19:12:22 2005
+++ geom_kern.c Sun Jun 5 19:21:17 2005
@@ -213,6 +213,31 @@
return error;
}
+static int
+sysctl_kern_geom_allow_foot_shooting(SYSCTL_HANDLER_ARGS)
+{
+ int error;
+ int val;
+
+ if (g_debugflags 16)
+ val = 1;
+ else
+ val = 0;
+
+ error = sysctl_handle_int(oidp, val, sizeof(int), req);
+ if (error || req-newptr == NULL)
+ return error;
+
+ if (val 0 || val 1)
+ return EINVAL;
+
+ if (val)
+ g_debugflags |= 16;
+ else
+ g_debugflags = ~16;
+ return 0;
+}
+
SYSCTL_NODE(_kern, OID_AUTO, geom, CTLFLAG_RW, 0, GEOMetry management);
SYSCTL_PROC(_kern_geom, OID_AUTO, confxml, CTLTYPE_STRING|CTLFLAG_RD,
@@ -230,6 +255,10 @@
TUNABLE_INT(kern.geom.debugflags, g_debugflags);
SYSCTL_INT(_kern_geom, OID_AUTO, debugflags, CTLFLAG_RW,
g_debugflags, 0, );
+
+SYSCTL_PROC(_kern_geom, OID_AUTO, allow_foot_shooting, CTLTYPE_INT|CTLFLAG_RW,
+ 0, sizeof(int), sysctl_kern_geom_allow_foot_shooting, I,
+ Allow foot-shooting);
SYSCTL_INT(_kern_geom, OID_AUTO, collectstats, CTLFLAG_RW,
g_collectstats, 0, );
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening raw disk while mounted in 5.x?
On Mon, 6 Jun 2005, Jeremie Le Hen wrote: I made the small attached patch which creates the kern.geom.allow_foot_shooting This was proposed in ftp://ftp.jurai.net/users/winter/geom.foot.patch before debug flag 16 existed. The longer name doesn't really do anything to inform the user about the behavior of GEOM that may run counter to their expectations. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
