kernel panic in tcp_input.c:2324
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c5a96
stack pointer = 0x10:0xcd316a98
frame pointer = 0x10:0xcd316abc
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 = 14 (swi1: net)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2233 2233 2233 2233 2233 2233 2233 2233 2233
2233 2233 2233 2233 2233 2233 2233 2233 2233 2233 2233
giving up on 1851 buffers
Uptime: 3h50m55s
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01cff9a in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d0203 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc02ee2f2 in trap_fatal (frame=0xcd316a58, eva=0)
at /usr/src/sys/i386/i386/trap.c:843
#4 0xc02edfd2 in trap_pfault (frame=0xcd316a58, usermode=0, eva=32)
at /usr/src/sys/i386/i386/trap.c:757
#5 0xc02edac0 in trap (frame=
{tf_fs = -1058209768, tf_es = -852426736, tf_ds = -1071251440, tf_edi = -1
058255824, tf_esi = 0, tf_ebp = -852399428, tf_isp = -852399484, tf_ebx = -10702
78932, tf_edx = -1058255824, tf_ecx = 1, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1071883626, tf_cs = 8, tf_eflags = 66050, tf_esp = 16, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:444
#6 0xc02ddc58 in calltrap () at {standard input}:96
#7 0xc0266729 in tcp_input (m=0xc0ec4c30, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2324
#8 0xc025fcff in ip_input (m=0xc0ee4400)
at /usr/src/sys/netinet/ip_input.c:944
#9 0xc024143e in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:236
#10 0xc01bbdc1 in ithread_loop (arg=0xc0ec2100)
at /usr/src/sys/kern/kern_intr.c:536
#11 0xc01bacb3 in fork_exit (callout=0xc01bbbf0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
(kgdb) up 7
#7 0xc0266729 in tcp_input (m=0xc0ec4c30, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2324
2324INP_INFO_WUNLOCK(tcbinfo);
--
Without the userland, the kernel is useless.
--inspired by The Tao of Programming
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
devstat_end_transaction: HELP!! busy_count for da1 is 0 (-1)!
Hello, I updated from an older CURRENT to a newer one and I am now getting a dozen kernel: devstat_end_transaction: HELP!! busy_count for da1 is 0(-1)! messages every seconds during disk activity. Any ideas about what happening? da1 is on a sym adapter: sym0: 1010-66 port 0x2000-0x20ff mem 0xfa40-0xfa401fff,0xfa402000-0xfa4023ff irq 11 at device 10.0 on pci2 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. Thanks, --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What's happened to bpf?
Added device bpf to my kernel config file, make a buildkenelinstallkernel, rebooted but there's not bpf in /dev: [EMAIL PROTECTED] flag]$ grep bpf /usr/src/sys/i386/conf/SOUTHCROSS device bpf # Berkeley packet filter [EMAIL PROTECTED] flag]$ uname -a FreeBSD southcross.skynet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Tue Mar 11 12:49:54 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS i386 [EMAIL PROTECTED] flag]$ ls /dev/bpf* ls: /dev/bpf*: No such file or directory [EMAIL PROTECTED] flag]$ I need it for tcpdump, any idea how to fix it? Thanks. -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What's happened to bpf?
Added device bpf to my kernel config file, make a buildkenelinstallkernel, rebooted but there's not bpf in /dev: [EMAIL PROTECTED] flag]$ grep bpf /usr/src/sys/i386/conf/SOUTHCROSS device bpf # Berkeley packet filter [EMAIL PROTECTED] flag]$ uname -a FreeBSD southcross.skynet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Tue Mar 11 12:49:54 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS i386 [EMAIL PROTECTED] flag]$ ls /dev/bpf* ls: /dev/bpf*: No such file or directory [EMAIL PROTECTED] flag]$ I need it for tcpdump, any idea how to fix it? Thanks. -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What's happened to bpf?
Added device bpf to my kernel config file, make a buildkenelinstallkernel, rebooted but there's not bpf in /dev: [EMAIL PROTECTED] flag]$ grep bpf /usr/src/sys/i386/conf/SOUTHCROSS device bpf # Berkeley packet filter [EMAIL PROTECTED] flag]$ uname -a FreeBSD southcross.skynet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Tue Mar 11 12:49:54 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS i386 [EMAIL PROTECTED] flag]$ ls /dev/bpf* ls: /dev/bpf*: No such file or directory [EMAIL PROTECTED] flag]$ I need it for tcpdump, any idea how to fix it? Thanks. -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's happened to bpf?
On Tue, Mar 11, 2003 at 02:07:04PM +0100, Paolo Pisati wrote: Added device bpf to my kernel config file, make a buildkenelinstallkernel, rebooted but there's not bpf in /dev: [EMAIL PROTECTED] flag]$ grep bpf /usr/src/sys/i386/conf/SOUTHCROSS device bpf # Berkeley packet filter [EMAIL PROTECTED] flag]$ uname -a FreeBSD southcross.skynet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Tue Mar 11 12:49:54 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS i386 [EMAIL PROTECTED] flag]$ ls /dev/bpf* ls: /dev/bpf*: No such file or directory [EMAIL PROTECTED] flag]$ I need it for tcpdump, any idea how to fix it? Try ls -l /dev/bpf0 instead, etc. Beware of DEVFS surprises. :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
5.0-CURRENT diskless boot recognition
Hello. As I posted prior to this question, I have problems in getting diskless started with 5.0-Current as cvsupdated today. The problem is still the same and after a night of hairloosing work I think I got closer to the problem. We use PXE as bootstrap environment, isc-dhcp and a read-only disk partition /usr/diskless conatining for each architecture we boot diskless its appropriate directory. The diskless kernels are compiled with individual 'ident Marker', have options NFS_ROOT, MD_ROOT, UNIONFS, PSEUDOFS and device md. The whole setup is as described in /etc/rc.d/initdiskless with special /conf-dir entries and this scheme works perfect under FreeBSD 4.7. FreeBSD 5.0-CURRENT seems to have problems within its bootstrap process to recognize that it is a diskless system. After the diskless station got its IP, loaded and booted the kernel I see this on screen: Mounting root from nfs: NF ROOT: MY.IP : /usr/diskless/xterm Loading configuration files. Starting file system checks: mount: / : unknown special file or filesystem Mounting NFS file system:. eval: /etc/rc.d/cleanvar: Permission denied. . . . After the last message a lot of deny error occur. I modified all the diskless-scripts in rc.d with my own echo commands to check which one gets involved, but none of them get touched! The above process looks identical of what a normal standalone machine does when booting. No wonder when diskless does not work when the init process does not recognize that it is booting diskless. We do not use BOOTP and I do not know whether FBSD 5.X does only support this scheme. We would like to stay with the NFS process. But I think technically this can not be the problem, because after the station has already booted the kernel it doesnt care what mechanism it booted from. NFS is the dominating facility and I could see, the root partition got mounted as expected. Can anyone help? Do I mark each kernel with 'ident DISKLESS' to give the init process any idea what it should do? If you need more informations about my configuration, please contact me. If someone could provide me with further informations how a init process or init scripts figures out whether it configures a diskless kernel or not, please let me know it. thanks in advance, Oliver -- MfG O. Hartmann [EMAIL PROTECTED] -- Systemadministration des Institutes fuer Physik der Atmosphaere (IPA) -- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 (Buero) FAX: +496131/3923532 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic on bootup this morning
After cvsup/rebuild today at about 14:00GMT I now get a 'page fault while in kernel mode' just after the system tries to mount the rootfs. Yesterday's kernel still works fine, and the filesystem came up clean, so I guess the new kernel didn't get far enough to write anything to disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
On Mon, Mar 10, 2003 at 10:44:34 -0500, Mike Barcroft wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Many programs (from ports too) defines _ISOC99_SOURCE to get C99 functions, but we don't sense this define currently. Here is the fix for review: Cool. I didn't realize there was an existing precedence, or I would have used it. Just search Google about _ISOC99_SOURCE and see :-) This part isn't needed... #else /*- * Deal with _ANSI_SOURCE: @@ -378,7 +381,7 @@ #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 #define__ISO_C_VISIBLE 1990 -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ +#elif defined(_ISOC99_SOURCE) /* Strict C99 env. */ #define__POSIX_VISIBLE 0 #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 ...since the next line here is: #define __ISO_C_VISIBLE 1999 Hm, I don't quite understand, which one part you mean? My patch handles 2 following cases: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. 2) _ISOC99_SOURCE without any _POSIX_C_SOURCE. In that case it overrides _ANSI_SOURCE like old _C99_SOURCE does. -- 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: What's happened to bpf?
On Tue, Mar 11, 2003 at 04:14:08PM +0200, Ruslan Ermilov wrote: Try ls -l /dev/bpf0 instead, etc. Beware of DEVFS surprises. :-) It works But, why it works like this?!?!? /me confused =P -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for da1 is 0 (-1)!
In message [EMAIL PROTECTED], Attila Nagy wri tes: Hello, I updated from an older CURRENT to a newer one and I am now getting a dozen kernel: devstat_end_transaction: HELP!! busy_count for da1 is 0(-1)! messages every seconds during disk activity. Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's happened to bpf?
On Tue, Mar 11, 2003 at 04:41:54PM +0100, Flag_reda wrote: On Tue, Mar 11, 2003 at 04:14:08PM +0200, Ruslan Ermilov wrote: Try ls -l /dev/bpf0 instead, etc. Beware of DEVFS surprises. :-) It works But, why it works like this?!?!? /me confused =P Because of device cloning; devices are created on demand. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov [EMAIL PROTECTED] writes: Hm, I don't quite understand, which one part you mean? My patch handles 2 following cases: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. I don't like this at all. The meaning of _ANSI_SOURCE is that the source is exclusively written in C89 with no BSD, POSIX, or XSI extentions. Similarly, I was intending _C99_SOURCE to be used without any POSIX. Programs looking for C99+POSIX functions should specify POSIX.1-2001, which incorporates both of these. 2) _ISOC99_SOURCE without any _POSIX_C_SOURCE. In that case it overrides _ANSI_SOURCE like old _C99_SOURCE does. Yes, _ANSI_SOURCE and any other standard constant are mutually exclusive. Defining _C99_SOURCE or _ANSI_SOURCE with some other standard constant results in unspecified behaviour. I'd like to keep things this way if you're going to rename _C99_SOURCE. Best regards, Mike BArcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's happened to bpf?
In message [EMAIL PROTECTED], Ruslan Ermilov writes: Because of device cloning; devices are created on demand. device cloning is really a wrong name for this, and I regret that I every used that term. On demand device creation is closer, but it doesn't have any sort of ring to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
isp(4) issue lead to a panic with no dump
Hey All, I've a -CURRENT box that was cvsup'd yesterday. It's a backup file server with a RAID array attached. This was a -STABLE machine at one point that I updated. The last few messages in /var/log/messages before the panic looked like this: Mar 10 15:44:34 alvin kernel: isp0: bad underrun for 124.0 (count 65536, resid 2147427327, status not marked) Mar 10 15:44:35 alvin kernel: isp0: bad underrun for 124.0 (count 49152, resid 2147451903, status not marked) Mar 10 15:44:35 alvin kernel: isp0: bad underrun for 124.0 (count 65536, resid 2147439615, status not marked) Mar 10 15:44:36 alvin kernel: isp0: bad underrun for 124.0 (count 65536, resid 2147431423, status not marked) Mar 10 15:44:38 alvin kernel: isp0: bad underrun for 124.0 (count 65536, resid 2147439615, status not marked) Mar 10 15:44:44 alvin kernel: isp0: LIP destroyed 8 active commands Mar 10 15:44:44 alvin kernel: isp0: Mbox Command Async (0x4000) with no waiters The system was busy rsync'ing data from the production file server (this system is a semi-warm mirror of the main... it pulls data twice a day). The file system is formatted as UFS1 and has soft-updates enabled. If I can get a serial dump of the next time (this is the first time I've seen it just panic and stop). The isn't the first time I've seen the isp messages. Just passing it along. Cheers, Ryan The /var/run/dmesg.boot looks like: Copyright (c) 1992-2003 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: Mon Mar 10 09:07:05 CST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ALVIN Preloaded elf kernel /boot/kernel/kernel at 0xc06d4000. Preloaded elf module /boot/kernel/acpi.ko at 0xc06d40a8. Timecounter i8254 frequency 1193182 Hz CPU: Intel Pentium III Xeon (699.29-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6a1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073733632 (1023 MB) avail memory = 1035710464 (987 MB) Changing APIC ID for IO APIC #0 from 0 to 2 on chip Changing APIC ID for IO APIC #1 from 0 to 3 on chip Programming 16 pins in IOAPIC #0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 Allocating major#253 to net Allocating major#252 to pci Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PE6450 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 ACPI-0625: *** Info: GPE Block1 defined as GPE32 to GPE63 pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fc350 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #1 intpin 1 - irq 2 IOAPIC #1 intpin 2 - irq 5 IOAPIC #1 intpin 5 - irq 10 IOAPIC #1 intpin 10 - irq 11 IOAPIC #1 intpin 15 - irq 13 pci0: display, VGA at device 4.0 (no driver attached) ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xe800-0xe8ff mem 0xfbefe000-0xfbefefff irq 2 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xe400-0xe4ff mem 0xfbefd000-0xfbefdfff irq 5 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=0, 32/253 SCBs fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xe0e0-0xe0ff mem 0xfbd0-0xfbdf,0xfd4ff000-0xfd4f irq 10 at device 7.0 on pci0 fxp0: Ethernet address 00:20:35:68:5b:23 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xe080-0xe0bf mem 0xfbc0-0xfbcf,0xfbefc000-0xfbefcfff irq 11 at device 8.0 on pci0 fxp1: Ethernet address 00:b0:d0:68:cf:9b inphy0: i82555 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge port 0x8a0-0x8af at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 UDMA33 controller port 0x8b0-0x8bf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: OHCI (generic) USB controller mem 0xfbefb000-0xfbefbfff irq 13 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports
Re: devstat_end_transaction: HELP!! busy_count for da1 is 0 (-1)!
Hello, Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. Great, thanks! --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash2 or devfs problem?
On 10-Mar-2003 Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Conrad Sabatier writes:
diff (cat file1) (cat file2)
errors out with:
diff: /dev/fd/63: No such file or directory
diff: /dev/fd/62: No such file or directory
Apparently, the nodes for the named pipes are not being created as they
should.
Is this a bash problem, or something in devfs not working as expected?
That's a good question...
Has anybody found out what the standards conformant thing is for /dev/fd ?
presently we do only 0,1 2, with the std{in,out,err} symlinks.
If we are required to do all filedescriptors, we should do so with
fdescfs by default.
OK, I took this to mean use fdescfs, so I loaded the module and tried it
again. Voila, it worked!
Thanks for the clarification there.
--
Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
On Tue, Mar 11, 2003 at 10:49:43 -0500, Mike Barcroft wrote: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. I don't like this at all. The meaning of _ANSI_SOURCE is that the source is exclusively written in C89 with no BSD, POSIX, or XSI extentions. Similarly, I was intending _C99_SOURCE to be used without any POSIX. Programs looking for C99+POSIX functions should specify POSIX.1-2001, which incorporates both of these. What to do, if, say, C99 program want to use some POSIX functions from lower (and not from higher) POSIX standard? Currently we have problem with ImageMagick - undefined prototypes for vsnprintf() and other like, because it wants right that: magick/studio.h: ... #define _GNU_SOURCE 1 #define _ISOC99_SOURCE 1 #define _POSIX_C_SOURCE 199506L #define _XOPEN_SOURCE 500 #define _LARGEFILE64_SOURCE 1 -- 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: What's happened to bpf?
On Tuesday 11 March 2003 17:06, Poul-Henning Kamp wrote: [snip] device cloning is really a wrong name for this, and I regret that I every used that term. On demand device creation is closer, but it doesn't have any sort of ring to it. ... but device on demand does have a ring to it :) -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov [EMAIL PROTECTED] writes: On Tue, Mar 11, 2003 at 10:49:43 -0500, Mike Barcroft wrote: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. I don't like this at all. The meaning of _ANSI_SOURCE is that the source is exclusively written in C89 with no BSD, POSIX, or XSI extentions. Similarly, I was intending _C99_SOURCE to be used without any POSIX. Programs looking for C99+POSIX functions should specify POSIX.1-2001, which incorporates both of these. What to do, if, say, C99 program want to use some POSIX functions from lower (and not from higher) POSIX standard? I think this is pretty rare. POSIX provides application writers with lots of time to transition away from deprecated interfaces. What functions are missing if you change _POSIX_C_SOURCE to 200112L and remove _ISOC99_SOURCE from the code you posted? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic in tcp_input.c:2324
Another panic in tcp_input while exiting gtk-gnutella.
Script started on Wed Mar 12 00:38:24 2003
melati# gdb -k kernel.debug /var/crash/vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: headlocked should be 1
panic messages:
---
panic: headlocked should be 1
syncing disks, buffers remaining... 4678 4678 4678 4678 4678 4678 4678 4678 wi0: tx
failed, retry limit exceeded
4678 4678 4678 4678 4678 4678 4678 4678 4678 4678 4678 4678
giving up on 2284 buffers
Uptime: 5m30s
Dumping 639 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt full
#0 doadump () at ../../../kern/kern_shutdown.c:239
No locals.
#1 0xc0183d60 in boot (howto=256) at ../../../kern/kern_shutdown.c:371
No locals.
#2 0xc0183fc3 in panic () at ../../../kern/kern_shutdown.c:542
td = (struct thread *) 0xc1843960
bootopt = 256
newpanic = 1
buf = headlocked should be 1, '\0' repeats 233 times
#3 0xc0202d11 in tcp_input (m=0xc1857c00, off0=20)
at ../../../netinet/tcp_input.c:2252
th = (struct tcphdr *) 0xc22ea834
ip = (struct ip *) 0xc22ea820
ipov = (struct ipovly *) 0x4410
inp = (struct inpcb *) 0xc536a000
optp = (u_char *) 0xc22ea848 \001\001\b\n
optlen = 12
len = -986328376
tlen = 1338
off = -986328376
drop_hdrlen = 52
tp = (struct tcpcb *) 0xc535d2c8
thflags = 1
so = (struct socket *) 0xc52a0c00
todrop = -986328376
acked = -986328376
ourfinisacked = -986328376
needoutput = 0
tiwin = 17424
to = {to_flags = 1, to_tsval = 813786, to_tsecr = 310864, to_cc = 0,
to_ccecho = 0, to_mss = 0, to_requested_s_scale = 0 '\0', to_pad = 0 '\0'}
taop = (struct rmxp_tao *) 0xc535d2c8
tao_noncached = {tao_cc = 3222954451, tao_ccsent = 3224621352,
tao_mssopt = 52664}
headlocked = 0
next_hop = (struct sockaddr_in *) 0x0
rstreason = -986328376
ip6 = (struct ip6_hdr *) 0x0
isipv6 = 0
#4 0xc01fb938 in ip_input (m=0xc1857c00) at ../../../netinet/ip_input.c:944
ip = (struct ip *) 0xc22ea820
fp = (struct ipq *) 0xc4fc7800
ia = (struct in_ifaddr *) 0xc4fc7800
ifa = (struct ifaddr *) 0x0
i = 0
hlen = 20
checkif = 1
sum = 0
pkt_dst = {s_addr = 1677830336}
divert_info = 0
args = {m = 0xdabf2cb8, oif = 0x0, next_hop = 0x0, rule = 0x0,
eh = 0x0, ro = 0x56d, dst = 0xc0362af4, flags = 233, f_id = {
dst_ip = 3224276871, src_ip = 3669961916, dst_port = 42304,
src_port = 49175, proto = 244 'ô', flags = 42 '*'}, divert_rule = 0,
retval = 3224243451}
#5 0xc01e8234 in swi_net (dummy=0x0) at ../../../net/netisr.c:236
ni = (struct netisr *) 0xc0315390
m = (struct mbuf *) 0xc1857c00
bits = 0
i = 0
#6 0xc0172f42 in ithread_loop (arg=0xc1831d80)
at ../../../kern/kern_intr.c:536
ithd = (struct ithd *) 0xc1831d80
ih = (struct intrhand *) 0xc1838440
td = (struct thread *) 0xc1843960
p = (struct proc *) 0xc1842be8
#7 0xc0172044 in fork_exit (callout=0xc1838440, arg=0x0, frame=0x0)
at ../../../kern/kern_fork.c:871
td = (struct thread *) 0x0
p = (struct proc *) 0xc1831d80
(kgdb) melati#
Script done on Wed Mar 12 00:38:39 2003
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT diskless boot recognition
As I posted prior to this question, I have problems in getting diskless started with 5.0-Current as cvsupdated today. The problem is still the same and after a night of hairloosing work I think I got closer to the problem. We use PXE as bootstrap environment, isc-dhcp and a read-only disk partition /usr/diskless conatining for each architecture we boot diskless its appropriate directory. The diskless kernels are compiled with individual 'ident Marker', have options NFS_ROOT, MD_ROOT, UNIONFS, PSEUDOFS and device md. The whole setup is as described in /etc/rc.d/initdiskless with special /conf-dir entries and this scheme works perfect under FreeBSD 4.7. I don't think you need MD_ROOT or UNIONFS. I also have BOOTP, BOOTP_NFSROOT and BOOTP_NFSV3. FreeBSD 5.0-CURRENT seems to have problems within its bootstrap process to recognize that it is a diskless system. After the diskless station got its IP, loaded and booted the kernel I see this on screen: Mounting root from nfs: NF ROOT: MY.IP : /usr/diskless/xterm Loading configuration files. Starting file system checks: mount: / : unknown special file or filesystem Do you have a mount point for / in fstab? I have something like this: my.nfs.ip.number:/export/current / nfs ro 0 0 Mounting NFS file system:. eval: /etc/rc.d/cleanvar: Permission denied. . . . After the last message a lot of deny error occur. I modified all the diskless-scripts in rc.d with my own echo commands to check which one gets involved, but none of them get touched! The above process looks identical of what a normal standalone machine does when booting. No wonder when diskless does not work when the init process does not recognize that it is booting diskless. The only mods that I made was to mount /var over NFS and not as a RAM disk. It would be nice if there was a knob to select that. :-) We do not use BOOTP and I do not know whether FBSD 5.X does only support this scheme. We would like to stay with the NFS process. But I think technically this can not be the problem, because after the station has already booted the kernel it doesnt care what mechanism it booted from. NFS is the dominating facility and I could see, the root partition got mounted as expected. Remember BOOTP is just a subset of DHCP. Actually the BOOTP in the kernel will first try dhcp requests before fallng back, IIRC. And it seems to need it in -current while it didn't when I last did a -stable diskless setup. Can anyone help? Do I mark each kernel with 'ident DISKLESS' to give the init process any idea what it should do? I use DLESS, so it shouldn't be necesary. :-) Well I learned a lot by watching tcpdump while it is all happening. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
On Tue, 11 Mar 2003 19:42:41 +0300, Andrey A. Chernov [EMAIL PROTECTED] said: What to do, if, say, C99 program want to use some POSIX functions from lower (and not from higher) POSIX standard? Programmer error. Either it's a C99 program or it's an old-POSIX program; it cannot be both. #define _GNU_SOURCE 1 #define _ISOC99_SOURCE 1 #define _POSIX_C_SOURCE 199506L #define _XOPEN_SOURCE 500 #define _LARGEFILE64_SOURCE 1 It is requesting contradictory namespaces, and getting what it deserves. It should not define any of these. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT diskless boot recognition
On Tue, 11 Mar 2003, John Hay wrote: : : As I posted prior to this question, I have problems in getting diskless : started with 5.0-Current as cvsupdated today. The problem is still the same : and after a night of hairloosing work I think I got closer to the problem. : : We use PXE as bootstrap environment, isc-dhcp and a read-only disk partition : /usr/diskless conatining for each architecture we boot diskless its appropriate : directory. The diskless kernels are compiled with individual 'ident Marker', : have options NFS_ROOT, MD_ROOT, UNIONFS, PSEUDOFS and device md. : The whole setup is as described in /etc/rc.d/initdiskless with special : /conf-dir entries and this scheme works perfect under FreeBSD 4.7. : :I don't think you need MD_ROOT or UNIONFS. I also have BOOTP, :BOOTP_NFSROOT and BOOTP_NFSV3. I do not have BOOTP and the other BOOTP_XXX options. When enabling this, I fall into trouble and the kernel panics. As you can see, the BOOTP-stage is left behind when the problems I have occurs. BOOTP should be necessary for loading and bootstrapping, but the kernel was already running when the fault happens. : : FreeBSD 5.0-CURRENT seems to have problems within its bootstrap process : to recognize that it is a diskless system. : : After the diskless station got its IP, loaded and booted the kernel I see this : on screen: : : Mounting root from nfs: : NF ROOT: MY.IP : /usr/diskless/xterm : Loading configuration files. : Starting file system checks: : mount: / : unknown special file or filesystem : :Do you have a mount point for / in fstab? I have something like this: : :my.nfs.ip.number:/export/current / nfs ro 0 0 No, I do not. I tried this, but without success. The problem is, as far as I can follow up, that the booted kernl/system does not know to be a diskless machine, so it goes on in initializing itself with the normal scripts and not with those especially made for diskless booting. : : Mounting NFS file system:. : eval: /etc/rc.d/cleanvar: Permission denied. : . : . : . : After the last message a lot of deny error occur. : I modified all the diskless-scripts in rc.d with my own echo : commands to check which one gets involved, but none of them : get touched! The above process looks identical of what a : normal standalone machine does when booting. No wonder when : diskless does not work when the init process does not recognize : that it is booting diskless. : :The only mods that I made was to mount /var over NFS and not as a RAM :disk. It would be nice if there was a knob to select that. :-) : : : We do not use BOOTP and I do not know whether FBSD 5.X does only support this : scheme. We would like to stay with the NFS process. But I think technically : this can not be the problem, because after the station has already booted : the kernel it doesnt care what mechanism it booted from. NFS is the dominating : facility and I could see, the root partition got mounted as expected. : :Remember BOOTP is just a subset of DHCP. Actually the BOOTP in the kernel :will first try dhcp requests before fallng back, IIRC. And it seems to :need it in -current while it didn't when I last did a -stable diskless :setup. If this is really the case, how prevent the kernel from panicing? What is the benefit of doing a bootp-bootstrap the new way compared against the way it was done in 4.X? If bootp is used, I need to reconfigure the whole stuff, especially the DHCP-server and this is not a nice work to do ... :-( : : Can anyone help? Do I mark each kernel with 'ident DISKLESS' to give the init : process any idea what it should do? : :I use DLESS, so it shouldn't be necesary. :-) : :Well I learned a lot by watching tcpdump while it is all happening. :-) : :John :-- :John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] : Thanks. Oliver -- MfG O. Hartmann [EMAIL PROTECTED] -- Systemadministration des Institutes fuer Physik der Atmosphaere (IPA) -- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 (Buero) FAX: +496131/3923532 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
crash: bwrite: need chained iodone
-CURRENT as of this week-end on a Dell Inspiron 8200 laptop.
During desktop use :
panic: bremfree: removing a buffer not on a queue
panic messages:
---
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
Uptime: 9h18m39s
Dumping 511 MB
ata0: resetting devices ..
done
16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272
288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01f4698 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01f4903 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0231bf0 in bremfreel (bp=0xce6bd4e8) at /usr/src/sys/kern/vfs_bio.c:630
#4 0xc0231b25 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:612
#5 0xc0233db3 in vfs_bio_awrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1682
#6 0xc02e346a in ffs_fsync (ap=0xe5db4910)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:257
#7 0xc02e263e in ffs_sync (mp=0xc4152600, waitfor=2, cred=0xc1509f00,
td=0xc039f1a0) at vnode_if.h:612
#8 0xc024649b in sync (td=0xc039f1a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc01f42ec in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#10 0xc01f4903 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
#12 0xc0232a7c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#13 0xc023a02b in cluster_wbuild (vp=0xc4a21124, size=16384, start_lbn=44,
len=3) at /usr/src/sys/kern/vfs_cluster.c:996
#14 0xc02396ff in cluster_write (bp=0xce6bd4e8, filesize=753664, seqcount=18)
at /usr/src/sys/kern/vfs_cluster.c:596
#15 0xc02e3fec in ffs_write (ap=0xe5db4be0)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:728
#16 0xc024e1b2 in vn_write (fp=0xc456921c, uio=0xe5db4c7c,
---Type return to continue, or q return to quit---
active_cred=0xc48e5780, flags=0, td=0xc46e2000) at vnode_if.h:417
#17 0xc0214008 in dofilewrite (td=0xc46e2000, fp=0xc456921c, fd=0,
buf=0x8e1e400, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc0213e49 in write (td=0xc46e2000, uap=0xe5db4d10)
at /usr/src/sys/kern/sys_generic.c:329
#19 0xc033a68e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 134742063, tf_edi = 677204256, tf_esi = 0,
tf_ebp = -1077939928, tf_isp = -438612620, tf_ebx = 677216484, tf_edx = 20, tf_ecx =
0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677548851, tf_cs = 31, tf_eflags =
518, tf_esp = -1077939988, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#20 0xc032a89d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
(kgdb) fr 3
#3 0xc0231bf0 in bremfreel (bp=0xce6bd4e8) at /usr/src/sys/kern/vfs_bio.c:630
630 panic(bremfree: removing a buffer not on a queue);
(kgdb) fr 11
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
795 panic(bwrite: need chained iodone);
(kgdb) list
790 (bp-b_flags B_ASYNC)
791 !vm_page_count_severe()
792 !buf_dirty_count_severe()) {
793 if (bp-b_iodone != NULL) {
794 printf(bp-b_iodone = %p\n, bp-b_iodone);
795 panic(bwrite: need chained iodone);
796 }
797
798 /* get a new block */
799 newbp = geteblk(bp-b_bufsize);
(kgdb) print bp-b_iodone
$1 = (void (*)(struct buf *)) 0xc0239320 cluster_callback
(kgdb) quit
I still have the crash dump at hand, if further forensics is necessary.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
MB_LEN_MAX undeclared (scan.c)
Hi all, I just cvsup updated my tree (this is FreeBSD CURRENT, 5.0), and make buildworld breaks with: ... cc -O -pipe -I. -I/usr/src/usr.bin/xlint/lint1 -I/usr/src/usr.bin/xlint/lint1/../arch/i386 -I/usr/src/usr.bin/xlint/lint1/../common -c /usr/src/usr.bin/xlint/lint1/tree.c cc -O -pipe -I. -I/usr/src/usr.bin/xlint/lint1 -I/usr/src/usr.bin/xlint/lint1/../arch/i386 -I/usr/src/usr.bin/xlint/lint1/../common -c /usr/src/usr.bin/xlint/lint1/func.c cc -O -pipe -I. -I/usr/src/usr.bin/xlint/lint1 -I/usr/src/usr.bin/xlint/lint1/../arch/i386 -I/usr/src/usr.bin/xlint/lint1/../common -c scan.c /usr/src/usr.bin/xlint/lint1/scan.l: In function `wccon': /usr/src/usr.bin/xlint/lint1/scan.l:769: `MB_LEN_MAX' undeclared (first use in this function) /usr/src/usr.bin/xlint/lint1/scan.l:769: (Each undeclared identifier is reported only once /usr/src/usr.bin/xlint/lint1/scan.l:769: for each function it appears in.) /usr/src/usr.bin/xlint/lint1/scan.l:769: storage size of `buf' isn't known ... shouldn't MB_LEN_MAX be defined in machine/limits.h? I couldn't find anything in UPDATING, or in the current mailing list archive, but please feel free to point me to the appropriate doc. Just in case: this is a SONY Vaio PCG-GRX626, P4 @ 1.7MHz. TIA, --Francisco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Recent alphas having newfs(8) issues?
ds10# newfs /dev/md0c fstab: /etc/fstab:0: No such file or directory /dev/md0c: 1.4MB (2880 sectors) block size 4096, fragment size 512 using 4 cylinder groups of 0.36MB, 91 blks, 192 inodes. super-block backups (for fsck -b #) at: 32, 760, 1488, 2216 ds10# fsck -n /dev/md0c fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory ** /dev/md0c (NO WRITE) ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? no Wilko, I've hit this problem first when newfs'ing /R on ds10, but have managed to fix it by running 3 fsck -y in a row, but this time inside make release. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
NCP130 wireless PCI card.
This card isn't detected by default, so I added the vendor and dev IDs to if_wi_pci.c. Now it's detected, but doesn't attach. Here's what I think are the relevant bits from dmesg. pci2: physical bus=2 map[14]: type 4, range 32, base dcf0, size 4, enabled map[18]: type 4, range 32, base dc80, size 6, enabled found- vendor=0x15e8, dev=0x0131, revid=0x01 bus=2, slot=8, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0183, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 4, range 32, base d800, size 8, enabled map[14]: type 1, range 32, base ff6ffc00, size 8, enabled found- vendor=0x11ad, dev=0x0002, revid=0x21 bus=2, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 wi0: SOHO NetBlaster II port 0xdc80-0xdcbf,0xdcf0-0xdcff irq 10 at device 8.0 on pci2 wi0: No I/O space?! device_probe_and_attach: wi0 attach returned 6 And here's some output from pciconf -vl [EMAIL PROTECTED]:8:0: class=0x028000 card=0x013115e8 chip=0x013115e8 rev=0x01 hdr=0x00 vendor = 'National Datacomm Corp.' device = 'Prism II InstantWave HR PCI card' class= network I've seen quite a few posts on the list archives and google about this problem, but none appear to contain a resolution. Any help would make me mighty happy. James. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for da1 is 0 (-1)!
In message [EMAIL PROTECTED], Attila Nagy wri tes: Hello, Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. Great, thanks! There is a patch which can be tried at: http://phk.freebsd.dk/patch/ken.patch -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MINCYLGRPS (was: 4-stable releases on -current?)
Hey, is anybody ever going to answer this email?
On Wed, Feb 26, 2003 at 02:48:10PM +0200, Ruslan Ermilov wrote:
On Tue, Feb 25, 2003 at 09:52:02PM +0200, Ruslan Ermilov wrote:
On Tue, Feb 25, 2003 at 08:02:19PM +0200, John Hay wrote:
[...]
Ok, with the patches below I can get to where it tries to build the
fixit floppy in release.10. It breaks because the floppy is too small.
I must still check to make sure it is true.
We'll know this in less than 1:30 -- I've just launched the
snapshot build for 4.x/i386 on my fast -stable box.
While I was writing it, it's already finished (successfully).
ftp://ftp.sunbay.net/pub/FreeBSD/snapshots/i386/4.x-20030225-STABLE/
OK, I've tracked it down to the differences in newfs(8) between
4.x and 5.x. In 4.x, newfs'ing a 1.44MB floppy results in a
single cylinder group, but in 5.x there's a thing called
MINCYLGRPS, which results in fewer free space on a floppy:
: # uname -r
: 4.7-STABLE
: # ./x
: Warning: Block size restricts cylinders per group to 6.
: Warning: 1216 sector(s) in last cylinder unallocated
: /dev/vn0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors
: 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g)
: super-block backups (for fsck -b #) at:
: 32
: Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on
: /dev/vn01363 01363 0% 1 3810%
: # uname -r
: 5.0-CURRENT
: # ./x
: /dev/md0c: 1.4MB (2880 sectors) block size 4096, fragment size 512
: using 4 cylinder groups of 0.36MB, 91 blks, 128 inodes.
: super-block backups (for fsck -b #) at:
: 32, 760, 1488, 2216
: Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on
: /dev/md01311 01311 0% 15090%
With this patch to newfs(8),
: Index: mkfs.c
: ===
: RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
: retrieving revision 1.74
: diff -u -p -r1.74 mkfs.c
: --- mkfs.c 22 Feb 2003 23:26:11 - 1.74
: +++ mkfs.c 26 Feb 2003 11:20:57 -
: @@ -317,7 +317,7 @@ mkfs(struct partition *pp, char *fsys)
: for ( ; sblock.fs_fpg maxblkspercg; sblock.fs_fpg += sblock.fs_frag) {
: sblock.fs_ipg = roundup(howmany(sblock.fs_fpg, fragsperinode),
: INOPB(sblock));
: - if (sblock.fs_size / sblock.fs_fpg MINCYLGRPS)
: + if (sblock.fs_size / sblock.fs_fpg (Oflag == 2 ? MINCYLGRPS : 1))
: break;
: if (CGSIZE(sblock) (unsigned long)sblock.fs_bsize)
: continue;
I still don't get the same picture as on 4.x, but it's now at least
sufficient to make release.10 happy.
: # ./x
: /dev/md0c: 1.4MB (2880 sectors) block size 4096, fragment size 512
: using 1 cylinder groups of 1.41MB, 361 blks, 416 inodes.
: super-block backups (for fsck -b #) at:
: 32
: Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on
: /dev/md01359 01359 0% 14130%
John, I'm sending you the complete patchset in another email.
Cheers,
--
Ruslan ErmilovSysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.orgThe Power To Serve
http://www.oracle.com Enabling The Information Age
FSIMG=fixit.flp
FSSIZE=1440
FSLABEL=fd1440
FSINODE=4000
dd of=${FSIMG} if=/dev/zero count=${FSSIZE} bs=1k 2/dev/null
case `uname -r` in
4.*)
DEVICE=vn0
vnconfig -s labels -c /dev/${DEVICE} ${FSIMG}
;;
5.*)
DEVICE=`mdconfig -a -t vnode -f ${FSIMG}`
;;
esac
disklabel -w -B ${DEVICE} ${FSLABEL}
newfs -i ${FSINODE} -o space -m 0 /dev/${DEVICE}c
#disklabel ${DEVICE}
df -i /dev/${DEVICE}
case `uname -r` in
4.*)
vnconfig -u ${DEVICE}
;;
5.*)
mdconfig -d -u ${DEVICE}
;;
esac
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
pgp0.pgp
Description: PGP signature
exclusive sleep mutex netisr...
I see several instances of this in /var/log/messages after cvsup'ing Monday evening and rebuilding world and kernel. I haven't seen any messages about this, so I figured I'd ask here. Message: Mar 11 17:33:30 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Can anybody supply me a clue as to what's going on here? -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
agp stuff
Hi, I get the following error (or whatever) in my bootmessage: agp0: VIA Generic host to PCI bridge mem 0xf000-0xf7ff at device 0.0 o n pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_F OUND I tried playing around in the bios but couldn't find anything that would fix this. Could this be what is causing all my nvidia problems? (and yeah, I'm running on a current kernel, not RELENG_5_0) //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Yet another panic
This morning's kernel. User PPP, cvs up.
Regards,
Vladimir~ sudo gdb -k /usr/obj/usr/src/sys/KUSHNIR/kernel.debug /usr/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0193af6
stack pointer = 0x10:0xcad27aa8
frame pointer = 0x10:0xcad27acc
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 = 14 (swi1: net)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 1822 1822 1822 1822 1822 1822 1822 1822 1822 1822
1822 1822 1822 1822 1822 1822 1822 1822 1822 1822
giving up on 1705 buffers
Uptime: 1h50m45s
Dumping 191 MB
ata2: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc019dfd3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc019e233 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc02cca52 in trap_fatal (frame=0xcad27a68, eva=0)
at /usr/src/sys/i386/i386/trap.c:843
#4 0xc02cc732 in trap_pfault (frame=0xcad27a68, usermode=0, eva=32)
at /usr/src/sys/i386/i386/trap.c:757
#5 0xc02cc220 in trap (frame=
{tf_fs = -1039532008, tf_es = 16, tf_ds = 16, tf_edi = -1059808208, tf_esi = 0,
tf_ebp = -892175668, tf_isp = -892175724, tf_ebx = -1070454004, tf_edx = -1059808208,
tf_ecx = -1035515156, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1072088330,
tf_cs = 8, tf_eflags = 66050, tf_esp = 16, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:444
#6 0xc02bc4d8 in calltrap () at {standard input}:96
#7 0xc021fb69 in tcp_input (m=0xc0d49c30, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2324
#8 0xc0218b26 in ip_input (m=0xc0d55000)
at /usr/src/sys/netinet/ip_input.c:944
#9 0xc020bfbb in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:236
#10 0xc0189e51 in ithread_loop (arg=0xc0d47100)
at /usr/src/sys/kern/kern_intr.c:536
#11 0xc0188d53 in fork_exit (callout=0xc0189c80 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
(kgdb) quit
Re: What's happened to bpf?
Daniel C. Sobral wrote: device cloning is really a wrong name for this, and I regret that I every used that term. On demand device creation is closer, but it doesn't have any sort of ring to it. Worst of all, device cloning is one of Terry's buzzwords. :-) Actually, it's an SVR4/AIX/Solaris/Any-UNIX-Except-FreeBSD buzzword. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Time drift.
I'm getting what I think is substantial time drift on my -current boxes. My home firewall in particular drifts about .42 seconds every hour. My desktop machine drifted ~350 seconds over the last 5 days. Anyone else seeing this? James. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Time drift.
On Tue, Mar 11, 2003 at 03:50:25PM -0800, James Satterfield wrote: I'm getting what I think is substantial time drift on my -current boxes. My home firewall in particular drifts about .42 seconds every hour. My desktop machine drifted ~350 seconds over the last 5 days. Anyone else seeing this? I have one machine which failes to keep decent time with ACPI enabled, but it's more like .5sec/sec. Disabling ACPI fixed that machine (it's an old thin client so I don't care if it stops being supported at some point). .42sec/hr seems to be within the relm of crappy PC hardware and is probably correctable with NTP. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Time drift.
On Tue, 11 Mar 2003, James Satterfield wrote: I'm getting what I think is substantial time drift on my -current boxes. My home firewall in particular drifts about .42 seconds every hour. My desktop machine drifted ~350 seconds over the last 5 days. .42 s/ 1 hr is about 116 ppm stability 350 s/ 5 days is about 810 ppm stability 116 ppm stability is certainly within the specification of most quartz crystals and PC southbridges. 810 ppm stability is a little sloppier than I would expect, but certainly not outside the realm of possibility. It could be a bug, but I wouldn't bet on it. The standard answer of run NTP applies. An $8.00 wristwatch has much better time accuracy that your multi-$100 PC. -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exclusive sleep mutex netisr...
Derek Tattersall wrote:
I see several instances of this in /var/log/messages after cvsup'ing
Monday evening and rebuilding world and kernel. I haven't seen any
messages about this, so I figured I'd ask here.
Message:
Mar 11 17:33:30 lorne kernel: malloc() of 64 with the following
non-sleepablelocks held:
Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0
(0xc0579160) locked @ /usr/src/sys/net/netisr.c:215
Can anybody supply me a clue as to what's going on here?
Problem with Jonathan Lemon's commit to update the NETISR code
to each have it's own queue.
The problem appears to be that the ni-ni_handler code os called
with the mtx_lock(netisr_mtx); mutex in effect, which is actually
only supposed to protect the netisrs list from deregistration or
reregistration while in the traversal loop.
Probably the most correct thing to so is probe, drop, call,
reacquire, reprobe, and restart on non-matching value (it
looks to me as if the mutex is only protecting the netisrs[]
array,y way of the NULL-ness of ni_handler, rather than the
elements in the queue ni_queue).
It seems to me that the order of operation in netisr_register()
and netisr_unregister(), and the lack of mutex protection there,
too, is broken.
My suggestion would be to sysctl the net.isr.enable on, to enable
direct dispatch as a workaround. I like that code path better for
livelock avaoidance anyway.
Otherwise, here's a patch that I think makes things work as they
are supposed to work (but the handler dispatch loop is probably
still wrong, given that it doesn't back off the mutex acquisition
and retry, and happens at clock interrupt, so a blocking mutex
acquisition is probably a bad thing there).
-- Terry*** netisr.c.oldTue Mar 11 12:12:01 2003
--- netisr.cTue Mar 11 12:24:32 2003
***
*** 75,82
KASSERT(!(num 0 || num = (sizeof(netisrs)/sizeof(*netisrs))),
(bad isr %d, num));
! netisrs[num].ni_handler = handler;
netisrs[num].ni_queue = inq;
}
void
--- 75,86
KASSERT(!(num 0 || num = (sizeof(netisrs)/sizeof(*netisrs))),
(bad isr %d, num));
! mtx_lock(netisr_mtx);
! KASSERT((netisrs[num].ni_handler == NULL)),
! (isr already registered %d, num));
netisrs[num].ni_queue = inq;
+ netisrs[num].ni_handler = handler;
+ mtx_unlock(netisr_mtx);
}
void
***
*** 87,99
KASSERT(!(num 0 || num = (sizeof(netisrs)/sizeof(*netisrs))),
(bad isr %d, num));
ni = netisrs[num];
! ni-ni_handler = NULL;
! if (ni-ni_queue != NULL) {
s = splimp();
IF_DRAIN(ni-ni_queue);
splx(s);
}
}
struct isrstat {
--- 91,108
KASSERT(!(num 0 || num = (sizeof(netisrs)/sizeof(*netisrs))),
(bad isr %d, num));
+ mtx_lock(netisr_mtx);
ni = netisrs[num];
! /* repeat drain of queue until queue is empty and mutex is held */
! while (ni-ni_queue != NULL) {
! mtx_unlock(netisr_mtx);
s = splimp();
IF_DRAIN(ni-ni_queue);
splx(s);
+ mtx_lock(netisr_mtx);
}
+ ni-ni_handler = NULL;
+ mtx_unlock(netisr_mtx);
}
struct isrstat {
***
*** 199,204
--- 208,214
struct netisr *ni;
struct mbuf *m;
u_int bits;
+ u_int obits;
int i;
#ifdef DEVICE_POLLING
const int polling = 1;
***
*** 207,212
--- 217,223
#endif
mtx_lock(netisr_mtx);
+ restart:
do {
bits = atomic_readandclear_int(netisr);
if (bits == 0)
***
*** 220,225
--- 231,238
printf(swi_net: unregistered isr %d.\n, i);
continue;
}
+ obits = bits;
+ mtx_unlock(netisr_mtx);
if (ni-ni_queue == NULL)
ni-ni_handler(NULL);
else
***
*** 229,234
--- 242,250
break;
ni-ni_handler(m);
}
+ mtx_lock(netisr_mtx);
+ if (obits != atomic_readandclear_int(netisr))
+ goto restart;
}
} while (polling);
mtx_unlock(netisr_mtx);
Re: Time drift.
I guess I've just never paid that much attention to the clock. I think it's time for me to get a real clock and setup an NTP server. Thanks. James. On Tue, 11 Mar 2003 16:24:57 -0800 (PST) Andrew P. Lentvorski, Jr. [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003, James Satterfield wrote: I'm getting what I think is substantial time drift on my -current boxes. My home firewall in particular drifts about .42 seconds every hour. My desktop machine drifted ~350 seconds over the last 5 days. .42 s/ 1 hr is about 116 ppm stability 350 s/ 5 days is about 810 ppm stability 116 ppm stability is certainly within the specification of most quartz crystals and PC southbridges. 810 ppm stability is a little sloppier than I would expect, but certainly not outside the realm of possibility. It could be a bug, but I wouldn't bet on it. The standard answer of run NTP applies. An $8.00 wristwatch has much better time accuracy that your multi-$100 PC. -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
¤é±`¥Î«~¤WºôÁÊ
Title: ±z¦³¤U¦C¯S½è¶Ü
«lÃz¡I¡I¾_¾Ù¡I¡I
±z¦³¤U¦C¯S½è¶Ü¡H
1.¨Æ·~¥ø¹Ï¤ß
2.¤£¥Ì¤ß¥¤Z
3.¤£º¡©ó²{ª¬
4.«i©ó±¹ï¥¼¨Ó
¥un±z¾Ö¦³¤W¦C¯S½è¡A§Ú̱N§K¶O°ö°V±z©Ò¦³¬ÛÃö§Þ¾¯à¤O¡A´£¨Ñ±zµ²¦Xºô¸ô¡B¹êÅé¡A¹¦ç¦í¦æ¡B
¦Y³Üª±¼Öªº³q¸ô¨Æ·~¡IÂI¿ï§Ú¡A±z´N¥i¥H±o¨ì¡I
ps:±N·|¦³±M¤H¬°±z¸Ô²Ó¸Ñ»¡³á¡I
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: exclusive sleep mutex netisr...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I see several instances of this in /var/log/messages after cvsup'ing Monday evening and rebuilding world and kernel. I haven't seen any messages about this, so I figured I'd ask here. Message: Mar 11 17:33:30 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Can anybody supply me a clue as to what's going on here? It can be ignored for now, the code path is still under the Giant lock, so this is harmless, I'll fix this soon to use a different approach; the lock was intended to protect against reentrancy. However, I'd be interested to know what is calling malloc(), if that information is in the syslog. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
FYI, -bugs is not a discussion list.
On Tue, 11 Mar 2003, Attila Nagy wrote:
The following reply was made to PR kern/49079; it has been noted by GNATS.
From: Attila Nagy [EMAIL PROTECTED]
To: Martin Machacek [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: kern/49079: panic: bwrite: buffer is not busy
Date: Tue, 11 Mar 2003 10:30:17 +0100 (CET)
Hello,
The system panics with panic: bwrite: buffer is not busy after random
time after boot if X server is running (although this is not verified to
Fix:
Would love to have one :-).
CURRENT already has a fix, in rev. 1.373 of vfs_bio.c
Could you please try to update to -CURRENT to see if this problem
disappears?
It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I
just got another one of these last night. The panic message is the same as
I've been getting, but the bremfree message is slightly different, if that
helps any.
Doug
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer not
on a queue
Uptime: 3d8h21m50s
(kgdb) bt
#0 doadump () at /usr/Local/src-current/sys/kern/kern_shutdown.c:240
#1 0xc021673e in boot (howto=260) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:371
#2 0xc0216cb0 in panic (fmt=0x0) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:542
#3 0xc02562a0 in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at /usr/Local/src-current/sys/kern/vfs_bio.c:630
#4 0xc02561c5 in bremfree (bp=0x0) at
/usr/Local/src-current/sys/kern/vfs_bio.c:612
#5 0xc02582ed in vfs_bio_awrite (bp=0x0)
at /usr/Local/src-current/sys/kern/vfs_bio.c:1682
#6 0xc02b9974 in ffs_fsync (ap=0xcdd2b8e4)
at /usr/Local/src-current/sys/ufs/ffs/ffs_vnops.c:257
#7 0xc02b8c20 in ffs_sync (mp=0xc26c1e00, waitfor=2, cred=0xc0eb6e80,
td=0xc0388bc0)
at vnode_if.h:612
#8 0xc026b00d in sync (td=0xc0388bc0, uap=0x0)
at /usr/Local/src-current/sys/kern/vfs_syscalls.c:138
#9 0xc021676a in boot (howto=256) at
/usr/Local/src-current/sys/kern/kern_shutdown.c:280
#10 0xc0216cb0 in panic (fmt=---Can't read userspace from dump, or kernel
process---
) at /usr/Local/src-current/sys/kern/kern_shutdown.c:542
#11 0xc0256a22 in bwrite (bp=0xc77310f8) at
/usr/Local/src-current/sys/kern/vfs_bio.c:795
#12 0xc025715c in bawrite (bp=0x0) at
/usr/Local/src-current/sys/kern/vfs_bio.c:1138
#13 0xc025e817 in cluster_wbuild (vp=0xc339a124, size=8192, start_lbn=16,
len=2)
at /usr/Local/src-current/sys/kern/vfs_cluster.c:996
#14 0xc025e156 in cluster_write (bp=0xc7733f60, filesize=155648,
seqcount=13)
at /usr/Local/src-current/sys/kern/vfs_cluster.c:596
#15 0xc02ba6d3 in ffs_write (ap=0xcdd2bbdc)
at /usr/Local/src-current/sys/ufs/ffs/ffs_vnops.c:728
#16 0xc0272d42 in vn_write (fp=0xc2964258, uio=0xcdd2bc78,
active_cred=0xc2d5f500,
flags=0, td=0xc2641b40) at vnode_if.h:417
#17 0xc0238359 in dofilewrite (td=0xc2641b40, fp=0xc2964258, fd=0,
buf=0x0, nbyte=512,
offset=0, flags=0) at file.h:239
#18 0xc02381bd in write (td=0xc2641b40, uap=0x200)
at /usr/Local/src-current/sys/kern/sys_generic.c:329
#19 0xc030fca3 in syscall (frame=
{tf_fs = 136577071, tf_es = 137691183, tf_ds = -1078001617, tf_edi =
151975312, tf_esi = 512, tf_ebp = -1077939400, tf_isp = -841826956, tf_ebx
= 26, tf_edx = 512, tf_ecx = 151975312, tf_eax = 4, tf_trapno = 22, tf_err
= 2, tf_eip = 677562292, tf_cs = 31, tf_eflags = 642, tf_esp =
-1077939448, tf_ss = 47})
at /usr/Local/src-current/sys/i386/i386/trap.c:1030
#20 0xc02ffe7d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
--
This .signature sanitized for your protection
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic in tcp_input.c:2324
You didn't say when your most recent upgrade was. If you're using 5.0-Release, you should upgrade to 5-current, where this problem should be fixed already. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exclusive sleep mutex netisr...
* Jonathan Lemon ([EMAIL PROTECTED]) [030312 01:12]: Date: Tue, 11 Mar 2003 18:59:15 -0600 (CST) From: Jonathan Lemon [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: exclusive sleep mutex netisr... Organization: Cc: In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I see several instances of this in /var/log/messages after cvsup'ing Monday evening and rebuilding world and kernel. I haven't seen any messages about this, so I figured I'd ask here. Message: Mar 11 17:33:30 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Can anybody supply me a clue as to what's going on here? It can be ignored for now, the code path is still under the Giant lock, so this is harmless, I'll fix this soon to use a different approach; the lock was intended to protect against reentrancy. However, I'd be interested to know what is calling malloc(), if that information is in the syslog. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message The only other bit of information I have is: Mar 10 20:55:09 lorne kernel: Bad malloc flags: 4 Mar 10 20:55:09 lorne kernel: Stack backtrace: Mar 10 20:55:09 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Mar 10 20:55:09 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 I haven't found anything that was crisper. I hope this is useful. I'll keep following the list for more info. -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic in tcp_input.c:2324
On Tue, Mar 11, 2003 at 05:24:55PM -0800, Doug Barton wrote: You didn't say when your most recent upgrade was. If you're using 5.0-Release, you should upgrade to 5-current, where this problem should be fixed already. Doug I buildworld/installworld daily. So it's not fixed. Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 breaks GCC 3.2.1-compiled code (seems OS specific)
You should send this information to the gcc folks. My understanding is that they are interested in solving problems like this. Doug On Mon, 11 Mar 2003, Dan Naumov wrote: Hello list. Since my issues are related to 5.0, I though I'd rather ask here. I've noticed an interesting problem: I am using FreeBSD 5.0-p4 and GCC 3.2.1 and if I use CPUTYPE=athlon-tbird and CFLAGS= -O2 -mmmx -m3dnow -fomit-frame-pointer -pipe, ezm3 refuses to compile AT ALL and even though AbiWord 1.0.4 does compile, it will always coredump on exit, preventing saving of any changes done to the Preferences. However, going down from -O2 to -O solved both problems. This makes me wonder what exactly is wrong, since I've used exactly the same CPUTYPE and CFLAGS under Gentoo Linux with GCC 3.2.1 for a long time and everything compiled absolutely fine. This leads me to believe that there are not only arch-specific, but also OS-specific GCC issues. Can anyone else confirm this ? Sincerely, -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Time drift.
James Satterfield wrote: I guess I've just never paid that much attention to the clock. I think it's t ime for me to get a real clock and setup an NTP server. Thanks. James. One of my gate boxes drifts about 11.5 sec a day. I use rdist to keep all my hosts at each site in sync - vital for NFS makes ! I use cron /or ppp dial up, to trigger one shot calls EG /usr/sbin/ntpdate ntp1.t-online.de to sync the gate that acts as rdist server. I havent set up an NTP server, I'm happy being an NTP client. I still havent protected myself from the ramifications of time lurches on my local net, while NFS compiling. I seem to recall one of rdist ntp offered sliding updates, the other only offered lurching updates. Maybe I'm wrong, hope so, must get back to it some time. Julian Stacey jhs @ berklix.com A few mails lost, please resend if awaiting a reply. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MB_LEN_MAX undeclared (scan.c)
Francisco Solsona [EMAIL PROTECTED] writes: Hi all, I just cvsup updated my tree (this is FreeBSD CURRENT, 5.0), and make buildworld breaks with: It doesn't sound like your tree is completely in-sync. shouldn't MB_LEN_MAX be defined in machine/limits.h? It's in revision 1.15 of limits.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exclusive sleep mutex netisr...
Derek Tattersall wrote: Mar 10 20:55:09 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: The only malloc of 64 bytes in this code path should be the transient template structure malloc (FWIW). John: did you look at my patch for the locking? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exclusive sleep mutex netisr...
Terry Lambert wrote: Derek Tattersall wrote: Mar 10 20:55:09 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: The only malloc of 64 bytes in this code path should be the transient template structure malloc (FWIW). John: did you look at my patch for the locking? Ugh. Meant Jon. Sorry. -- Terry 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: crash: bwrite: need chained iodone
I've trimmed to the relavent part of the stack.
On Tue, 11 Mar 2003, Thomas Quinot wrote:
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
#12 0xc0232a7c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#13 0xc023a02b in cluster_wbuild (vp=0xc4a21124, size=16384, start_lbn=44,
len=3) at /usr/src/sys/kern/vfs_cluster.c:996
#14 0xc02396ff in cluster_write (bp=0xce6bd4e8, filesize=753664, seqcount=18)
at /usr/src/sys/kern/vfs_cluster.c:596
#15 0xc02e3fec in ffs_write (ap=0xe5db4be0)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:728
#16 0xc024e1b2 in vn_write (fp=0xc456921c, uio=0xe5db4c7c,
---Type return to continue, or q return to quit---
active_cred=0xc48e5780, flags=0, td=0xc46e2000) at vnode_if.h:417
#17 0xc0214008 in dofilewrite (td=0xc46e2000, fp=0xc456921c, fd=0,
buf=0x8e1e400, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc0213e49 in write (td=0xc46e2000, uap=0xe5db4d10)
at /usr/src/sys/kern/sys_generic.c:329
#19 0xc033a68e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 134742063, tf_edi = 677204256, tf_esi = 0,
tf_ebp = -1077939928, tf_isp = -438612620, tf_ebx = 677216484, tf_edx = 20, tf_ecx =
0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677548851, tf_cs = 31, tf_eflags
= 518, tf_esp = -1077939988, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#20 0xc032a89d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
#11 0xc0232072 in bwrite (bp=0xce5313e0) at /usr/src/sys/kern/vfs_bio.c:795
795 panic(bwrite: need chained iodone);
(kgdb) list
790 (bp-b_flags B_ASYNC)
791 !vm_page_count_severe()
792 !buf_dirty_count_severe()) {
793 if (bp-b_iodone != NULL) {
794 printf(bp-b_iodone = %p\n, bp-b_iodone);
795 panic(bwrite: need chained iodone);
796 }
797
798 /* get a new block */
799 newbp = geteblk(bp-b_bufsize);
(kgdb) print bp-b_iodone
$1 = (void (*)(struct buf *)) 0xc0239320 cluster_callback
(kgdb) quit
Can you please print bp? I'd like to know what all of the members are. A
cluster buf should NEVER have BX_BKGRDWRITE set. This is totally bogus.
I still have the crash dump at hand, if further forensics is necessary.
Thanks!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
failed to set signal flags properly for ast()
Compile, run under gdb, then type print test() when the program receives
SIGABRT. Seems to work incorrectly on 4.7 too.
#include stdio.h
#include stdlib.h
void
test(void)
{
puts(hello);
}
int
main(int argc, char *argv[])
{
abort();
exit(0);
}
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Still getting panic on boot.
04:00 GMT Mar 12: Just cvsup'd and rebuilt with same result as 12 hours ago -- I see a kernel panic page fault while in kernel mode just after attempting to mount the root filesystem. The kernel from yesterday works fine and when I reboot the filesystems come up clean, so the new kernel nevers writes to disk, apparently. Am I the only one seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 breaks GCC 3.2.1-compiled code (seems OS specific)
In article [EMAIL PROTECTED], Dan Naumov [EMAIL PROTECTED] wrote: Since my issues are related to 5.0, I though I'd rather ask here. I've noticed an interesting problem: I am using FreeBSD 5.0-p4 and GCC 3.2.1 and if I use CPUTYPE=athlon-tbird and CFLAGS= -O2 -mmmx -m3dnow -fomit-frame-pointer -pipe, ezm3 refuses to compile AT ALL [...] Well, ezm3-1.0 has an ancient gcc-2.7.2.1 code generator spliced onto a Modula-3 front end, so it's a miracle it works under the best of circumstances. :-) I'm close to releasing version 1.1, which is based on gcc-3.2.1. There's more hope for that version. But out of curiosity, what exactly happens if you try to build ezm3 with those CPUTYPE and CFLAGS settings? Do you have the error messages? I'm surprised that CPUTYPE and CFLAGS affect the ezm3 build at all, frankly. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for rtc, vmware modules and post-500104 -current
On Wed, 5 Mar 2003 19:37:35 +0100 (MET)
Marcin CIE LAK [EMAIL PROTECTED] wrote:
See the patches enclosed to emulators/rtc
and emulators/vmware2 ports.
Tested only for -current with:
#define __FreeBSD_version 500104
Hum.. This is not work in my environment. Because MOD_LOAD initializer
didn't kick rtc_attach. I fixed this problem and merge(but ADHOC:-).
Please, anyone, check following patch.
BTW, vmmon_*.ko is not good. hum
diff -urN emulators/rtc/Makefile local/rtc/Makefile
--- emulators/rtc/Makefile Fri Mar 7 15:01:17 2003
+++ local/rtc/Makefile Tue Mar 11 16:48:46 2003
@@ -6,7 +6,7 @@
#
PORTNAME= rtc
-PORTVERSION= 2001.09.16.1
+PORTVERSION= 2002.03.05.1
CATEGORIES= emulators linux
MASTER_SITES= # none
DISTFILES= # none
diff -urN emulators/rtc/files/rtc.c local/rtc/files/rtc.c
--- emulators/rtc/files/rtc.c Sun Sep 16 16:05:18 2001
+++ local/rtc/files/rtc.c Tue Mar 11 19:40:39 2003
@@ -85,6 +85,14 @@
static int rtc_modeevent(module_t mod, int cmd, void *arg);
static struct cdevsw rtc_cdevsw = {
+#if __FreeBSD_version = 500104
+ .d_open = rtc_open,
+ .d_close = rtc_close,
+ .d_ioctl = rtc_ioctl,
+ .d_poll = rtc_poll,
+ .d_name = DEVICE_NAME,
+ .d_maj = CDEV_MAJOR,
+#else
/* open */ rtc_open,
/* close */ rtc_close,
/* read */ noread,
@@ -104,6 +112,7 @@
#if __FreeBSD_version = 500018 || __FreeBSD_version = 43
/* kqfilter */ nokqfilter,
#endif
+#endif
};
/*
@@ -118,7 +127,6 @@
static struct rtc_softc *
rtc_attach(dev_t dev)
{
- struct rtc_softc *sc;
int unit;
#if __FreeBSD_version = 500014
@@ -132,24 +140,8 @@
return dev-si_drv1;
}
- if (rtc_sc!=NULL)
- return NULL;
-
- dev = make_dev(rtc_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
- if (dev==NULL)
- return (NULL);
-
- MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
- if (sc==NULL)
- return NULL;
-
- bzero(sc, sizeof(*sc));
- rtc_sc = sc;
- dev-si_drv1 = sc; /* Link together */
- sc-dev = dev;
-
- DLog(Lexit, new %p,%p, dev, sc);
- return sc;
+ DLog(Lexit, new %p,%p, dev, rtc_sc);
+ return rtc_sc;
}
static int
@@ -264,11 +256,26 @@
static int
init_module(void)
{
-int error;
+ int error = 0;
+ dev_t dev;
+#if __FreeBSD_version 500104
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if (dev==NULL)
+ return ENOMEM;
+
+ MALLOC(rtc_sc, struct rtc_softc*, sizeof(*rtc_sc), M_DEVBUF, M_WAITOK);
+ if (rtc_sc==NULL)
+ return ENOMEM;
+
+ bzero(rtc_sc, sizeof(*rtc_sc));
+ dev-si_drv1 = rtc_sc; /* Link together */
+ rtc_sc-dev = dev;
return error;
}
@@ -286,7 +293,9 @@
DLog(Lfail, %p busy, sc);
return error;
}
+#if __FreeBSD_version 500104
error = cdevsw_remove(rtc_cdevsw);
+#endif
DLog(Linfo, return %d, error);
return error;
}
diff -urN emulators/rtc/files/rtc.sh local/rtc/files/rtc.sh
--- emulators/rtc/files/rtc.sh Fri Sep 22 20:08:22 2000
+++ local/rtc/files/rtc.sh Tue Mar 11 16:49:55 2003
@@ -7,11 +7,11 @@
start)
if [ -x $kmoddir/$kmod ]; then
echo -n ' rtc'
- kldload $kmoddir/$kmod
+ /sbin/kldload $kmoddir/$kmod
fi
;;
stop)
- kldunload $kmod echo -n ' rtc'
+ /sbin/kldunload $kmod echo -n ' rtc'
;;
*)
echo Usage: `basename $0` {start|stop} 2
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Mar 12 00:10:07 EST 2003 -- === hifn /tinderbox/sparc64/src/sys/dev/hifn/hifn7751.c:47:22: opt_hifn.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/hifn. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock order reversal? current with tl ethernet
Running -current from March 11 on a dual cpu compaq 5100, there are some warnings in the dmesg about the tl ethernet interface. Here are the warnings: malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 malloc() of PROC with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 lock order reversal 1st 0xc4017aa8 tl0 (network driver) @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 2nd 0xc043f8c0 allproc (allproc) @ /usr/src/5-current/src/sys/kern/kern_fork.c:328 Stack backtrace: malloc() of 64 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 malloc() of 256 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 malloc() of 64 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 malloc() of 512 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:658 I'm willing to work on this myself if someone can give me a pointer to technical docs describing how things are supposed to work. I have not yet attempted to use the tl0 interface since I also have an fxp in the system, but I do plan on using it later. Here's the complete dmesg with warnings intact: Copyright (c) 1992-2003 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: Tue Mar 11 18:56:10 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/5-current/src/sys/BOROSILICATE Preloaded elf kernel /boot/kernel/kernel at 0xc0565000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 536870912 (512 MB) avail memory = 515575808 (491 MB) APIC_IO: MP table broken: 8259-APIC entry missing! Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 8, version: 0x00170011, at 0xfec0 Allocating major#253 to net Allocating major#252 to pci Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: ServerWorks NB6536 2.0HE host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 11 IOAPIC #0 intpin 17 - irq 15 pci0: display, VGA at device 3.0 (no driver attached) pci0: display, VGA at device 4.0 (no driver attached) fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0x6020-0x603f mem 0xe020-0xe02f,0xe048-0xe0480fff irq 15 at device 5.0 on pci0 fxp0: Ethernet address 00:a0:c9:c8:b6:2f inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci0: Promise TX2 UDMA100 controller port 0x6010-0x601f,0x6054-0x6057,0x6048-0x604f,0x6050-0x6053,0x6040-0x6047 mem 0xe040-0xe0403fff irq 16 at device 6.0 on pci0 ata2: at 0x6040 on atapci0 ata3: at 0x6048 on atapci0 isab0: PCI-ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 atapci1: GENERIC ATA controller port 0x6000-0x600f,0-0x3,0-0x7,0-0x3,0-0x7 irq 15 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci1 pcib1: ServerWorks NB6536 2.0HE host to PCI bridge at pcibus 1 on motherboard pci1: PCI bus on pcib1 IOAPIC #0 intpin 23 - irq 17 IOAPIC #0 intpin 20 - irq 18 IOAPIC #0 intpin 21 - irq 19 ohci0: OHCI (generic) USB controller mem 0xe000-0xefff irq 17 at device 10.0 on pci1 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x0e11) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered tl0: Compaq Netelligent 10/100 TX UTP port 0x5400-0x540f mem 0xe018-0xe018000f irq 18 at device 11.0 on pci1 malloc() of 128 with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 malloc() of PROC with the following non-sleepablelocks held: exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @ /usr/src/5-current/src/sys/pci/if_tl.c:1146 lock order reversal 1st
bad malloc flags: 4
Got this when booting a fresh kernel: Bad malloc flags: 4 Stack backtrace: backtrace(c03953d4,4,1,c035e443,c1b6e500) at backtrace+0x17 malloc(3c,c03dfe80,4,c1b85d00,dcd7bc78) at malloc+0x5b m_tag_alloc(0,e,30,4,c5a5bcc0) at m_tag_alloc+0x2f ip6_addaux(c1b85d00,dcd7bcbc,c02af378,c1b85d00,c5bab800) at ip6_addaux+0x59 ip6_setdstifaddr(c1b85d00,c5bab800,10,c020a846,c04131b4) at ip6_setdstifaddr+0x1 1 ip6_input(c1b85d00,0,c039d38a,e9,c1b63240) at ip6_input+0x8d8 swi_net(0,0,c03949e3,217,c1b705f4) at swi_net+0x112 ithread_loop(c1b6e100,dcd7bd48,c0394860,35f,0) at ithread_loop+0x182 fork_exit(c0201a60,c1b6e100,dcd7bd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdcd7bd7c, ebp = 0 --- pgp0.pgp Description: PGP signature
Re: Time drift.
In message [EMAIL PROTECTED], Andrew P. Lentvorski, Jr. writes: An $8.00 wristwatch has much better time accuracy that your multi-$100 PC. That's because the crystal in your wristwatch is cut specially so that it has a flat temp-co at about 23-16 C, whereas the xtal in your computer is has a gradient all the way from 0 to 70 C. See: http://www.corningfrequency.com/library/vig/Vig-tutorial_files/frame.htm -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bad malloc flags: 4
On Tue, 11 Mar 2003, Kris Kennaway wrote: Got this when booting a fresh kernel: Bad malloc flags: 4 Stack backtrace: backtrace(c03953d4,4,1,c035e443,c1b6e500) at backtrace+0x17 malloc(3c,c03dfe80,4,c1b85d00,dcd7bc78) at malloc+0x5b What does the output of ls -l /etc/malloc.conf look like? Regards Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bad malloc flags: 4
In message [EMAIL PROTECTED], Andre Guibert de Bruet writes: On Tue, 11 Mar 2003, Kris Kennaway wrote: Got this when booting a fresh kernel: Bad malloc flags: 4 Stack backtrace: backtrace(c03953d4,4,1,c035e443,c1b6e500) at backtrace+0x17 malloc(3c,c03dfe80,4,c1b85d00,dcd7bc78) at malloc+0x5b What does the output of ls -l /etc/malloc.conf look like? This has nothing to do with userland, it's a kernel problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Qt 3.1 on -CURRENT
Is Qt expected to work on -CURRENT? Because on my system it won't even build: [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% pcvs up [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% ident Makefile Makefile: $FreeBSD: ports/x11-toolkits/qt31/Makefile,v 1.134 2003/02/22 09:13:12 demon Exp $ [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% make configure === Extracting for qt-3.1.1_4 Checksum OK for KDE/qt-x11-free-3.1.1.tar.bz2. === Patching for qt-3.1.1_4 === Applying FreeBSD patches for qt-3.1.1_4 === Configuring for qt-3.1.1_4 === qt-3.1.1_4 depends on executable: gmake - found === qt-3.1.1_4 depends on shared library: mng.1 - found === qt-3.1.1_4 depends on shared library: png.5 - found === qt-3.1.1_4 depends on shared library: jpeg.9 - found === qt-3.1.1_4 depends on shared library: Xft.2 - found === qt-3.1.1_4 depends on shared library: glut.3 - found === qt-3.1.1_4 depends on shared library: X11.6 - found The specified system/compiler is not supported: /usr/ports/x11-toolkits/qt31/work/qt-x11-free-3.1.1/mkspecs//usr/X11R6/mkspecs/default Please see the PLATFORMS file for a complete list. === Script configure failed unexpectedly. Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the /usr/ports/x11-toolkits/qt31/work/qt-x11-free-3.1.1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/x11-toolkits/qt31. I have XFree86 4.2.1, installed from ports just last week (I clean out and reinstall all my ports with regular intervals) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [kde-freebsd] Qt 3.1 on -CURRENT
The port builds fine here on -CURRENT from 5 march. It is supposed to find the freebsd-g++ platform. If this doesn't work, try adding -platform=freebsd-g++ to the CONFIGURE_ARGS in the ports' Makefile. Best regards, Arjan On Tuesday 11 March 2003 23:47, Dag-Erling Smorgrav wrote: Is Qt expected to work on -CURRENT? Because on my system it won't even build: [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% pcvs up [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% ident Makefile Makefile: $FreeBSD: ports/x11-toolkits/qt31/Makefile,v 1.134 2003/02/22 09:13:12 demon Exp $ [EMAIL PROTECTED] /usr/ports/x11-toolkits/qt31% make configure === Extracting for qt-3.1.1_4 Checksum OK for KDE/qt-x11-free-3.1.1.tar.bz2. === Patching for qt-3.1.1_4 === Applying FreeBSD patches for qt-3.1.1_4 === Configuring for qt-3.1.1_4 === qt-3.1.1_4 depends on executable: gmake - found === qt-3.1.1_4 depends on shared library: mng.1 - found === qt-3.1.1_4 depends on shared library: png.5 - found === qt-3.1.1_4 depends on shared library: jpeg.9 - found === qt-3.1.1_4 depends on shared library: Xft.2 - found === qt-3.1.1_4 depends on shared library: glut.3 - found === qt-3.1.1_4 depends on shared library: X11.6 - found The specified system/compiler is not supported: /usr/ports/x11-toolkits/qt31/work/qt-x11-free-3.1.1/mkspecs//usr/X11R6/mksp ecs/default Please see the PLATFORMS file for a complete list. === Script configure failed unexpectedly. Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the /usr/ports/x11-toolkits/qt31/work/qt-x11-free-3.1.1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/x11-toolkits/qt31. I have XFree86 4.2.1, installed from ports just last week (I clean out and reinstall all my ports with regular intervals) DES To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [kde-freebsd] Qt 3.1 on -CURRENT
Arjan van Leeuwen [EMAIL PROTECTED] writes: The port builds fine here on -CURRENT from 5 march. It is supposed to find the freebsd-g++ platform. If this doesn't work, try adding -platform=freebsd-g++ to the CONFIGURE_ARGS in the ports' Makefile. Thanks. Turned out to be pilot error, I had QMAKESPEC set to an incorrect value in my environment. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Qt 3.1 on -CURRENT
On Tuesday 11 March 2003 23:47, Dag-Erling Smorgrav wrote: Is Qt expected to work on -CURRENT? Because on my system it won't even build: [snip] The specified system/compiler is not supported: /usr/ports/x11-toolkits/qt31/work/qt-x11-free-3.1.1/mkspecs//usr/X11R6/mkspecs/default This line is bogus... what's your environment look like? You probably have QMAKESPEC set in your environment (to /usr/X11R6/mkspecs/default), which doesn't exist on disk anymore. It's been moved to /usr/X11R6/share/qt/mkspecs/default It would probably make sense for the qt31 port to unset QMAKESPEC before configuring/building. -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FBSD 5.0 diskless environment does not work!
In message: [EMAIL PROTECTED] Hartmann, O. [EMAIL PROTECTED] writes: : Can anyone help? Has someone a runnng diskless FBSD 5.0-R/5-CURRENT : environment? I fixed a couple of bugs in the /etc/rc.d files that broke diskless boots about a month or two so after 5.0-RELEASE. It would have precluded diskless systems network from working most of the time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
