kernel problem
hello i got a problem with my 6.0 GENERIC kernel i have done a kgdb on the dumps it gave out here is the output [EMAIL PROTECTED]kgdb kernel.debug /usr/local/var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd. Unread portion of the kernel message buffer: instruction pointer = 0x20:0xc08badd7 stack pointer = 0x28:0xd4496cc8 frame pointer = 0x28:0xd4496ccc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 30 (irq19: em0) trap number = 30 panic: unknown/reserved trap Uptime: 46m5s Dumping 511 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) hope this helps you help me !DSPAM:437315ac6516536821444! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel problem
On 11/10/05, Jens Holmqvist [EMAIL PROTECTED] wrote:
hello i got a problem with my 6.0 GENERIC kernel
i have done a kgdb on the dumps it gave out here is the output
[EMAIL PROTECTED]kgdb kernel.debug /usr/local/var/crash/vmcore.1
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
instruction pointer = 0x20:0xc08badd7
stack pointer = 0x28:0xd4496cc8
frame pointer = 0x28:0xd4496ccc
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 30 (irq19: em0)
trap number = 30
panic: unknown/reserved trap
Uptime: 46m5s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367
351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95
79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb)
hope this helps you help me
!DSPAM:437315ac6516536821444!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
i forgot to do a backtrace so here is a new kgdb output
[EMAIL PROTECTED]kgdb kernel.debug /usr/local/var/crash/vmcore.2
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
instruction pointer = 0x20:0xc08badd7
stack pointer = 0x28:0xd4496cc8
frame pointer = 0x28:0xd4496ccc
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 30 (irq19: em0)
trap number = 30
panic: unknown/reserved trap
Uptime: 56m17s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) quit
[EMAIL PROTECTED]kgdb kernel.debug /usr/local/var/crash/vmcore.2
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
instruction pointer = 0x20:0xc08badd7
stack pointer = 0x28:0xd4496cc8
frame pointer = 0x28:0xd4496ccc
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 30 (irq19: em0)
trap number = 30
panic: unknown/reserved trap
Uptime: 56m17s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc069d978 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc069dca6 in panic (fmt=0xc0943594 unknown/reserved trap) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc08c4968 in trap_fatal (frame=0xd4496c88, eva=0) at
/usr/src/sys/i386/i386/trap.c:833
#4 0xc08c43a7 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1046961280, tf_esi = 4, tf_ebp
= -733385524, tf_isp = -733385548, tf_ebx = -1046941312, tf_edx = 0, tf_ecx
= -1046941312, tf_eax = 524870, tf_trapno = 30, tf_err = 0, tf_eip =
-1064587817, tf_cs = 32, tf_eflags = 524870, tf_esp = -1046941312, tf_ss =
-733385468}) at /usr/src/sys/i386/i386/trap.c:629
#5 0xc08b109a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc08badd7 in spinlock_exit ()
Re: kernel problem
On 11/10/05, Jens Holmqvist [EMAIL PROTECTED] wrote: [...] trap number = 30 panic: unknown/reserved trap Uptime: 46m5s Looks weird. Would you please also attach the dmesg.boot generated with boot -v (or verbose boot if you use beastie boot menu), which may be helpful for us to figure out what was happening. Cheers, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel problem
On 11/10/05, Xin LI [EMAIL PROTECTED] wrote: On 11/10/05, Jens Holmqvist [EMAIL PROTECTED] wrote: [...] trap number = 30 panic: unknown/reserved trap Uptime: 46m5s Looks weird. Would you please also attach the dmesg.boot generated with boot -v (or verbose boot if you use beastie boot menu), which may be helpful for us to figure out what was happening. Cheers, ok here is my dmesg when i started it in verbose Copyright (c) 1992-2005 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 6.0-STABLE #0: Tue Nov 8 03:32:10 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0b55000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0b55188. Calibrating clock(s) ... i8254 clock: 1193368 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1400600893 Hz CPU: AMD Athlon(tm) XP 1600+ (1400.60-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0480800SYSCALL,MP,MMX+,3DNow+,3DNow Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f6b7fff, 514404352 bytes (125587 pages) avail memory = 515964928 (492 MB) MP Configuration Table version 1.4 found at 0xc00f1400 Table 'FACP' at 0x1fff3040 Table 'APIC' at 0x1fff6b00 MADT: Found table at 0x1fff6b00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: VIA694 AWRDACPI bios32: Found BIOS32 Service Directory header at 0xc00fb030 bios32: Entry = 0xfb4a0 (c00fb4a0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb4d0 pnpbios: Found PnP BIOS data at 0xc00fbfa0 pnpbios: Entry = f:bfd0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12 (edge, high) ioapic0: intpin 13 - ISA IRQ 13 (edge, high) ioapic0: intpin 14 - ISA IRQ 14 (edge, high) ioapic0: intpin 15 - ISA IRQ 15 (edge, high) ioapic0: intpin 16 - PCI IRQ 16 (level, low) ioapic0: intpin 17 - PCI IRQ 17 (level, low) ioapic0: intpin 18 - PCI IRQ 18 (level, low) ioapic0: intpin 19 - PCI IRQ 19 (level, low) ioapic0: intpin 20 - PCI IRQ 20 (level, low) ioapic0: intpin 21 - PCI IRQ 21 (level, low) ioapic0: intpin 22 - PCI IRQ 22 (level, low) ioapic0: intpin 23 - PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 Version 0.2 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x err: 0x0001 pcm: 0x0001 wlan: 802.11 Link Layer random: entropy source, Software, Yarrow nfslock: pseudo-device io: I/O mem: memory Pentium Pro MTRR support enabled null: null device, zero device npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30991106) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fdef0 PCI-Only Interrupts: 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 16 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 16 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 16 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 16 D 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 15 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 15 B 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 15 C 0x03 3 4
Re: compile kernel problem
Kris Kennaway wrote: On Thu, Feb 10, 2005 at 02:39:38AM +0100, Ivan Roth wrote: no, I don't think so. I read carefully the handbook's section and I quote it: I said to read the comments in the GENERIC kernel, not the handbook. e.g. if you commented out SCSI support, you probably left in the USB mass storage device (umass), which requires SCSI and will leave your kernel uncompilable. Kris ok. I didn't know that and should have read more carrefully :) but it doesn't matter since I realized I need the SCSI support. But for example, do I need to keep all the lines for the SCSI peripherals or can I keep just some of them. How to know if iPod need this one or this other line? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
compile kernel problem
I got problems when trying to compile my new kernel on 5.3-release. I didn't go to stable yet cause I never did it (really new to unix...) and I heard that it was better to customize the system first (?). But when I put a # before lines I don't need like all RAID and SCSI options, kernel don't want to make properly. Can somebody helps? Or is it a question for another list? thanks, Ivan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compile kernel problem
I just try it again cause I didn't want to annoy anybody and it worked! (?) I left the SCSI lines cause I use an iPod (and it seems to be an SCSI drive inside). I commented all the RAID lines and compilation succeeded. Now can you tell me how to be sure that my kernel conf is optimized? I attached my actual kernel. Thanks for your help, I really appreciate it. my physical conf is: AMD Sempron 2400+ (slowed at 1333 MHz cause of only PC 2100 DDR) ASUS A7V8X-X motherboard asus DVD writer 80 GB maxtor HDD one floppy drive ATI Radeon 64 MB DDR VIVO (if VIVO is useable on freeBSD I'd like to know how :) I think I didn't forget anything. Thanks, Ivan. # # TENSHI -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.6.2.2 2004/10/24 18:02:52 scottl Exp $ machine i386 cpu I686_CPU ident TENSHI # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options CPU_ENABLE_SSE # used by DVD options USER_LTD# used by many apps options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci device sound device snd_emu10k1 # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym
Re: compile kernel problem
On Thu, Feb 10, 2005 at 01:23:16AM +0100, Ivan Roth wrote: I got problems when trying to compile my new kernel on 5.3-release. I didn't go to stable yet cause I never did it (really new to unix...) and I heard that it was better to customize the system first (?). But when I put a # before lines I don't need like all RAID and SCSI options, kernel don't want to make properly. Because you put in too many #. Read the comments carefully, they tell you what you can and can't comment out together. Kris pgp3Wc4umC5TD.pgp Description: PGP signature
Re: compile kernel problem
no, I don't think so. I read carefully the handbook's section and I quote it: SCSI controllers. Comment out any you do not have in your system. If you have an IDE only system, you can remove these altogether. SCSI peripherals. Again, comment out any you do not have, or if you have only IDE hardware, you can remove them completely. Supported RAID controllers. If you do not have any of these, you can comment them out on http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html or remove them. first I didn't use my ipod so I removed all that lines and it didn't work. I don't think the number of commented lines is limited...am I wrong? Nevermind, the problem is solved since I compiled it succesfully just with RAID off. Now can somebody help me about configuring my kernel in a more personal way? I forgot to mention that I have two Ethernet cards on PCI slots and one on the motherboard. I also have a sound card. I hope I am not too boring. Just tell it if I am. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compile kernel problem
On Thu, Feb 10, 2005 at 02:39:38AM +0100, Ivan Roth wrote: no, I don't think so. I read carefully the handbook's section and I quote it: I said to read the comments in the GENERIC kernel, not the handbook. e.g. if you commented out SCSI support, you probably left in the USB mass storage device (umass), which requires SCSI and will leave your kernel uncompilable. Kris pgp0uB1EwMM2g.pgp Description: PGP signature
Re: SMP kernel problem
On Friday 09 August 2002 04:28 pm, Bob M. wrote: | I also get the SMP: AP CPU | #1 Launched! message at the end. : I'm new to | FreeBSD, but I figured if I get one boot mesg that looks like it detects | and launches both cpu's at the beginning and one that says #1 CPU launched | and never mentions cpu0 something ain't right. Why would I get that? The system never launches CPU #0 because of course the first processor has to *already* be running in order for the system to boot in the first place. So by the time things are far enough along for it to be possible to print a message, the first CPU (#0) has already been running for millions of cycles. -- Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) http://www.babbleon.org http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: building kernel problem w/ linux_proto.h
in message [EMAIL PROTECTED], wrote Brian T. Schellenberger thusly... On Sunday 06 January 2002 10:28 am, parv wrote: hi, i cvsup'd old sources (4-stable oct 13 2001) to current (4-stable 2002.01.05.15.45.19). at this point i am stuck at errors w/ linux_proto.h ... first i ran make cleandir in /usr/src, removed /usr/obj/*, and tried to build kernel. after first snag, i searched the internet which indicated to read src/UPDATING. well, first i did make modules-clean in src/sys/compile/$KERNCONF as i do not have MODULES_WITH_WORLD=yes in /etc/make.conf. after that when i tried again, it failed. so i tried again after running make cleandir in src/sys/modules/linux w/o any success. This is probably a more subtle fix than this, but the following is what finally worked for me: rm -r /usr/obj rm -r /usr/src cvsup /root/sup/conf ln -s /root/BTS /usr/src/sys/i386/conf ... CAUTION2: Without a broadband, this would be tiresome--it causes the entire source to be re-downloaded from the net. you know what, that's exactly what i am doing right now... it started at 2.43p edt, and currently cvsup is downloading src/contrib/ncurses; time now is 6.23p. a long way to go on dial up connection. NOTE: There is almost certainly a more subtle solution. But if you have a fast connection, just doing the above is probably a lot easier less frustrating than tracking it down. i would sure hope that somebody else will track it down, as doing fresh cvsup of src tree needs patience, at least on dial up connection. thanks brian. - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: building kernel problem w/ linux_proto.h
The UPDATING instructions also didn't work for me, though I did this over a month ago. I seem to recall that rm -rf /usr/src/sys/modules/linux /usr/src/sys/compat/linux followed by a cvsup; make buildworld make buildkernel got things going again. A bit of a sledgehammer, I admit. jay parv wrote: in message [EMAIL PROTECTED], wrote M. Warner Losh thusly... In message: [EMAIL PROTECTED] parv [EMAIL PROTECTED] writes: ... : well, first i did make modules-clean in src/sys/compile/$KERNCONF : as i do not have MODULES_WITH_WORLD=yes in /etc/make.conf. after : that when i tried again, it failed. so i tried again after running : make cleandir in src/sys/modules/linux w/o any success. If you are building the kernel by hand, try rm -rf modules in src/sys/compile/$KERNCONF. yes, sometimes i build kernel by hand; and since 4-stable, i build kernel w/ world every time via KERNCONF. i did try that; didn't work. then i tried after obliterating the src/sys/compile/$KERNCONF, that didn't work either. unless, somebody has any other option, i will try w/ clean cvsup'd src tree. before i do that, is there anything else that i could do manually? - parv To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: building kernel problem w/ linux_proto.h
On Sunday 06 January 2002 10:28 am, parv wrote: hi, i cvsup'd old sources (4-stable oct 13 2001) to current (4-stable 2002.01.05.15.45.19). at this point i am stuck at errors w/ linux_proto.h -- which had been reported at least since nov. 2001 to this month. first i ran make cleandir in /usr/src, removed /usr/obj/*, and tried to build kernel. after first snag, i searched the internet which indicated to read src/UPDATING. well, first i did make modules-clean in src/sys/compile/$KERNCONF as i do not have MODULES_WITH_WORLD=yes in /etc/make.conf. after that when i tried again, it failed. so i tried again after running make cleandir in src/sys/modules/linux w/o any success. at this point would above two steps help if i revert to earlier sources, and then back to current -stable? any other pointers? This is probably a more subtle fix than this, but the following is what finally worked for me: rm -r /usr/obj rm -r /usr/src cvsup /root/sup/conf ln -s /root/BTS /usr/src/sys/i386/conf CAUTION1: This wipes out your kernel configuration. I keep mine in /root all the time (I back up /root but not /usr/src), so I could just re-link it after the wipe (my kernel config is called BTS). If you don't, stuff it away someplace safe. CAUTION2: Without a broadband, this would be tiresome--it causes the entire source to be re-downloaded from the net. NOTE: There is almost certainly a more subtle solution. But if you have a fast connection, just doing the above is probably a lot easier less frustrating than tracking it down. -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) http://www.babbleon.org --- Free Dmitry Sklyarov! (let him go home) --- http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: harddisk faillure or kernel problem ?
I have been told these can be caused by cable problems or even other things on the pci bus so the data just didnt get through with a correct crc. I think my troubles started when I reorganized some drives, and went away when I used an 80 pin cable for the affected drive. The drive was only ata33 but the extra grounding present in the cable seems to help keep data sane. Maybe a shorter, better cable would help you. I'd avoid kinking or looping the cable and try to keep it reasonably away from other things if possible. On Thu, 24 May 2001, Stephan van Beerschoten wrote: Oops, I accidently mailed this to -CURRENT. Sorry folks. I bounced it to -STABLE On Wed, 23 May 2001, Stephan van Beerschoten wrote: For a while now I keep having the following logentries in my messages file: May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 1704031 of 720912-720913 (ad0s1 bn 17040 31; cn 1803 tn 3 sn 7) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 2857979 of 1297886-1297887 (ad0s1 bn 285 7979; cn 3024 tn 4 sn 47) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 3689535 of 1713664-1713677 (ad0s1 bn 368 9535; cn 3904 tn 4 sn 3) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4198463 of 1968128-1968129 (ad0s1 bn 419 8463; cn 4442 tn 12 sn 17) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4607039 of 2172416-2172419 (ad0s1 bn 460 7039; cn 4875 tn 2 sn 38) retrying Is this because of some UDMA option in my kernel that I have or may have missed, or is this really hardware ? I've had this for months now and never actually bothered because it never gave me any problems, at least not noticable ones. I use the machine remotely mainly, so harddisk speeds that may have dropped because of this are hardly noticable if you're just doing commandline work. Diagnoses: Do I need to replace hardware here, or not ? FreeBSD .xx.xxx.xx.xx 4.3-STABLE FreeBSD 4.3-STABLE #3: Tue May 15 20:23:48 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENIGMA i386 Thanks, Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To err is human, to forgive is Not Company Policy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To err is human, to forgive is Not Company Policy 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-stable in the body of the message
Re: harddisk faillure or kernel problem ?
I have been told these can be caused by cable problems or even other things on the pci bus so the data just didnt get through with a correct crc. I think my troubles started when I reorganized some drives, and went away when I used an 80 pin cable for the affected drive. The drive was only ata33 but the extra grounding present in the cable seems to help keep data sane. Maybe a shorter, better cable would help you. I'd avoid kinking or looping the cable and try to keep it reasonably away from other things if possible. On Wed, 23 May 2001, Stephan van Beerschoten wrote: For a while now I keep having the following logentries in my messages file: May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 1704031 of 720912-720913 (ad0s1 bn 17040 31; cn 1803 tn 3 sn 7) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 2857979 of 1297886-1297887 (ad0s1 bn 285 7979; cn 3024 tn 4 sn 47) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 3689535 of 1713664-1713677 (ad0s1 bn 368 9535; cn 3904 tn 4 sn 3) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4198463 of 1968128-1968129 (ad0s1 bn 419 8463; cn 4442 tn 12 sn 17) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4607039 of 2172416-2172419 (ad0s1 bn 460 7039; cn 4875 tn 2 sn 38) retrying Is this because of some UDMA option in my kernel that I have or may have missed, or is this really hardware ? I've had this for months now and never actually bothered because it never gave me any problems, at least not noticable ones. I use the machine remotely mainly, so harddisk speeds that may have dropped because of this are hardly noticable if you're just doing commandline work. Diagnoses: Do I need to replace hardware here, or not ? FreeBSD .xx.xxx.xx.xx 4.3-STABLE FreeBSD 4.3-STABLE #3: Tue May 15 20:23:48 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENIGMA i386 Thanks, Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To err is human, to forgive is Not Company Policy 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-stable in the body of the message
Re: custom kernel problem
Hi! The result of the 'file' command on the generated core file (if any) would help knowing which tool really segfault! Phil. On 18 Aug, Greg Prosser wrote: Is it the compiler or make that is segfaulting? Better phrasing: Do any other system binaries segfault? Is there a noticeable pattern or perhaps similarities? The last time I worked on a machine where make/other stuff started segfaulting, it turned out to be 'cc' segfaulting, and that was at the fault of either some bad ram, or other hardware issues. The machine doing this was an OC'd cpu, and when it was restored to normal speed I'm told the problems stopped, but I'm not sure. If it is make that is segfaulting, on the other hand, and if nothing else appears to have the problem, try going into /usr/src and just rebuilding make, perhaps one of your compiles went bad in the past. /gp on Fri, 18 Aug 2000, zshack babbled .. ;; this system is on a cyrix processer ;; any idea why its seg faulting?? ;; ;; ;; su-2.04# /usr/sbin/config PIGLET ;; Don't forget to do a ``make depend'' ;; Kernel build directory is ../../compile/PIGLET ;; su-2.04# cd ../../compile/PIGLET ;; su-2.04# make depend ;; Segmentation fault (core dumped) ;; ;; ;; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
In message [EMAIL PROTECTED] "Francisco Reyes" writes: : /usr/libexec/ld-elf.so.1: Shared object "libc.so.4" not found UPDATING says: [5] If you get warnings from ld-elf.so that it cannot load libc.so, run 'ldconfig -R /usr/obj/usr/src/lib/libc' and repeat the installworld target. But you may need to substitute your own values of "/usr/obj" and "/usr/src" in the above path. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
In message [EMAIL PROTECTED] Joe Royce writes: : An alternative method of building a kernel is: : : cd /usr/src/usr.bin/genassym : make depend all install clean : cd ../../usr.sbin/config : make depend all install clean : cd ../../sys/i386/conf : config YOUR_KERNEL_HERE : cd ../../compile/YOUR_KERNEL_HERE : make depend make : make install : : Then continue with the rest of the instructions. This alternative method has been known to have problems, which is why I replaced it with the method that currently is in UPDATING. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
In message [EMAIL PROTECTED] "Francisco Reyes" writes: : Would someone please send-pr the current instructsions to go : from 3.4 to 4.X Stable. cvsup to get 4.x stable cat /usr/src/UPDATING Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
In message [EMAIL PROTECTED] "Francisco Reyes" writes: : clarification... I mean to say if someone would send-prg to : update /usr/src/UPDATING. What update is needed? The instructions worked fine for me last time I tried it? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
In message [EMAIL PROTECTED] "Francisco Reyes" writes: : For one they are missing the references about genassym. No. They aren't. You don't need to build genassym. Buildkernel takes care of all of that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel problem building from 3.4 stable to 4.X stable
On Mon, Jun 26, 2000 at 07:27:01AM -0400, Francisco Reyes wrote: Following the instructions from UPDATING. When I get to the point of building the kernel I get a number of syntax errors and the last line reports: Specify machine type, e.g. ``machine vax'' I tried to put single and double quotes to my "machine" line with no luck. The archives returned two questions on this and one answer suggesting to put quotes which I already did. Francisco I believe 4.x does not require quotes. Try without. -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
