Re: none (cvs mirrors)
From: Kris Kennaway [EMAIL PROTECTED] To: KSrinivasa Raghavan [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: none (cvs mirrors) Date: Fri, 7 Sep 2001 16:46:15 -0700 On Fri, Sep 07, 2001 at 11:24:58PM +, KSrinivasa Raghavan wrote: Hi Kris, cvsup servers doesn't seem to work as cvs servers. The anoncvs server worked yesterday, but today I am seeing other problems. Yes, I was being sarcastic. They're different protocols. I thought both the services were provided by the same system but ... I have been checking out sources directly into /usr directory and using it. Today I am getting this error message: # cvs co ports/www/w3m-img cannot mkdir /cvstmp/cvs-serv64094/./CVS No space left on device I didn't create cvstmp before too and it worked. Couldn't find any query related to this in FreeBSD mailing list. Known problem..should be fixed soon. Kris ... happy to know about the fix coming soon. Thanks, Srini. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 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 Sat, 8 Sep 2001, Chris Costello wrote: On Saturday, September 08, 2001, Poul-Henning Kamp wrote: No actually not, I want something short and predictable like VT_CODA. How about my second suggestion: making v_tag point to mp-mnt_stat.f_fstypename, or a copy thereof? Good, but I as far as I understand this, the only legitimate point of v_tag is to tell applications like fstat(1) the type of the vnode. fstat can find chase the kernel pointers in vp-v_mount-mnt_stat-f_fstypename almost as (un)easily as it could chase vp-v_tag if v_tag is a pointer. Copying the string would give ugly bloat, but would not be all that much worse than the bloat for a pointer on alphas (the contents of the string VT_CODA takes the same space as a pointer on alphas). 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
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: 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: 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: [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: SONY Z1 on motherboard Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 [...] atspeaker0 port 0x61 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ~ atkbd0: AT Keyboard 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: PS/2 Mouse 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: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard 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: PS/2 mouse port on isa0 You should see psm0: PS/2 mouse irq 12 on atkbdc0 psmcpnp0: PS/2 mouse port 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
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
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: 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-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=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE @@ -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: Keyboard controller (i8042) at port 0x60,0x64 on isa0 +atkbd0: AT Keyboard 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: PS/2 Mouse 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: System console failed to probe at flags 0x100 on isa0 @@ -323,12 +333,8 @@ isa_probe_children: probing PnP devices unknown: PNP0c02 can't assign resources unknown: PNP0c02 at port 0x398-0x399,0x4d0-0x4d1,0x8000-0x804f,0x1040-0x104f iomem 0xfff8-0x,0xfff7f600-0xfff7 on isa0 -atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 -atkbd0: AT Keyboard 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: PNP0303 can't assign resources +unknown: PNP0303 at port 0x60 on isa0 atspeaker0: AT speaker at port 0x61 on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0c02 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
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
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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE 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: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI 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: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge 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: PCI bus on acpi_pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xc000-0xc00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: serial bus, USB at device 7.3 (no driver attached) pci0: bridge, PCI-unknown at device 7.4 (no driver attached) pcm0: Creative EMU10K1 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: BrookTree 878 mem 0xda00-0xda000fff irq 2 at device 12.0 on pci0 bti2c0: bt848 Hard/Soft I2C controller iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O 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: multimedia 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: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: HighPoint HPT370 ATA100 controller 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: NEC 72065B or clone 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: Printer on ppbus0 lpt0: Interrupt-driven port ppc1: cannot reserve I/O port range atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ppc1: cannot reserve I/O port range psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA 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,
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
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: 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
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((1cpu_reset_proxyid));
printf(cpu_reset_proxy: Stopped CPU %d\n, cpu_reset_proxyid);
DELAY(100);
@@ -463,6 +477,7 @@
cpu_reset_proxyid = PCPU_GET(cpuid);
cpustop_restartfunc = cpu_reset_proxy;
cpu_reset_proxy_active = 0;
+ wbinvd();
printf(cpu_reset: Restarting BSP\n);
started_cpus = (10); /* Restart CPU #0 */
@@ -471,9 +486,19 @@
cnt++; /* Wait for BSP to announce restart */
if (cpu_reset_proxy_active == 0)
printf(cpu_reset: Failed to restart BSP\n);
- enable_intr();
+ disable_intr();
cpu_reset_proxy_active = 2;
-
+ wbinvd();
+ cnt = 0;
+ while (cpu_reset_proxy_active == 2 cnt 1000)
+ cnt++; /* Wait for BSP to stop APs */
+ if (cpu_reset_proxy_active == 2) {
+ printf(cpu_reset: BSP did not stop APs\n);
+ cpu_reset_real();
+ }
+ cpu_reset_proxy_active = 4;
+ wbinvd();
+ enable_intr();
while (1);
/* NOTREACHED */
}
