RE: synchronization question about /sys/dev/vkbd/vkbd.c
> > My question is: > > Is it not possible, that vkbd_dev_intr() could be > > interrupted at any position before the VKBD_LOCK() > > and then vkbd_dev_write() called? > > in theory it is possible. > > > If yes, how should vkbd_dev_write() know, that it should > > call task_enqueue(), as TASK is still set? > > well, i guess it is possible to miss interrupt in this case. also, the > scancodes are not lost, they will be processed on next write. > I agree, that it is hardly possible to miss an interrupt, as keys come in so slowly. But that also means if it happens, you will notice it, because you have to press an additional key. > i suspect that the vkbd_dev_intr() should be interrupted exactly > in between > > (*kbdsw[kbd->kb_index]->intr)(kbd, NULL); > > and > > VKBD_LOCK(state); > Yes, precisely. > yes, that could be done. it is also possible to have a callout going few > times a second to check if there is a scancodes in the queue and > schedule vkbd_dev_intr(). funny that atkbd(4) and ukbd(4) have just this. Thank you for your comments, Norbert ___ 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]"
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: 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: 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]"
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: help me with C languaje please, re: files.
On Sun, Jun 05, 2005 at 01:35:21AM -0400, Pablo Mora wrote:
> #include
> #include
>
> 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]"
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: 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: 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
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]"
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: 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: 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: 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: port 0x530-0x537 on acpi0
acpi_perf0: on cpu0
acpi_throttle0: on cpu0
acpi_throttle0: P_CNT from P_BLK 0x8e0
acpi_acad0: on acpi0
acpi_cmbat0: on acpi0
acpi_cmbat1: on acpi0
acpi_lid0: on acpi0
acpi_button0: on acpi0
acpi_button1: on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: 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, range 32, base bf80, size 5, enabled
pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LNKA:0)
pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LNKA
found-> vendor=0x8086, dev=0x2484, revid=0x02
bus=0, slot=29, func=1
