Re: vfsload appearse broken after new changes
"Andrey A. Chernov" wrote: > When I try to mount my dos partition I got now: > > msdosfs: vfsload(msdosfs): No such file or directory > > kldload msdosfs.ko > > fails too. > > When I preload it manually before mount using full path > /boot/kernel/msdosfs.ko, it works. The problem is that many of our kld's are missing module version declarations. Also, check that the kern.module_path sysctl has got a trailing / on each component.You can do a 'ktrace kldload msdosfs' and you should be able to see the path searching for linker.hints and the .ko files as NAMI calls. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot() called on cpu #1 - hang
On Mon, 10 Sep 2001 [EMAIL PROTECTED] wrote:
> > Hello Tor,
> >
> > thank you for your quick response, unfortunately your patch did
> > not fix the problem.
>
>
> Your machine seems to hang too early for the patch to have any effect.
> (the patch affects a hang that occurs after the kernel has printed
> cpu reset called on cpu#1
> cpu_reset: Stopping other CPUs
> )
>
> > I have now tested a little bit more with the following sequence:
> >
> > boot machine to single-user
> > reboot
> >
> > I did this more then 10 times. It now got stuck every time
> > Approx. 8 time with
> >
> > boot() called on cpu #1
> > W
> >
> > And 3 times with
> >
> > boot() called on cpu #0
> > Wa
> >
> > or
> >
> > boot() called on cpu #0
> > Waiting (max
> >
> > It looks to me that the kernel-printf gets somehow stuck.
>
>
> Did you use -O2 when compiling the kernel ? That sometimes causes
> strange problems.
>
> The kernel doesn't appear do do much before printing the
>
> Waiting (max %d seconds) for system process `%s' to stop
>
> message in kproc_shutdown.
>
>
> boot() in /usr/src/sys/kern/kern_shutdown.c contains
>
> #ifdef SMP
> if (smp_active)
> printf("boot() called on cpu#%d\n", PCPU_GET(cpuid));
> #endif
> /*
> * Do any callouts that should be done BEFORE syncing the filesystems.
> */
> EVENTHANDLER_INVOKE(shutdown_pre_sync, howto);
>
>
> where the EVENTHANDLER_INVOKE macro expands to a lockmgr() call and
> invocation of the two events associated with shutdown_pre_sync:
>
> kproc_shutdown(bufdaemonproc, howto)
> kproc_shutdown(updateproc, howto)
>
> The normal output is
>
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
> Waiting (max 60 seconds) for system process `syncer' to stop...stopped
>
> If the lockmgr lock for the event list is damaged, further damage
> elsewhere might occur due to the lockmgr call. If a debug printf
> before the lockmgr call in EVENTHANDLER_INVOKE() works while a debug
> printf after the lockmgr call isn't properly printed, then the
> probability for the problem being related to the lockmgr call is
> increased (cf. /usr/src/sys/sys/eventhandler.h)
>
> - Tor Egge
>
>
Hello Tor,
I have added a printf right before and after the lockmgr call in the
EVENTHANDLER_INVOKE() Macro in /usr/src/sys/sys/eventhandler.h.
But both of these printf do work! The output I am getting then is:
Boot() called on cpu #1
before lockmgr
after lockmgr
W
What else could I test?
Michael
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
vfsload appearse broken after new changes
When I try to mount my dos partition I got now: msdosfs: vfsload(msdosfs): No such file or directory kldload msdosfs.ko fails too. When I preload it manually before mount using full path /boot/kernel/msdosfs.ko, it works. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI kills my current-box frequently.
Oops. > In <[EMAIL PROTECTED]> > NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote: HN> Dmesgs with and without acpi are attached below. ===> with acpi.ko loaded 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 #12: Sat Sep 8 16:56:16 JST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NAKAJI Calibrating clock(s) ... TSC clock: 936722721 Hz, i8254 clock: 1193160 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (936.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 671072256 (655344K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004fa000 - 0x27ff3fff, 665821184 bytes (162554 pages) avail memory = 647581696 (632404K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f92a0 bios32: Entry = 0xf0690 (c00f0690) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x890 pnpbios: Found PnP BIOS data at 0xc00fc260 pnpbios: Entry = f:c290 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc04d4000. Preloaded elf module "acpi.ko" at 0xc04d40a8. null: mem: Pentium Pro MTRR support enabled random: Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06911106) Using $PIR table, 8 entries at 0xc00f0e60 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_button0: on acpi0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP/ECP_RLE/NIBBLE_ID/ECP_ID/ECP_RLE_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: PRINTER POSTSCRIPT plip0: on ppbus0 bpf: lp0 attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc1: cannot reserve I/O port range sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x41 0x49 0x41 0x41 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A 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: failed to get data. psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:, flags:, packet size:4 psm0: syncmask:00, syncbits:00 psmcpnp0 irq 12 on acpi0 ppc1: cannot reserve I/O port range pcib0: at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base e400, size 26, enabled found-> vendor=0x1106, dev=0x0691, revid=0xc2 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x1106, dev=0x0596, revid=0x12 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base b800, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base b400, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x08 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=5 found-> vendor=0x1106, dev=0x3050, revid=0x20 bus=0, slot=4, func=3 class=06-00-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base b000, size 7, enabled map[14]: type 1, range 32, base e180, size 7, enabled found-> vendor=0x10b7, dev=0x9055, revid=0x30 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=5 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e100, size 12, enabled map[14]: type 1, range 32, base e080, size 20, enabled found-> vendor=0x1013, dev=0x6003, revid=0x01 bus=0, slot=11, func=0 class
No Subject
Max Conrad MCP UPS Technology Support To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI kills my current-box frequently.
Thank you, Iwasaki-san. Now I booted the system with 'hint.acpi.0.disable=1' in /boot/device.hints. It works good at least while writing this message. > In <[EMAIL PROTECTED]> > Mitsuru IWASAKI <[EMAIL PROTECTED]> wrote: HN> Just after rebooting with this kernel and installworld, this host HN> reboots frequently, about every 10 minutes. /var/log/messages shows HN> that MI> Could you describe your hardware? I'd like see boot -v dmesg and ACPI MI> data. Please send them to acpi-jp ML. My hardware is... M/B ASUS P3V4X CPU PentiumIII 933MHz with ASUS S370-DL Mem 640MB (total) HDD WDC AC32500H/24.09P07 Maxtor 31536U2/BAC51NJ0 FUJITSU MPC3102AT E/6207 IBM-DTLA-307045/TX6OA60A IBM-DTLA-307045/TX6OA60A IBM DPES-31080 S31Q IBM DPSS-318350N S96H IBM DPSS-318350N S96H QUANTUM FIREBALL SE2.1S PJ09 SCSIAHA-2940U2W RAIDHighPoint HPT370 ATA100 controller SOUND AOpen AW230 (CS461x PCM Audio) NIC 3Com 3c905B-TX Fast Etherlink XL VGA Rage 3D IIC (not detected when booting) PortJusty JIF-01A (serial and parallel ISA) Dmesgs with and without acpi are attached below. And kernel configuration is available at http://www.rc.tutrp.tut.ac.jp/~nakaji/tmp/NAKAJI MI> Also could you try adjust loader variable `debug.acpi.disable' and MI> see if which component is causing the problem? I'll check them later. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
The testing I've done shows that postfix is buggy in two ways: - The main() in inet_addr_local.c assumes that the addresses in addr_list and mask_list are sockaddrs, but this is only true when using IPv6. This only affects testing with -DTEST. - inet_addr_local() calls inet_addr_list_append(..., struct in_addr) even when -DINET6 when inet_addr_list_append() takes a second argument of struct sockaddr *. When I fix the bugs in main() and compile without -DINET6 to avoid the bug in inet_addr_local(), the test code seems to print the right things. stash% ./TEST 135.197.10.172/255.255.255.128 127.0.0.1/255.0.0.0 stash% ifconfig -a dc0: flags=8843 mtu 1500 ... inet 135.197.10.172 netmask 0xff80 broadcast 135.197.10.255 ... lo0: flags=8049 mtu 16384 ... inet 127.0.0.1 netmask 0xff00 stash% uname -a FreeBSD stash.attlabs.att.com 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Mon Sep 10 17:03:15 PDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STASH i386 Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ThinkPad, ACPI, and PS/2 mouse
It now appears that some IBM ThinkPad models assign a distinct PnP ID to the PS/2 mouse port. If you have ThinkPad and its pointing device is not recognized when ACPI is loaded in the latest -current system, please do the following 1. Disable ACPI and boot unset acpi_load boot -v 2. Send the entire dmesg output to me. Don't forget to tell me the model name of your ThinkPad too. ThinkPad models currently known to have this behavior: model PnP ID for the PS/2 mouse port ThinkPad 570E IBM3780 Thanks Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ToPIC100 not working correctly
In message <[EMAIL PROTECTED]> Mark Santcroos writes: : On Mon, Sep 10, 2001 at 09:51:00PM +0200, Mark Santcroos wrote: : > Do you know the exact reason for this problem or can I help by exactly : > finding out what change of code causes this problems? : : I deciced to track it down. I narrowed it down to the commit to pcic_pci.c : v1.71. That's good to know. : diff /tmp/pccardd/current/pcic.c ./pcic.c : 897c897 : < return (bus_generic_teardown_intr(dev, child, irq, cookie)); : --- : > return 0; : diff /tmp/pccardd/current/pcic_pci.c ./pcic_pci.c : 1336c1336 : < DEVMETHOD(bus_teardown_intr,bus_generic_teardown_intr), : --- : > DEVMETHOD(bus_teardown_intr,pcic_teardown_intr), : : : IOW, just skip the bus_generic_teardown_intr(). I called it a workaround, : cause I don't know if this is really a fix or a hack. (Don't know the code : well enough for that) : However, my problems disappeared with this patch. : : Please shine your light on this, or give a suggestion for a nice fix. : Anyway, the fix seems close (and trivial). That's actually excellent information. That's about the best diagnosis I've had in a while. I'd rather have had a -u diff, but with such a small diff, I can easily try it here. There might be side effects that we'll need to take care of... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD current is very slow
- Original Message - From: "Liu Siwei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 8:58 PM Subject: FreeBSD current is very slow > Hi,all: > Do you run freebsd-current? what current? I make a > clean SNAP of freebsd-current through make release. > And make a CD. I install freebsd-current from my own > CD. All things are fine. But its multimedia is not > soundable. I compile gnome-1.4 on this current-SNAP > smoothly from source through ports. But when I first > run gnome desktop environment, it takes long time to > appear desktop environment. But when I disable the > gnome's sound event and restart it again, it is very > quickly start up. This is one reason I say that. > Secondly, I make mpg123 from ports by > source(current ports). I start it in background like > this: "mpg123 my.mp3 &", I use top command to see my > system's load, I was surpised: mpg123 only takes no > more than 5% system resources, but the interrupt TAKES > more than 90% system resources. So my system is very > slow to run other software. Why? and I want to know > what's the interrupt and it relates what? > Now, I have installed FreeBSD 4.4RC1. I compile > mpg123 again, and play it background, I find the > interrupt takes no more than 5% system resource! > Is it FreeBSD-current's BUGs??? > > Best Regard. > > > __ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.com > FreeBSD-current, by default, has debugging turned on in the kernel. Try recompiling your kernel without the debugging options, and it should work very quickly. - David > 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
FreeBSD current is very slow
Hi,all: Do you run freebsd-current? what current? I make a clean SNAP of freebsd-current through make release. And make a CD. I install freebsd-current from my own CD. All things are fine. But its multimedia is not soundable. I compile gnome-1.4 on this current-SNAP smoothly from source through ports. But when I first run gnome desktop environment, it takes long time to appear desktop environment. But when I disable the gnome's sound event and restart it again, it is very quickly start up. This is one reason I say that. Secondly, I make mpg123 from ports by source(current ports). I start it in background like this: "mpg123 my.mp3 &", I use top command to see my system's load, I was surpised: mpg123 only takes no more than 5% system resources, but the interrupt TAKES more than 90% system resources. So my system is very slow to run other software. Why? and I want to know what's the interrupt and it relates what? Now, I have installed FreeBSD 4.4RC1. I compile mpg123 again, and play it background, I find the interrupt takes no more than 5% system resource! Is it FreeBSD-current's BUGs??? Best Regard. __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ToPIC100 not working correctly
On Mon, Sep 10, 2001 at 09:51:00PM +0200, Mark Santcroos wrote: > Do you know the exact reason for this problem or can I help by exactly > finding out what change of code causes this problems? I deciced to track it down. I narrowed it down to the commit to pcic_pci.c v1.71. For that version it had the following relevant change: 833,834c794,795 < DEVMETHOD(bus_setup_intr, pcic_pci_setup_intr), < DEVMETHOD(bus_teardown_intr,pcic_pci_teardown_intr), --- > DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), > DEVMETHOD(bus_teardown_intr,bus_generic_teardown_intr), I translated that back to the -current code and it comes to the following 'workaround': diff /tmp/pccardd/current/pcic.c ./pcic.c 897c897 < return (bus_generic_teardown_intr(dev, child, irq, cookie)); --- > return 0; diff /tmp/pccardd/current/pcic_pci.c ./pcic_pci.c 1336c1336 < DEVMETHOD(bus_teardown_intr,bus_generic_teardown_intr), --- > DEVMETHOD(bus_teardown_intr,pcic_teardown_intr), IOW, just skip the bus_generic_teardown_intr(). I called it a workaround, cause I don't know if this is really a fix or a hack. (Don't know the code well enough for that) However, my problems disappeared with this patch. Please shine your light on this, or give a suggestion for a nice fix. Anyway, the fix seems close (and trivial). Thanks Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buildkernel Breakage?
Upgrading a 4.4-RC4 system to -CURRENT with sources cvsupped from this morning gives me the errors below. I read UPDATING and I don't think I missed anything (though I've been wrong before). Any suggestions? Thanks! --Andy uname -a: - FreeBSD stingray 4.4-RC FreeBSD 4.4-RC #1: Fri Sep 7 11:26:35 CDT 2001root@stingray:/usr/obj/usr/src/sys/STINGRAY i386 log snippet: cc -nostdinc -O -pipe -march=pentiumpro -march=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -no stdinc -I- -I. -I@ -I@/dev -I@/../include -g -mpreferred-stack-boundary=2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -c linux_ sysent.c In file included from linux_sysent.c:14: linux_proto.h:57: syntax error before `linux_time_t' linux_proto.h:57: `linux_time_t' undeclared here (not in a function) linux_proto.h:57: syntax error before `)' linux_proto.h:57: `linux_time_t' undeclared here (not in a function) linux_proto.h:57: syntax error before `)' linux_proto.h:156: syntax error before `linux_handler_t' linux_proto.h:156: `linux_handler_t' undeclared here (not in a function) linux_proto.h:156: `linux_handler_t' undeclared here (not in a function) linux_proto.h:184: syntax error before `linux_dev_t' linux_proto.h:184: `linux_dev_t' undeclared here (not in a function) linux_proto.h:184: `linux_dev_t' undeclared here (not in a function) linux_proto.h:189: syntax error before `linux_osigaction_t' linux_proto.h:189: `linux_osigaction_t' undeclared here (not in a function) linux_proto.h:189: syntax error before `)' linux_proto.h:189: `linux_osigaction_t' undeclared here (not in a function) linux_proto.h:189: syntax error before `)' linux_proto.h:190: syntax error before `linux_osigaction_t' linux_proto.h:190: `linux_osigaction_t' undeclared here (not in a function) linux_proto.h:190: syntax error before `)' linux_proto.h:190: `linux_osigaction_t' undeclared here (not in a function) linux_proto.h:190: syntax error before `)' linux_proto.h:196: syntax error before `linux_osigset_t' linux_proto.h:196: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:196: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:200: syntax error before `linux_osigset_t' linux_proto.h:200: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:200: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:201: syntax error before `linux_osigset_t' linux_proto.h:201: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:201: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:204: syntax error before `linux_osigset_t' linux_proto.h:204: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:204: syntax error before `)' linux_proto.h:204: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:204: syntax error before `)' linux_proto.h:216: syntax error before `linux_gid_t' linux_proto.h:216: `linux_gid_t' undeclared here (not in a function) linux_proto.h:216: syntax error before `)' linux_proto.h:216: `linux_gid_t' undeclared here (not in a function) linux_proto.h:216: syntax error before `)' linux_proto.h:220: syntax error before `linux_gid_t' linux_proto.h:220: `linux_gid_t' undeclared here (not in a function) linux_proto.h:220: syntax error before `)' linux_proto.h:220: `linux_gid_t' undeclared here (not in a function) linux_proto.h:220: syntax error before `)' linux_proto.h:344: syntax error before `linux_osigset_t' linux_proto.h:344: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:344: syntax error before `)' linux_proto.h:344: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:344: syntax error before `)' linux_proto.h:345: syntax error before `linux_osigset_t' linux_proto.h:345: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:345: syntax error before `)' linux_proto.h:345: `linux_osigset_t' undeclared here (not in a function) linux_proto.h:345: syntax error before `)' linux_proto.h:380: syntax error before `linux_uid_t' linux_proto.h:380: `linux_uid_t' undeclared here (not in a function) linux_proto.h:380: `linux_uid_t' undeclared here (not in a function) linux_proto.h:383: syntax error before `linux_gid_t' linux_proto.h:383: `linux_gid_t' undeclared here (not in a function) linux_proto.h:383: `linux_gid_t' undeclared here (not in a function) linux_proto.h:410: syntax error before `linux_pid_t' linux_proto.h:410: `linux_pid_t' undeclared here (not in a function) linux_proto.h:410: `linux_pid_t' undeclared here (not in a function) linux_proto.h:439: syntax error before `linux_uid_t' linux_proto.h:439: `linux_uid_t' undeclared here (not in a function) linux_proto.h:439: syntax error before `)' linux_proto.h:439: `linux_uid_t
Re: Anyone working on missing sysv* ipc functionality
Hi, On Tue, 11 Sep 2001, Peter Jeremy wrote: ... > Whilst not Linux related, there's a lot of general SysV Semaphore > cleanup in PR kern/12014. Following the latest round of Giant > pushdown's, the patches in the PR don't apply, but I have an > updated-but-untested set of patches. I'm still awaiting my commit privs to commit it myself. But in the meantime could you please send a follow-up to the PR with your updatet patch? Thanks. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone working on missing sysv* ipc functionality
[I'm a long way behind with my e-mail] On 2001-Aug-12 14:22:00 +0200, Michael Reifenberger <[EMAIL PROTECTED]> wrote: >at least the linux emulation is missing some ipc functionality: >[SEM|SHM]_INFO [SEM|SHM]_STAT. Whilst not Linux related, there's a lot of general SysV Semaphore cleanup in PR kern/12014. Following the latest round of Giant pushdown's, the patches in the PR don't apply, but I have an updated-but-untested set of patches. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp -> suspend -> wakeup problem
On Mon, Sep 10, 2001 at 03:24:31PM +0100, Brian Somers wrote:
> > > What sort of problem do you have with ppp ?
> > 1. pcmcia-modem
> > 2. active ppp-link
> > zzz
> >
> > wakeup -> panic
> > the same problem is with pppd(as I remember).
> > I'll give you dump-information in 5-6 hours: my pcmcia-modem is at home...
>
> Hmm, I've never been able to suspend and resume on my laptop (with
> APM or ACPI), so I'm not going to be able to help I'm afraid.
ohh... I think it is so bring to boot twice a day...
> My apologies.
never mind, but... could you 'just to see', may be you'll have any ideas?
I think the problem is:
when I suspend my system, pccard is unregistred and disapeared as device.
when I resume, it needs some time to activate device back, but in the
same time ppp or tun or bpf or some network stuff try to talk with this device
and... ta-da
I think I saw the same when I suspend with pccard-NIC at the moment,
when trafshow was running...
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4993024
initial pcb at 2e85a0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014709f
stack pointer = 0x10:0xcfc97c60
frame pointer = 0x10:0xcfc97c78
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 616 (ppp)
\\|/ \\|/
"@'/ .. \\`@"
/_| \\__/ |_\\
\\__U_/
panic: from debugger
\\|/ \\|/
"@'/ .. \\`@"
/_| \\__/ |_\\
\\__U_/
panic: from debugger
Uptime: 2m26s
dumping to dev ad0s3b, offset 128
dump ata0: resetting devices .. done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235
234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214
213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193
192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151
150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130
129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:489
489 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:489
#1 0xc0170f68 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:332
#2 0xc01713de in panic (fmt=0xc028b1be "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:657
#3 0xc01287c1 in db_panic (addr=-1072402273, have_addr=0, count=1,
modif=0xcfc97adc "") at /usr/src/sys/ddb/db_command.c:443
#4 0xc0128761 in db_command (last_cmdp=0xc02c69f8, cmd_table=0xc02c6838,
aux_cmd_tablep=0xc02be560, aux_cmd_tablep_end=0xc02be564)
at /usr/src/sys/ddb/db_command.c:341
#5 0xc012882b in db_command_loop () at /usr/src/sys/ddb/db_command.c:465
#6 0xc012aa9f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0265204 in kdb_trap (type=12, code=0, regs=0xcfc97c20)
at /usr/src/sys/i386/i386/db_interface.c:167
#8 0xc0273468 in trap_fatal (frame=0xcfc97c20, eva=20)
at /usr/src/sys/i386/i386/trap.c:929
#9 0xc02731c5 in trap_pfault (frame=0xcfc97c20, usermode=0, eva=20)
at /usr/src/sys/i386/i386/trap.c:848
#10 0xc02728a4 in trap (frame={tf_fs = -1070727144, tf_es = 16,
tf_ds = -1070661616, tf_edi = 0, tf_esi = -1032471552,
tf_ebp = -808878984, tf_isp = -808879028, tf_ebx = -808878956,
tf_edx = 0, tf_ecx = 19, tf_eax = 64, tf_trapno = 12, tf_err = 0,
tf_eip = -1072402273, tf_cs = 8, tf_eflags = 66195,
tf_esp = -1032471552, tf_ss = 64}) at /usr/src/sys/i386/i386/trap.c:405
#11 0xc014709f in spec_poll (ap=0xcfc97c94)
---Type to continue, or q to quit---
at /usr/src/sys/fs/specfs/spec_vnops.c:333
#12 0xc0146d1d in spec_vnoperate (ap=0xcfc97c94)
at /usr/src/sys/fs/s
Re: ToPIC100 not working correctly
I supplied you with the information you asked for, but didnt receive any feedback/further directions. Is it btw recommended to switch to NEWCARD for the sake of testing/debugging. Or doesnt it matter at all? In pcic_pci.c v1.80 the warning for ToPIC100 not working disappeared, but it still isnt working as it should for me. (For verbosity: the cards only loads correctly once, it doesnt detect the second insert after removing (see other mails in this thread)) Do you know the exact reason for this problem or can I help by exactly finding out what change of code causes this problems? Mark On Thu, Sep 06, 2001 at 01:50:53PM +0200, Mark Santcroos wrote: > > On Wed, Sep 05, 2001 at 11:51:07AM -0400, Jonathan Chen wrote: > > A complete dmesg from a verbose boot with both the successful and failed > > attempts would be a good start. It would also be useful to know what card > > you're using. > > The card is a Lucent wavelan. I haven't tried this with another card > though, let me know if that might me usefull. > > Find attached the two dmesgs. They are both build after a cvsup. > For one of the two kernels I have replaced src/sys/pccard/ with the one > from August 20. > > I have also included my kernel config. > > Mark > > -- > Mark SantcroosRIPE Network Coordination Centre > http://www.ripe.net/home/mark/New Projects Group/TTM > machine i386 > cpu I686_CPU > ident MYNEW > maxusers 32 > options INET#InterNETworking > options FFS #Berkeley Fast Filesystem > options SOFTUPDATES #Enable FFS soft updates support > options MD_ROOT #MD is a potential root device > options PROCFS #Process filesystem > options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] > options UCONSOLE#Allow users to grab the console > options KTRACE #ktrace(1) support > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options P1003_1B#Posix P1003_1B real-time extensions > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV# install a CDEV entry in /dev > deviceisa > devicepci > devicefdc > deviceata > deviceatadisk # ATA disk drives > deviceatapicd # ATAPI CDROM drives > options ATA_STATIC_ID #Static device numbering > deviceatkbdc 1 > deviceatkbd > devicepsm > devicevga > devicesc 1 > devicenpx > deviceapm > devicepmtimer > devicecard > devicepcic > devicesio > devicewi > devicerandom # Entropy device > deviceloop# Network loopback > deviceether # Ethernet support > devicetun # Packet tunnel. > devicepty # Pseudo-ttys (telnet etc) > devicemd # Memory "disks" > devicebpf # Berkeley packet filter > deviceuhci > deviceusb # USB Bus (required) > deviceugen# Generic > options PSEUDOFS > options COMPAT_LINUX > options LINPROCFS > options DDB > options INCLUDE_CONFIG_FILE > options IPFIREWALL > options IPDIVERT > 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 #10: Thu Sep 6 09:41:15 CEST 2001 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP > Calibrating clock(s) ... TSC clock: 299933216 Hz, i8254 clock: 1193150 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz > CLK_USE_TSC_CALIBRATION not specified - using old calibration method > CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x66a Stepping = 10 > >Features=0x183f9ff > real memory = 134086656 (130944K bytes) > Physical memory chunk(s): > 0x1000 - 0x0009efff, 647168 bytes (158 pages) > 0x0032c000 - 0x07fd7fff, 130727936 bytes (31916 pages) > avail memory = 127447040 (124460K bytes) > bios32: Found BIOS32 Service Directory header at 0xc00f0220 > bios32: Entry = 0xfc465 (c00fc465) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf+0xedcd > pnpbios: Found PnP BIOS data at 0xc00f8ed
kern/30440, please commit enclosed patch
hi, could someone please commit the patch enclosed in kern/30440 to -current? thanks, christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linuxulator: possible Giant pushdown victim
On 10-Sep-01 Dag-Erling Smorgrav wrote: > Julian Elischer <[EMAIL PROTECTED]> writes: >> Marcel Moolenaar wrote: >> > BTW: Do we have handy functions for use in the remote debugger, such >> > as show_proc, show_vm or whatever, that dump important information >> > in a readable form? >> Matt has a cool set of macros as does Grog. > > I have a couple of macros I've used for debugging KLDs, which may > serve as templates or inspiration for someone to write e.g. a "ps" > macro (it shouldn't be too different from the "kldstat" macro, just > walk the process table and print formatted info for every process) Grog has a ps macro. Look in sys/modules/vinum IIRC. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp in INSTALLTMP?
On 09-Sep-01 Christian Weisgerber wrote: > Bruce Evans <[EMAIL PROTECTED]> wrote: > >> > I don't know why nobody else seems to be seeing this, but cp is >> >> This might be caused by having the sources and objects on different >> machines with inconsistent clocks. > > No, it's all local on a single machine. > FWIW, I'm on alpha. Yes, I've seen this. I'm betting it is timing related, and that dfr's fix to pmap.c will fix this. I found that if I did a buildworld without -j X and then did an installworld it would work ok. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linuxulator: possible Giant pushdown victim
Julian Elischer <[EMAIL PROTECTED]> writes:
> Marcel Moolenaar wrote:
> > BTW: Do we have handy functions for use in the remote debugger, such
> > as show_proc, show_vm or whatever, that dump important information
> > in a readable form?
> Matt has a cool set of macros as does Grog.
I have a couple of macros I've used for debugging KLDs, which may
serve as templates or inspiration for someone to write e.g. a "ps"
macro (it shouldn't be too different from the "kldstat" macro, just
walk the process table and print formatted info for every process)
define kldstat
set $kld = linker_files.tqh_first
printf "Id Refs AddressSize Name\n"
while ($kld != 0)
printf "%2d %4d 0x%08x %-8x %s\n", \
$kld->id, $kld->refs, $kld->address, $kld->size, $kld->filename
set $kld = $kld->link.tqe_next
end
end
document kldstat
Lists the modules that were loaded when the kernel crashed.
end
define kldstat-v
set $kld = linker_files.tqh_first
printf "Id Refs AddressSize Name\n"
while ($kld != 0)
printf "%2d %4d 0x%08x %-8x %s\n", \
$kld->id, $kld->refs, $kld->address, $kld->size, $kld->filename
printf "Contains modules:\n"
printf "Id Name\n"
set $module = $kld->modules.tqh_first
while ($module != 0)
printf "%2d %s\n", $module->id, $module->name
set $module = $module->link.tqe_next
end
set $kld = $kld->link.tqe_next
end
end
document kldstat-v
Lists modules with full information.
end
define kldload
set $kld = linker_files.tqh_first
set $done = 0
while ($kld != 0 && $done == 0)
if ($kld->filename == $arg0)
set $done = 1
else
set $kld = $kld->link.tqe_next
end
end
if ($done == 1)
shell /usr/bin/objdump -h $arg0 | \
awk '/ .text/ { print "set \$offset = 0x" $6 }' > .kgdb.temp
source .kgdb.temp
add-symbol-file $arg0 $kld->address + $offset
end
end
document kldload
Loads a module. Arguments are module name and offset of text section.
end
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1255] Re: ACPI and PS/2 mouse problem
Hi, > I have the same laptop but a different problem, with today kernel. The > following is copied by hand, no serial console at home: > wait: > > panic: free: address 0xcbf5e5fe > > db> trace > panic(...) at panic+0xb6 > free(...) at free+0x32 > AcpiOsFree(...) at AcpiOsFree+0x11 > AcpiExCopyStringToString(...) at AcpiExCopyStringToString+0x4d Yes, this is already analyzed in http://home.jp.FreeBSD.org/cgi-bin/showmail/acpi-jp/1239 Try following patch. This fix will be appear in next Intel ACPICA snapshot release. Index: dsobject.c === RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsobject.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 dsobject.c --- dsobject.c 26 Aug 2001 22:28:16 - 1.1.1.9 +++ dsobject.c 3 Sep 2001 11:45:49 - @@ -558,6 +558,7 @@ break; } +ObjDesc->Common.Flags |= AOPOBJ_STATIC_POINTER; return (AE_OK); } Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI kills my current-box frequently.
Hi, NAKAJI-san. Thank you for reporting. > Just after rebooting with this kernel and installworld, this host reboots > frequently, about every 10 minutes. /var/log/messages shows that Could you describe your hardware? I'd like see boot -v dmesg and ACPI data. Please send them to acpi-jp ML. Also could you try adjust loader variable `debug.acpi.disable' and see if which component is causing the problem? Possible values to debug.acpi.disable are; bus, children, button, cpu, ec, lid, pci, sysresource, thermal and timer. You can specify them in loader, like; ok set debug.acpi.disable="cpu ec lid pci sysresource thermal timer" See also acpi(4). Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp in INSTALLTMP?
On Sun, Sep 09, 2001 at 05:54:43PM -0400, Mike Barcroft wrote: > Christian Weisgerber <[EMAIL PROTECTED]> writes: > > Bruce Evans <[EMAIL PROTECTED]> wrote: > > > > > > I don't know why nobody else seems to be seeing this, but cp is > > > > > > This might be caused by having the sources and objects on different > > > machines with inconsistent clocks. > > > > No, it's all local on a single machine. > > FWIW, I'm on alpha. > > I'm seeing this on my alpha as well. I believe it started about a week > or two ago. I successfully installworld on alpha last with sources from 3th Sep. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How can I turn off acpi 100%?
Hi, > was comming. Mistake. It comes up fine, I think because all I can see are: > > acpi_cmbat0: bif size changed 0 > > at what looks like several per second. In single user I am getting: > > acpi-ec0: evaluation of CPE query method _Q3F failed - AE_NOT_FOUND Hmm, I think these two problems are the same; i.e. Embedded Controller problem. Could you get ACPI data from your machine, like # acpidump -o Compaq_1700.dsdt > Compaq_1700.asl and send them (plus boot -v dmesg) to [EMAIL PROTECTED] ? > How can I turn all this off? Can I send any info that might help someone else? It's very easy to disable ACPI, but I think we had better to improve our ACPI implementation :-) Because newer Intel-based machines (not only Laptops) have become strongly depending on ACPI. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1258] ACPI Data for a Dell Inspiron 8000 Laptop
Hi, thanks for your report. I'll add submitted ACPI data to our collection. > Find attached some data to help out with getting ACPI running smoothly. > Many features work with this laptop but the most annoying complaint is > the lack of console display being restored after a suspend/resume. Are you using APM suspend/resume on ACPI enabled system? I know that some machines can support both at the same time, but many machines cannnot. Please try to use acpiconf(8) under ACPI instead of apm(8)/zzz(8), then report the problems to acpi-jp ML if exists. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Raid Controller reconditioning
On Mon, Sep 10, 2001 at 12:56:16PM +0100, Tomas Palfi wrote: > i'm running stable4.3 on Dell poweredge 2500 with PERC 3/Di controller which > is causing a problem. the support battery on the controller is being > discharged on irregular basis and when fully discharged it freezes the > system. After rebooting the system the console displays: > > aac0: ** Battery charge is now OK > > this message is displayed on the console after approx. 2-3 mins of running. > there is no way the battery would be fully recharged after such a short > time. Being it a new system the battery has not been fully charged and > dischardged to gain full working capacity. This is not the fault of the OS or the driver. The message that you see is generated by the firmware on the aac controller and simply logged to the console. My guess is that the battery is damaged and the controller is confused as to its state. Calling Dell Tech Support would be a good option. As a second option you could update to -current (or wait a week for -stable to catch up) and get the new-and-improved aac driver which will let you run the afacli app from Dell. With that, you may be able to convince the controller to recondition the battery with some success. Scott 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 Sun, Sep 09, 2001 at 09:49:59AM +0900, [EMAIL PROTECTED] wrote:
> 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 ?
Ouch! I was wondering why no one complained about the way I broke
dynamic module unloading.. Guess I don't read -current as much as
I should..
Anyway - yes, I am aware of the breakage that rev 1.112 introduced,
although I only became aware of it a week or so ago, when I tried
to MFC it to 4.4-RC.. I wrote up a quick patch to make things work
again, a short discussion on -arch followed, resulting in no real
agreement except for "it's broken, somebody should fix it".
This, of course, is definitely not an appropriate way to end
a discussion about a FreeBSD kernel breakage, but I've been a bit
held up by real work events lately, and my -current system went
a-bye-bye due to unrelated issues, so I had no system to test any
kind of fixes on.
I am CC'ing this to Andrej Bialecki, who seems to know a bit more
than me about kern_sysctl.c; Andrej, is the attached patch good
enough to be committed as an interim fix, until somebody actually
gets around to fixing the sysctl_ctx_free() algorithm? This patch
is definitely way better than my hack, which added a bogus new
argument to sysctl_add_oid() :)
If there are no objections, I could commit this in the next few
days and take on the responsibility to really look into this in
a week or two, and really clean up the mess I made..
G'luck,
Peter
--
Nostalgia ain't what it used to be.
> > -- 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);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Raid Controller reconditioning
Faulty battery monitor? If it's a NiCad, consistant recharging when the cell isn't discharged to the recommended "discharged" voltage can cause what is known as "memory effect", where the battery will never charge above that partially-discharged state at which it been consistantly recharged from. Also, if a NiCad is allowed to discharge below a certain voltage, polarity reversal can happen. Most modern gear will use NiMH or Li-ion cells nowadays, because such cells do not have these problems. Some manufacturers using cheezy parts and other cut corners in quality do still use NiCad cells though [if they were shoddy there, where else were they shoddy?] Main question: is it under warranty? Tomas Palfi wrote: > i'm running stable4.3 on Dell poweredge 2500 with PERC 3/Di controller which > is causing a problem. the support battery on the controller is being > discharged on irregular basis and when fully discharged it freezes the > system. After rebooting the system the console displays: > > aac0: ** Battery charge is now OK > > this message is displayed on the console after approx. 2-3 mins of running. > there is no way the battery would be fully recharged after such a short > time. Being it a new system the battery has not been fully charged and > dischardged to gain full working capacity. > > come on guys, what's going on here?!, is anyone running 4.3 on Poweredge > 2500, has anyone got similar problems? i've checked it with 'stable guys' > and no messages no suggestion, nothing. perhaps it's me, overlooking > something, but the server goes down at least once a week > > thank you > -- > Tomas Palfi 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: Awright, who's the funny bunny?
Bruce Evans <[EMAIL PROTECTED]> writes:
> > 19 18 17 16 15 14 13 12 11 10 9 8 [CTRL-C to abort] 7 6 5 [CTRL-C to
> > abort] 4 [CTRL-C to abort] 3 2 [CTRL-C to abort] 1 0 [CTRL-C to abort]
> Did you want to abort? I really hate the change that stopped the space
> bar aborting.
No, I don't know why it did that. I may have pressed a key by accident.
>
> > ---
> > ...
> > #8 0xc01a529d in panic (fmt=0xc02a9e88 "recurse")
> > at ../../../kern/kern_shutdown.c:657
> > #9 0xc01c55c8 in witness_lock (lock=0xda11373c, flags=8,
> > file=0xc02c3380 "../../../i386/linux/linux_sysvec.c", line=387)
> > at ../../../kern/subr_witness.c:543
> > #10 0xc02807b0 in linux_sendsig (catcher=0x286f2e10, sig=32, mask={
> > sigmask_l_ = , sigmask = 0xda14ff1c,
> > sigmask_r_ = 0xda14fef8 ""}, code=0)
> > at ../../../i386/linux/linux_sysvec.c:387
> > #11 0xc01aaaea in postsig (sig=32) at ../../../kern/kern_sig.c:1694
>
> This seems to be because:
>
> 1.85 +3 -3 src/sys/i386/linux/linux_sysvec.c
>
> missed changing linux_sendsig(). It only changed linux_rt_sendsig().
It's not just linux_sendsig() - I get this panic even when not running
Linux programs:
#0 dumpsys () at ../../../kern/kern_shutdown.c:489
#1 0xc01a4e3b in boot (howto=260) at ../../../kern/kern_shutdown.c:332
#2 0xc01a529d in panic (fmt=0xc02ace21 "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:657
#3 0xc01e0d29 in bremfree (bp=0xccf49d0c) at ../../../kern/vfs_bio.c:535
#4 0xc01e23de in vfs_bio_awrite (bp=0xccf49d0c)
at ../../../kern/vfs_bio.c:1528
#5 0xc0177d8c in spec_fsync (ap=0xda0b6c6c)
at ../../../fs/specfs/spec_vnops.c:400
#6 0xc0177999 in spec_vnoperate (ap=0xda0b6c6c)
at ../../../fs/specfs/spec_vnops.c:119
#7 0xc0230a40 in ffs_sync (mp=0xc295b200, waitfor=2, cred=0xc14b2d00,
p=0xc034f0a0) at vnode_if.h:441
#8 0xc01f0673 in sync (p=0xc034f0a0, uap=0x0)
at ../../../kern/vfs_syscalls.c:622
#9 0xc01a48f7 in boot (howto=256) at ../../../kern/kern_shutdown.c:241
#10 0xc01a529d in panic (fmt=0xc02a9d20 "blockable sleep lock (%s) %s @ %s:%d")
at ../../../kern/kern_shutdown.c:657
#11 0xc01c5432 in witness_lock (lock=0xc034fb40, flags=0,
file=0xc02a6503 "../../../kern/kern_proc.c", line=146)
at ../../../kern/subr_witness.c:493
#12 0xc01aca15 in _sx_slock (sx=0xc034fb40,
file=0xc02a6503 "../../../kern/kern_proc.c", line=146)
at ../../../kern/kern_sx.c:115
#13 0xc019bf80 in pfind (pid=453) at ../../../kern/kern_proc.c:146
#14 0xc01ca409 in selwakeup (sip=0xc2bf5004)
at ../../../kern/sys_generic.c:1255
#15 0xc01d580b in ptcwakeup (tp=0xc2bf5020, flag=1)
at ../../../kern/tty_pty.c:319
#16 0xc01d57e6 in ptsstart (tp=0xc2bf5020) at ../../../kern/tty_pty.c:308
#17 0xc01d2d40 in ttstart (tp=0xc2bf5020) at ../../../kern/tty.c:1409
#18 0xc01d42f9 in tputchar (c=109, tp=0xc2bf5020) at ../../../kern/tty.c:2458
#19 0xc01c075b in putchar (c=109, arg=0xda0b6eb4)
at ../../../kern/subr_prf.c:305
#20 0xc01c09c2 in kvprintf (
fmt=0xc02a6921 "icrouptime() went backwards (%ld.%06ld -> %ld.%06ld)\n",
func=0xc01c070c , arg=0xda0b6eb4, radix=10, ap=0xda0b6ecc "\\n")
at ../../../kern/subr_prf.c:488
#21 0xc01c0688 in printf (
fmt=0xc02a6920 "microuptime() went backwards (%ld.%06ld -> %ld.%06ld)\n")
at ../../../kern/subr_prf.c:261
#22 0xc01a2a17 in calcru (p=0xd9fbb880, up=0xda0b5cd0, sp=0xda0b5cd8, ip=0x0)
at ../../../kern/kern_resource.c:640
#23 0xc01a2f8f in getrusage (p=0xd9fbb880, uap=0xda0b6f80)
at ../../../kern/kern_resource.c:719
#24 0xc0277f79 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 4, tf_esi = 675146872, tf_ebp = 136366288, tf_isp = -636784684,
tf_ebx = 675227280, tf_edx = 136366316, tf_ecx = 675052402,
tf_eax = 117, tf_trapno = 0, tf_err = 2, tf_eip = 677466309, tf_cs = 31,
tf_eflags = 535, tf_esp = 136366248, tf_ss = 47})
at ../../../i386/i386/trap.c:1117
#25 0xc026a4fd in syscall_with_err_pushed ()
#26 0x283c6c0b in ?? ()
#27 0x283b7d3e in ?? ()
#28 0x283b7b1d in ?? ()
#29 0x283ba242 in ?? ()
#30 0x283b9f25 in ?? ()
#31 0x283b1e10 in ?? ()
#32 0x80944b7 in ?? ()
#33 0x80b2387 in ?? ()
#34 0x80b20ee in ?? ()
#35 0x80b2962 in ?? ()
#36 0x80617c7 in ?? ()
#37 0x80610e3 in ?? ()
#38 0x8060a3e in ?? ()
#39 0x283cdb08 in ?? ()
#40 0x283cd91a in ?? ()
#41 0xbfbffae8 in ?? ()
#42 0x0 in ?? ()
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Raid Controller reconditioning
i'm running stable4.3 on Dell poweredge 2500 with PERC 3/Di controller which is causing a problem. the support battery on the controller is being discharged on irregular basis and when fully discharged it freezes the system. After rebooting the system the console displays: aac0: ** Battery charge is now OK this message is displayed on the console after approx. 2-3 mins of running. there is no way the battery would be fully recharged after such a short time. Being it a new system the battery has not been fully charged and dischardged to gain full working capacity. come on guys, what's going on here?!, is anyone running 4.3 on Poweredge 2500, has anyone got similar problems? i've checked it with 'stable guys' and no messages no suggestion, nothing. perhaps it's me, overlooking something, but the server goes down at least once a week thank you -- Tomas Palfi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi.ko
Mike Smith <[EMAIL PROTECTED]> writes:
> I am assuming you're using an ALi chipset of some sort? Your bugreport
> dosn't seem to indicate that. If all you're having trouble with is the
> timecounter, turn it off.
Yes, an ALI Aladdin V, and I reported this several weeks ago when the
ACPI timer code was first introduced.
Other problems: recent -CURRENT kernels have an average uptime of
about ten minutes ("bremfree: bp 0xcd04f5a0 not locked"), and older
kernels, when loaded with a new boot loader, fail to probe / attach
ISA devices (kbd, sio). I'm currently running a loader / kernel combo
from August 22 (which has issues with the syncer, causing horrible
interrupt latency, but at least it doesn't panic every ten minutes or
so).
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP! DAO mode added to burncd/ATA driver...
Due to new ioctl's and a rearrange of the old ones make sure that burncd & kernel is in sync or wierd things can happen. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New ACPI dangerous false devices
I think you had better supply some more information, such as entire dmesg output after "boot -v". Kazu >With new ACPI and my ASUS TUSL2-C I got following false devices >configured: > >sio1: configured irq 3 not in bitmap of probed irqs 0 >sio1 port 0-0x7 irq 3 on acpi0 >sio1: type 8250 > >(I disable sio1 in BIOS, it must not assign irq 3 here) > >sc1: on isa0 >sc1: MDA <16 virtual consoles, flags=0x0> > >(I have no sc1 or MDA) > >sio1 maked by ACPI is dangerous ineed because when try to write something >to /dev/cuaa1 I got system lockup. Please do something with it. > >Also I got lots of: > >fdc1: cannot reserve I/O port range (6 ports) >ppc1: cannot reserve I/O port range > >I don't think they are dangerous because no devices created. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
