Re: Un-install upgrade application software
I have installed application software from port collection . How do I make un-install ? If I want to upgrade the existing application , how do I upgrade them ? Please advise Please ask this question on [EMAIL PROTECTED] M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GENERIC Kernel Panic
I own and MSI 694D Pro MoBo. It's a VIA 694x chip based dual P-III board. I recently installed a version of 5.0 from March, and it was running fine. I cvsup'd and rebuilt everything Friday night. When I tried to boot the new kernel it was panicing on a call to destroy_dev() on device 154/0 which I believe is an asr device (Adaptec Scsi controller of some sort). Here is what it looked like Pentium Pro MTRR support enabled Warning: devsm() called on 154/0 Warning: Driver mistake: destroy_dev on 154/0 panic don't do that debugger (panic) Stopped at Debugger + 0x44: pushl %ebx db So I found the code in kern_conf.c that makes the call to panic and just commented out the panic and rebuilt the kernel. I did this based on the cvs log entry about 2 file revs back and also the fact that I noticed the orginial kernel I installed from March had the same warnings but no panic and seemed to run ok. This seemed to work. I still got the warnings but no panic. So I built a custom kernel without scsi, since there isn't any in this machine. And now it runs like a champ. a dmesg from the currently good CUSTOM kernel is attatched. I am guessing it was erroneously trying to build an asr device then realizing there wasn't one and destroying it. Is this correct? If you need any more info on this from the debugger let me know I still have a copy of a GENERIC kernel with this problem. -Eric Liedtke To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
So here is the dmesg
Sorry here is the attatchment. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Oct 29 03:24:52 CST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/CUSTOM Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (801.83-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 268369920 (262080K bytes) avail memory = 256995328 (250972K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel /boot/kernel/kernel at 0xc03f5000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03f50a8. Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00fdc30 npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 acpi_pcib0: Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 16 - irq 11 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 2 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd800-0xd81f irq 2 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: multimedia, audio at device 7.5 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xec00-0xec3f mem 0xd700-0xd70f,0xd710-0xd7100fff irq 11 at device 14.0 on pci0 fxp0: Ethernet address 00:d0:b7:7f:35:90 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: Option ROMs at iomem 0xc-0xcbfff,0xcc000-0xccfff on isa0 fdc1: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 ppc1: cannot reserve I/O port range sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 3093MB FUJITSU MPC3032AT [6704/15/63] at ata0-master UDMA33 ad1: 4120MB Maxtor 84320D4 [8930/15/63] at ata0-slave UDMA33 acd0: CDROM TOSHIBA CD-ROM XM-6702B at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a SMP: AP CPU #1 Launched!
Re: So here is the dmesg
Right, got it. Thanks for the ptr. -eric Yonatan Bokovza writes: see long and tedious thread in cvs-all with headline of Re: Causing known breakage (was: cvs commit: src/sys/kern kern_conf.c subr_disk.c) -Original Message- From: Eric P Liedtke [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 16:20 To: [EMAIL PROTECTED] Subject: So here is the dmesg Sorry here is the attatchment. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
David O'Brien [EMAIL PROTECTED] wrote: On Sun, Oct 28, 2001 at 02:06:00PM -, cameron grant wrote: my system with dual 1.1ghz durons identifies as: CPU: AMD Duron(tm) MP Processor (1110.94-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x670 Stepping = 0 Wonder why you get the 'MP' and I don't: CPU: AMD Athlon(tm) Processor (1194.46-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x661 Stepping = 1 The string is programmed by the BIOS into the CPU. So it depends on the BIOS. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC Kernel Panic
Eric P Liedtke [EMAIL PROTECTED] writes: Warning: devsm() called on 154/0 Warning: Driver mistake: destroy_dev on 154/0 panic don't do that Please refer to the first paragraph of section 19.2.1.4 in the handbook. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC Kernel Panic
On Mon, Oct 29, 2001 at 02:19:16PM +, Eric P Liedtke wrote: I own and MSI 694D Pro MoBo. It's a VIA 694x chip based dual P-III board. I recently installed a version of 5.0 from March, and it was running fine. I cvsup'd and rebuilt everything Friday night. When I tried to boot the new kernel it was panicing on a call to destroy_dev() on device 154/0 which I believe is an asr device (Adaptec Scsi controller of some sort). Here is what it looked like This is a known problem that was recently exposed. If you don't have an asr card you can just remove the driver from your kernel. I'll have a fix into CVS within a few hours. Scott Pentium Pro MTRR support enabled Warning: devsm() called on 154/0 Warning: Driver mistake: destroy_dev on 154/0 panic don't do that debugger (panic) Stopped at Debugger + 0x44: pushl %ebx db So I found the code in kern_conf.c that makes the call to panic and just commented out the panic and rebuilt the kernel. I did this based on the cvs log entry about 2 file revs back and also the fact that I noticed the orginial kernel I installed from March had the same warnings but no panic and seemed to run ok. This seemed to work. I still got the warnings but no panic. So I built a custom kernel without scsi, since there isn't any in this machine. And now it runs like a champ. a dmesg from the currently good CUSTOM kernel is attatched. I am guessing it was erroneously trying to build an asr device then realizing there wasn't one and destroying it. Is this correct? If you need any more info on this from the debugger let me know I still have a copy of a GENERIC kernel with this problem. -Eric Liedtke 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: devfs question
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Mike Silbersack writes: Oops, error on my part; /proc does need to exist. So, I guess the question is this: Can devfs's error handling in the case of /dev being non-existant be improved? Barely, because without /dev, how do you plan to open the console ? Mkdir(/dev) isn't an option because the rootfs is mounted R/O. You could modify devfs so it can be union-mounted on top of /; or you could hack namei to return a fake vnode for /dev so it's always present. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs question
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes: Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Mike Silbersack writes: Oops, error on my part; /proc does need to exist. So, I guess the question is this: Can devfs's error handling in the case of /dev being non-existant be improved? Barely, because without /dev, how do you plan to open the console ? Mkdir(/dev) isn't an option because the rootfs is mounted R/O. You could modify devfs so it can be union-mounted on top of /; or you could hack namei to return a fake vnode for /dev so it's always present. Right, but then again, I could also stay sane :-) -- 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: adding athlon xp to bsd.cpu.mk
On 29-Oct-01 cameron grant wrote:
from what i can see, identcpu.c fetches the cpu name using a cpuid
instruction.
The part cpuid gives you is AuthenticAMD.
The fancy name is determined by switching on the Id.
read identcpu.c. you are correct for k6 and lesser processors. the code in
question is around line 323:
do_cpuid(0x8000, regs);
nreg = regs[0];
if (nreg = 0x8004) {
do_cpuid(0x8002, regs);
memcpy(cpu_model, regs, sizeof regs);
do_cpuid(0x8003, regs);
memcpy(cpu_model+16, regs, sizeof regs);
do_cpuid(0x8004, regs);
memcpy(cpu_model+32, regs, sizeof regs);
}
-cg
Doh, my bad. :)
/me shuffles off into the corner..
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
from what i can see, identcpu.c fetches the cpu name using a cpuid
instruction.
The part cpuid gives you is AuthenticAMD.
The fancy name is determined by switching on the Id.
read identcpu.c. you are correct for k6 and lesser processors. the code in
question is around line 323:
do_cpuid(0x8000, regs);
nreg = regs[0];
if (nreg = 0x8004) {
do_cpuid(0x8002, regs);
memcpy(cpu_model, regs, sizeof regs);
do_cpuid(0x8003, regs);
memcpy(cpu_model+16, regs, sizeof regs);
do_cpuid(0x8004, regs);
memcpy(cpu_model+32, regs, sizeof regs);
}
-cg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
