Re: boot() called on cpu #1 - hang
> Hello,
>
> on a 5.0-current i386-SMP system of today I am still getting on about
> every second reboot the message:
>
> boot() called on cpu #1
> W
Try applying the enclosed patch.
- Tor Egge
Index: vm_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/vm_machdep.c,v
retrieving revision 1.169
diff -u -r1.169 vm_machdep.c
--- vm_machdep.c4 Sep 2001 08:36:46 - 1.169
+++ vm_machdep.c4 Sep 2001 19:58:38 -
@@ -424,8 +433,13 @@
{
cpu_reset_proxy_active = 1;
+ wbinvd();
while (cpu_reset_proxy_active == 1)
;/* Wait for other cpu to see that we've started */
+ cpu_reset_proxy_active = 3;
+ wbinvd();
+ while (cpu_reset_proxy_active == 3)
+ ; /* Wait for other cpu to enable interrupts */
stop_cpus((1<
Re: problem with dynamic sysctls in -current
On Sat, Sep 08, 2001 at 10:27:10PM +0200, Christian Carstensen wrote:
>
> hmm,
>
> i've posted the attached mail a week ago to this list, but got no
> response. could someone please comment on this issue?
I've also posted a patch(much less refined than yours, though) last month
but still got no response. Maybe you need to talk to the person who committed
rev 1.112 of kern_sysctl.c ?
> -- Forwarded message --
> Date: Sat, 1 Sep 2001 03:26:46 +0200 (CEST)
> From: Christian Carstensen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: dynamic sysctl problem and proposed hot fix
>
>
> hi,
>
> i just came across a problem with dynamic sysctls:
> when unloading a driver module that used dyn sysctls, my system paniced
> with "oid too high". that problem is caused by sysctl_ctx_free() in
> kern/kern_sysctl.c, that first deregisters all oids in the list to see if
> a error occurs. then, all oids are being reregistered and, if there was no
> error, they're finally removed.
> during the second phase, sysctl_register_oid(e1->entry) is called with
> n := e1->entry->oid_number being the old oid number with n > CTL_AUTO_START.
> that leads to panic("static sysctl too high") in sysctl_register_oid.
> one approach might be to initialize the oid_number field to contain the
> value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
> side effects of doing that in sysctl_ctx_free().
> alternatively, the "old" oid number could be reused, the following patch
> should do, but it's just a workaround.
>
>
> best,
> christian
>
> --
> "Sorry, no defects found. Please try a different search"
> [http://www.cisco.com/support/bugtools/bugtool.shtml]
>
>
> Index: kern_sysctl.c
> ===
> RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
> retrieving revision 1.113
> diff -r1.113 kern_sysctl.c
> 83a84,96
> > static struct sysctl_oid *
> > sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
> > {
> > struct sysctl_oid *oidp;
> >
> > SLIST_FOREACH(oidp, list, oid_link) {
> > if (oidp->oid_number == number) {
> > return (oidp);
> > }
> > }
> > return (NULL);
> > }
> >
> 125c138,139
> < panic("static sysctl oid too high: %d", oidp->oid_number);
> ---
> > if (sysctl_find_oidnumber(oidp->oid_number, parent))
> > panic("static sysctl oid too high: %d", oidp->oid_number);
> 177c191
> < if (error)
> ---
> > if (error)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
problem with dynamic sysctls in -current
hmm,
i've posted the attached mail a week ago to this list, but got no
response. could someone please comment on this issue?
thanks,
christian
-- Forwarded message --
Date: Sat, 1 Sep 2001 03:26:46 +0200 (CEST)
From: Christian Carstensen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: dynamic sysctl problem and proposed hot fix
hi,
i just came across a problem with dynamic sysctls:
when unloading a driver module that used dyn sysctls, my system paniced
with "oid too high". that problem is caused by sysctl_ctx_free() in
kern/kern_sysctl.c, that first deregisters all oids in the list to see if
a error occurs. then, all oids are being reregistered and, if there was no
error, they're finally removed.
during the second phase, sysctl_register_oid(e1->entry) is called with
n := e1->entry->oid_number being the old oid number with n > CTL_AUTO_START.
that leads to panic("static sysctl too high") in sysctl_register_oid.
one approach might be to initialize the oid_number field to contain the
value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
side effects of doing that in sysctl_ctx_free().
alternatively, the "old" oid number could be reused, the following patch
should do, but it's just a workaround.
best,
christian
--
"Sorry, no defects found. Please try a different search"
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: kern_sysctl.c
===
RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.113
diff -r1.113 kern_sysctl.c
83a84,96
> static struct sysctl_oid *
> sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
> {
> struct sysctl_oid *oidp;
>
> SLIST_FOREACH(oidp, list, oid_link) {
> if (oidp->oid_number == number) {
> return (oidp);
> }
> }
> return (NULL);
> }
>
125c138,139
< panic("static sysctl oid too high: %d", oidp->oid_number);
---
> if (sysctl_find_oidnumber(oidp->oid_number, parent))
> panic("static sysctl oid too high: %d", oidp->oid_number);
177c191
< if (error)
---
> if (error)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
On Saturday, September 08, 2001, Maxim Sobolev wrote:
> I don't like idea to hardcode the same string ("procfs"), with the
> same meaning in several places across kernel. As for your proposition
> to use f_fstypename to set v_tag, it is even more bogus because
> value of the f_fstypename is supplied from the user level, so
> potentially it could be anything and we can't make any reasonable
> assumptions about mapping between its value and type of the filesystem
> in question.
How do you figure? The contents if `f_fstypename' must match
a configured file system exactly, so it could _not_ be anything.
To quote sys/kern/vfs_syscalls.c:mount():
if ((error = copyinstr(SCARG(uap, type), fstypename, MFSNAMELEN, NULL))
vput(vp);
return (error);
}
for (vfsp = vfsconf; vfsp; vfsp = vfsp->vfc_next)
if (!strcmp(vfsp->vfc_name, fstypename))
break;
if (vfsp == NULL) {
/* ... try and load a module ... */
/* ... fail if no module can be found, or no
* matching VFS is loaded */
}
--
+---+---+
| Chris Costello| You depend too much on computers for information. |
| [EMAIL PROTECTED] | |
+---+---+
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
boot() called on cpu #1 - hang
Hello, on a 5.0-current i386-SMP system of today I am still getting on about every second reboot the message: boot() called on cpu #1 W and then the sysetm hangs. When boot is called on cpu #0 everything works as expected. I think this started roughly two week from now. But I am not sure if then boot was only called on cpu #0 or boot worked on cpu #1. Any suggestions? Micha dmesg from the system is: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Sep 8 10:04:26 MEST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (998.36-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 1073676288 (1048512K bytes) avail memory = 1040457728 (1016072K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc04c7000. Preloaded elf module "acpi.ko" at 0xc04c709c. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdbc0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 IOAPIC #0 intpin 19 -> irq 2 IOAPIC #0 intpin 16 -> irq 5 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 pci0: on acpi_pcib0 agp0: mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.4 (no driver attached) pcm0: port 0xcc00-0xcc1f irq 5 at device 9.0 on pci0 sym0: <810> port 0xd400-0xd4ff mem 0xda003000-0xda0030ff irq 10 at device 10.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking bktr0: mem 0xda00-0xda000fff irq 2 at device 12.0 on pci0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 smb0: on smbus0 bktr0: Hauppauge Model 61344 D121 bktr0: Detected a MSP3410D-B4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. pci0: at device 12.1 (no driver attached) xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xda002000-0xda00207f irq 11 at device 13.0 on pci0 xl0: Ethernet address: 00:10:5a:d7:dd:9c miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xec00-0xecff,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc07 irq 11 at device 14.0 on pci0 ata2: at 0xdc00 on atapci1 ata3: at 0xe400 on atapci1 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppc1: cannot reserve I/O port range atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ppc1: cannot reserve I/O port range psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 linprocfs registered APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IPv6 packet filtering initialized, default to accept, unlimited logging IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging IPsec: Initialized Security Association Processing. acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 32634MB [66305/16/63] at ata0-master tagged UDMA66 ad4: 43979MB [89355/16/63] at ata2-master tagged UDMA100 ad6: 32634MB [66305/16/63] at ata3-master tagged UDMA66 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s4a cd0 at sym0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8)
Re: postfix fails to start
From the keyboard of Hellmuth Michaelis: > Perhaps i can find out more later as i now have to tell my kids > a goodnight story How good that i did that - on today´s current postfix runs again Anyway, the time i intended to work on -current and commit some bits to it was once again just eaten up by getting current up and running :-( hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problems
Mike Smith wrote: > This is the general form of a different problem. The hints > DO NOT supply PNP identifiers. Got it yet? You are adding nothing useful in terms of forward progress on solving his problem by commenting on my postings instead of addressing his issues, which I have at least attempted to address, in the absence of direct participation by you. > > A "quick hack", which was iscussed but not implemented at > > the time I read the message about it, would be to disable > > the ACPI timer > > It's a) implemented and b) documented in the acpi(4) manpage > (and has been for some time). Perhaps you are reading only my postings, and have missed the fact that _he is not running ACPI_. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On Sat, Sep 08, 2001 at 07:32:17PM +0900, Kazutaka YOKOTA wrote: > Your forgot to put the following lines in device.hints. > > hint.atkbdc.0.at="isa" > hint.atkbdc.0.port="0x60" > > See /sys/i386/conf/GENERIC.hints. no, I didn't forget. It wasn't required before now and I had 1 string less in unknown devices :) anyway, I've added this to device.hints and now mouse works. There is dmesg diff: --- dmesg.noacpiSat Sep 8 11:02:22 2001 +++ dmesg.noacpi.after Sat Sep 8 15:28:23 2001 @@ -3,8 +3,8 @@ The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #46: Sat Sep 8 10:26:49 MSD 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO -Calibrating clock(s) ... TSC clock: 496308852 Hz, i8254 clock: 1193183 Hz -Timecounter "i8254" frequency 1193183 Hz +Calibrating clock(s) ... TSC clock: 496305810 Hz, i8254 clock: 1193175 Hz +Timecounter "i8254" frequency 1193175 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x387f9ff @@ -314,6 +314,16 @@ bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff +atkbdc0: at port 0x60,0x64 on isa0 +atkbd0: flags 0x1 irq 1 on atkbdc0 +kbd0 at atkbd0 +kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d +atkbd1: unable to allocate IRQ +psm0: current command byte:0047 +psm0: irq 12 on atkbdc0 +psm0: model GlidePoint, device ID 0-00, 2 buttons +psm0: config:6000, flags:, packet size:3 +psm0: syncmask:c0, syncbits:00 pmtimer0 on isa0 sc1: no video adapter found. sc1: failed to probe at flags 0x100 on isa0 @@ -323,12 +333,8 @@ isa_probe_children: probing PnP devices unknown: can't assign resources unknown: at port 0x398-0x399,0x4d0-0x4d1,0x8000-0x804f,0x1040-0x104f iomem 0xfff8-0x,0xfff7f600-0xfff7 on isa0 -atkbdc0: at port 0x60,0x64 irq 1 on isa0 -atkbd0: flags 0x1 irq 1 on atkbdc0 -kbd0 at atkbd0 -kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d -atkbd1: unable to allocate IRQ -psm0: unable to allocate IRQ +unknown: can't assign resources +unknown: at port 0x60 on isa0 atspeaker0: at port 0x61 on isa0 unknown: can't assign resources unknown: at iomem 0xdc000-0xd on isa0 -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RAM cram!!! is this a -current issue? XF86/Netscape-6.10
I was just checking something out in top, and noticed a big discrepancy in the core usage for mozilla, and XF86 looks a bit heavier than normal... The "mozilla" in use is the linux netscape 6.10 dist direct from netscape [i avoided installing the -port, because it was using some kinda hacked version with missing menus and such]... Could this be a netscape memory leak issue, or a -current issue?? I have *NEVER* seen netscape using this much core. --- 5:57AM up 6 days, 9:33, 6 users, load averages: 0.99, 0.71, 0.49 FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Aug 31 16:12:39 CDT 2001 --- last pid: 15303; load averages: 0.56, 0.61, 0.43 up 6+09:30:26 05:54:39 141 processes: 3 running, 117 sleeping, 21 waiting CPU states: 3.8% user, 0.0% nice, 3.5% system, 0.4% interrupt, 92.3% idle Mem: 404M Active, 39M Inact, 32M Wired, 13M Cache, 7488K Buf, 11M Free Swap: 1024M Total, 187M Used, 837M Free, 18% Inuse PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 11 root -160 0K 0K CPU0 0 117.0H 73.00% 73.00% idle: cpu0 10 root -160 0K 0K RUN1 115.7H 70.07% 70.07% idle: cpu1 558 jbryant 1000 332M 205M select 0 856:43 31.35% 31.35% mozilla-bin 285 root 990 124M 97664K select 0 48.7H 5.81% 5.81% XFree86 2 root -160 0K 0K psleep 0 0:24 0.88% 0.88% pagedaemon 525 jbryant960 25800K 6792K select 0 42:58 0.68% 0.68% kdeinit 596 jbryant960 86948K 26716K select 1 80:29 0.44% 0.44% communicator-linux- 487 jbryant960 16972K 3332K select 1 127:37 0.39% 0.39% kdeinit 527 jbryant960 17156K 2464K select 1 61:35 0.20% 0.20% kdeinit 13 root -48 -167 0K 0K WAIT 0 50:45 0.15% 0.15% swi6: tty:sio clock 505 jbryant960 17904K 3764K select 1 21:19 0.05% 0.05% kdeinit 28 root -60 -179 0K 0K WAIT 0 3:02 0.05% 0.05% irq12: psm0 15271 jbryant960 17228K 11384K select 1 0:11 0.05% 0.05% ksnapshot 15289 root -80 1636K 1184K physst 1 0:01 0.05% 0.05% dump 15290 root 200 1636K 1184K pause 0 0:01 0.05% 0.05% dump 15291 root 200 1636K 1184K pause 0 0:01 0.05% 0.05% dump 15253 jbryant960 2380K 1276K CPU1 1 0:05 0.00% 0.00% top jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top(1) takes ages to start up
Le 2001-09-08, Nick Hibma écrivait : > Why don't you add an early-out for namelength => 15 or put the > if-statement in the loop: Well, in my case all usernames are <= 8 characters, so the proposed changes would not prevent a complete walk of the NIS db. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Thank you for your report. >On Sat, Sep 08, 2001 at 12:15:59AM +0900, Kazutaka YOKOTA wrote: >> Please send me the entire dmesg output after you boot >> the system with "boot -v" at the loader prompt. >ok. >> >> And do you have the following line in /boot/device.hints? >> hint.psm.0.irq="12" >yes. I tried with and without some lines in /boot/device.hints. >attached outputs is with the following hints: >hint.atkbd.0.at="atkbdc" >hint.atkbd.0.irq="1" >hint.atkbd.0.flags="0x1" >hint.psm.0.at="atkbdc" >hint.psm.0.irq="12" >hint.vga.0.at="isa" >hint.sc.0.at="isa" >hint.sc.0.flags="0x100" >hint.vt.0.at="isa" >hint.pmtimer.0.at="isa" >hint.spic.0.at="isa" >hint.spic.0.port="0x10a0" >hint.acpi.0.disable=1 Your forgot to put the following lines in device.hints. hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x60" See /sys/i386/conf/GENERIC.hints. However, there definitely are some strange things about ACPI and PnP BIOS in your machine... Your first dmesg: the acpi module is enabled. >acpi0: on motherboard >Timecounter "ACPI" frequency 3579545 Hz >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 >acpi_cpu0: on acpi0 >acpi_tz0: on acpi0 >acpi_button0: on acpi0 >acpi_pcib0: port 0xcf8-0xcff on acpi0 [...] >atspeaker0 port 0x61 on acpi0 >atkbdc0: port 0x64,0x60 irq 1 on acpi0 ~ >atkbd0: flags 0x1 irq 1 on atkbdc0 >atkbd: the current kbd controller command byte 0047 >atkbd: keyboard ID 0x41ab (2) >kbd0 at atkbd0 >kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d >atkbd1: unable to allocate IRQ >psm0: unable to allocate IRQ >atkbd1: unable to allocate IRQ >psm0: current command byte:0047 >psm0: irq 12 on atkbdc0 >psm0: model GlidePoint, device ID 0-00, 2 buttons >psm0: config:6000, flags:, packet size:3 >psm0: syncmask:c0, syncbits:00 >psmcpnp0 irq 12 on acpi0 The PS/2 mouse is detected. But, the AT keyboard driver is assigned with port resources 0x64 and 0x60; the order should normally be 0x60, then 0x64... Your second dmesg: the acpi module is disabled. As you don't have hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x60" in device hints, the kernel tried to attach the keyboard controller, keyboard and PS/2 mouse based on the PnP BIOS information. This should normally work, despite the missing above lines in device.hints, because the information supplied by the PnP BIOS is supporsed to be correct. But, see below. [...] >pnpbios: 17 devices, largest 210 bytes >PNP0c02: adding fixed memory32 range 0xfff8-0x, size=0x8 [...] >pnpbios: handle 15 device ID SNY7001 (0170d9cd) >PNP0401: adding io range 0x378-0x37f, size=0x8, align=0x1 >PNP0401: adding io range 0x778-0x77f, size=0x8, align=0x1 >PNP0401: adding irq mask 0x80 >PNP0401: adding dma mask 0x8 >pnpbios: handle 18 device ID PNP0401 (0104d041) >pnpbios: handle 20 device ID PNP0f13 (130fd041) ~~~ This is the PS/2 mouse reported by the PnP BIOS. It should be assigned with the "irq mask 0x1000". But it's missing here! >atkbdc0: at port 0x60,0x64 irq 1 on isa0 >atkbd0: flags 0x1 irq 1 on atkbdc0 >kbd0 at atkbd0 >kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d >atkbd1: unable to allocate IRQ >psm0: unable to allocate IRQ [...] (The above failure is expected, and you can ignore.) >psmcpnp0: on isa0 You should see psm0: irq 12 on atkbdc0 psmcpnp0: irq 12 on isa0 at this point. But, because the irq was not assigned to the PS/2 mouse node earlier by the PnP BIOS, the mouse failed to attach. I have never seen this failure before ;-( I will think about what I can do... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top(1) takes ages to start up
* Nick Hibma <[EMAIL PROTECTED]> [010908 04:51] wrote:
>
> Why don't you add an early-out for namelength => 15 or put the
> if-statement in the loop:
This is a good idea, however it fails for the case when everyone
has been assigned usernames that are less than 15 characters, I
would suggest putting an upper bounds on the amount of times you'll
call getpwent() to something like 200 or some other compile time
(but command line over-rideable) number before defaulting to the
max.
>
> Index: machine.c
> ===
> RCS file: /home/ncvs/src/usr.bin/top/machine.c,v
> retrieving revision 1.44
> diff -u -r1.44 machine.c
> --- machine.c 2001/05/31 22:36:51 1.44
> +++ machine.c 2001/09/08 09:48:03
> @@ -216,13 +216,16 @@
> while ((pw = getpwent()) != NULL) {
> if (strlen(pw->pw_name) > namelength)
> namelength = strlen(pw->pw_name);
> + if (smpmode && namelength > 13) {
> + namelength = 13;
> + break;
> + } else if (namelength > 15) {
> + namelength = 15;
> + break;
> + }
> }
> if (namelength < 8)
> namelength = 8;
> -if (smpmode && namelength > 13)
> - namelength = 13;
> -else if (namelength > 15)
> - namelength = 15;
>
> if ((kd = kvm_open("/dev/null", "/dev/null", "/dev/null", O_RDONLY,
> "kvm_open")) == NULL)
> return -1;
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: top(1) takes ages to start up
Why don't you add an early-out for namelength => 15 or put the
if-statement in the loop:
Index: machine.c
===
RCS file: /home/ncvs/src/usr.bin/top/machine.c,v
retrieving revision 1.44
diff -u -r1.44 machine.c
--- machine.c 2001/05/31 22:36:51 1.44
+++ machine.c 2001/09/08 09:48:03
@@ -216,13 +216,16 @@
while ((pw = getpwent()) != NULL) {
if (strlen(pw->pw_name) > namelength)
namelength = strlen(pw->pw_name);
+ if (smpmode && namelength > 13) {
+ namelength = 13;
+ break;
+ } else if (namelength > 15) {
+ namelength = 15;
+ break;
+ }
}
if (namelength < 8)
namelength = 8;
-if (smpmode && namelength > 13)
- namelength = 13;
-else if (namelength > 15)
- namelength = 15;
if ((kd = kvm_open("/dev/null", "/dev/null", "/dev/null", O_RDONLY,
"kvm_open")) == NULL)
return -1;
On Fri, 7 Sep 2001, Thomas Quinot wrote:
> ... because it walks through the entire NIS db just to find out what the
> longest user name is (/src/usr.bin/top/machine.c 1.5). At this site,
> this means 2800 RPC calls and dozens of seconds when the network and/or
> NIS server are busy.
>
> What do others think of the following patch?
>
> Thomas.
>
> --- machine.c.distFri Jun 1 00:36:51 2001
> +++ machine.c Fri Sep 7 16:31:45 2001
> @@ -212,7 +212,7 @@
> sysctlbyname("kern.smp.active", &smpmode, &modelen, NULL, 0) < 0) ||
> modelen != sizeof(smpmode))
> smpmode = 0;
> -
> +#ifndef NO_GETPWENT
> while ((pw = getpwent()) != NULL) {
> if (strlen(pw->pw_name) > namelength)
> namelength = strlen(pw->pw_name);
> @@ -223,6 +223,9 @@
> namelength = 13;
> else if (namelength > 15)
> namelength = 15;
> +#else
> +namelength = 8;
> +#endif
>
> if ((kd = kvm_open("/dev/null", "/dev/null", "/dev/null", O_RDONLY,
>"kvm_open")) == NULL)
> return -1;
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RFC: hack volatile bzero and bcopy
On Fri, 7 Sep 2001, Bakul Shah wrote: > > out-of order is probably ok for a buffer if you know that it's > > presently yours to write into. > > If the area being bcopied/bzeroed has this behavior why not > remove the volatile from the struct ptrs instead of "fixing" > bcopy/bzero? One reason is that the memory might be normal at the time of the bcopy (because you have locked out concurrent accesses to it), but volatile at other times. I think this should be handled in general by declaring it as normal and always locking it. > > 2/ add to the prototype of bzero and bcopy so that volatile pointers are > > acceptable > > arguments. (I don't see any reason to not do this). > > Because the (informal) defn of bcopy/bzero does not allow > volatile arguments. You are wagging the dog. > > Why not just cast these ptrs at the call sites where you > _know_ bcopy, bzero use is safe. That sort of documents what > is going on without opening a big hole. FreeBSD turns on -Wcast-qual in order to prevent inadvertant loss of type qualifiers, so using explicit casts just moves the warning from the implicit casts caused by the prototype to the implicit casts. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
On Saturday, September 08, 2001, Maxim Sobolev wrote:
> No, it should be pre-defined, because otherwise we will be
> unable to use strcmp() in a few places when v_tag is abused.
So in these cases (which ideally would be eliminated rather
than considered for support), why can't you do:
if (strcmp(vp->v_tag, "procfs") == 0) {
rather than
if (strcmp(vp->v_tag, VT_PROCFS) == 0) {
in the case of procfs? As for a solution to the problem, I'm
not entirely sure, but maybe this is a case for either a new
vnode flag, `VUNSAFE', for files which should be closed across
exec() calls (this is all setugidsafety() and its hackish
is_unsafe() companion are used for as far as I can tell).
--
+---++
| Chris Costello| Let the machine do the dirty work. |
| [EMAIL PROTECTED] |- Elements of Programming Style |
+---++
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
