Re: filesystem corruption ?
On Tue, 17 Sep 2002, Martin Blapp wrote: Date: Tue, 17 Sep 2002 02:29:41 +0200 (CEST) From: Martin Blapp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Michael Reifenberger [EMAIL PROTECTED], Peter Wemm [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: filesystem corruption ? Hi all, It looks more and more to me that pmap does something wrong. I get pmap related vm crashes or corruption, relating in filesystem corruption. I had about 3-4 different panics. Mozilla build tends to prefer panic: bad link count, openoffice prefers page faults in ffs code ;) But these options here are enabled: optionsDISABLE_PSE optionsDISABLE_PG_G Not in my config-file After gcc32 was imported. I got panics over and over. I looked carefuly that no -march was used, so that this could be the reason. I use -march=pentium3 as CFLAGS But this doesn't seem to be related. I have had no application crashes after adding options CPU_ENABLE_SSE to my config-file but this shouldn't be necessary any longer after some recent commits for auto detection. I use now this option to get a panic even faster ( and to get a lot smaller dumps of course ) ;) options MAXMEM=(128*1024) It cannot be hardware. I've preplaced everthing on this box, including the motherboard. Michael Reifenberger has the same symptoms. I bet he has also a PIV. Wrong bet :-( It's a IBM-A30p notebook using a PIII and 1G main-mem. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
Hello! I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory There is exactly one ``stdint.h'' on my machine (in /usr/src/sys/sys). I was already told by Mike Barcroft that there should be copy in /usr/include/sys and a link to it in /usr/include. Of course this pulls is sys/_types.h and machine/_stdint.h, etc. . These will then conflict with defines in old include files also sucked in by ``usr.bin/file''. I do not see how I can get around this problem. Why is the build for ``usr.bin/file'' using old system include files at all? Regards, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: filesystem corruption ?
On 17 Sep, Michael Reifenberger wrote: On Tue, 17 Sep 2002, Martin Blapp wrote: Date: Tue, 17 Sep 2002 02:29:41 +0200 (CEST) From: Martin Blapp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Michael Reifenberger [EMAIL PROTECTED], Peter Wemm [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: filesystem corruption ? Hi all, It looks more and more to me that pmap does something wrong. I get pmap related vm crashes or corruption, relating in filesystem corruption. I had about 3-4 different panics. Mozilla build tends to prefer panic: bad link count, openoffice prefers page faults in ffs code ;) But these options here are enabled: optionsDISABLE_PSE optionsDISABLE_PG_G Not in my config-file I was seeing random-looking memory corruption on my Athlon box during repeated buildworld runs without these options. I've also got 1GB of RAM, so the source tree would remain cached in RAM after the first run. The memory corruption would show up as damage to random files in the source tree and would disappear after a reboot. A small section of the damaged file would be turned into binary garbage. The damage wouldn't show up until I'd run buildworld 5 to 8 times. The system never paniced, though that could easily be configuration and workload dependent. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: filesystem corruption ?
Hi, I was seeing random-looking memory corruption on my Athlon box during repeated buildworld runs without these options. I've also got 1GB of RAM, so the source tree would remain cached in RAM after the first run. The memory corruption would show up as damage to random files in the source tree and would disappear after a reboot. A small section of the Exactly what I see here too ! But I did not reboot then, I remade the whole filesystem. damaged file would be turned into binary garbage. The damage wouldn't show up until I'd run buildworld 5 to 8 times. The system never paniced, though that could easily be configuration and workload dependent. I'll try to reboot the next time. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Triple panic
On my current system updated yesterday, I've hit triple [sic!] panic doing cvs up of ports tree: panic: kmem_malloc(4096): kmem_map too small: 22067920 total allocated syncing disks... panic: bwrite: buffer is no busy??? Uptime: 22m0s Dumping 64 MB ata0: reseting devices .. panic: bremfree: removing buffer not on a queue Uptime: 22m1s Automatic reboot in 15 seconds... It seems that something is seriously b0rken. Any ideas are appreciated. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- 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 /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 17 03:09:54 PDT 2002 -- Kernel build for GENERIC completed on Tue Sep 17 03:34:58 PDT 2002 -- Kernel build for LINT started on Tue Sep 17 03:34:58 PDT 2002 -- === vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /h/des/src/sys/dev/dgb/dgb.c:89: /h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /h/des/src/sys/dev/dgb/dgb.c:92:2: #error The dgb device requires the old isa compatibility shims /h/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /h/des/src/sys/dev/ncv/ncr53c500.c:86: /h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /h/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /h/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /h/des/src/sys/dev/wl/if_wl.c:218: /h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /h/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /h/des/src/sys/dev/wl/if_wl.c:227:2: #error The wl device requires the old isa compatibility shims /h/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /h/des/src/sys/kern/subr_prof.c:232:2: #error /h/des/src/sys/kern/subr_prof.c:243:2: #error In file included from /h/des/src/sys/netatm/spans/spans_arp.c:66: spans_xdr.h:9:21: rpc/rpc.h: No such file or directory spans_xdr.h:55:23: rpc/types.h: No such file or directory In file included from /h/des/src/sys/netatm/spans/spans_cls.c:64: spans_xdr.h:9:21: rpc/rpc.h: No such file or directory spans_xdr.h:55:23: rpc/types.h: No such file or directory In file included from /h/des/src/sys/netatm/spans/spans_if.c:69: spans_xdr.h:9:21: rpc/rpc.h: No such file or directory spans_xdr.h:55:23: rpc/types.h: No such file or directory /h/des/src/sys/netatm/spans/spans_kxdr.c:103:23: rpc/types.h: No such file or directory /h/des/src/sys/netatm/spans/spans_kxdr.c:104:21: rpc/xdr.h: No such file or directory /h/des/src/sys/netatm/spans/spans_msg.c:61:21: rpc/rpc.h: No such file or directory In file included from /h/des/src/sys/netatm/spans/spans_msg.c:62: spans_xdr.h:9:21: rpc/rpc.h: No such file or directory spans_xdr.h:55:23: rpc/types.h: No such file or directory In file included from /h/des/src/sys/netatm/spans/spans_print.c:54: spans_xdr.h:9:21: rpc/rpc.h: No such file or directory spans_xdr.h:55:23: rpc/types.h: No such file or directory In file included from
Crashdumps available for download ... please help
Hi all,
Hope this helps people. After I've disabled the secondlevel
CPU cache, the panic is now always at the same place:
0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2937pte = vtopte(pv-pv_va);
2938#else
2939pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
2940#endif
2941tpte = *pte;
2942
2943if (tpte == 0) {
2944printf(TPTE at %p IS ZERO @ VA %08x\n,
2945pte, pv-pv_va);
Kernelfile:
http://people.freebsd.org/~mbr/crashes/kernel.debug.bz2 (8 Mb)
Kernelconfig:
http://people.freebsd.org/~mbr/crashes/kernel.CONFIG
Cores:
http://people.freebsd.org/~mbr/crashes/vmcore.1.bz2 (5 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.2.bz2 (7 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.3.bz2 (26 Mb)
Descriptions:
http://people.freebsd.org/~mbr/crashes/vmcore.1.txt
http://people.freebsd.org/~mbr/crashes/vmcore.2.txt
http://people.freebsd.org/~mbr/crashes/vmcore.3.txt
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
Robert Suetterlin wrote: I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory FYI I'm seeing the exact same error trying to build -CURRENT under 4.6-RELEASE (just cvs updated). Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Crashdumps available for download ... please help
On Tue, 17 Sep 2002, Martin Blapp wrote:
Hope this helps people. After I've disabled the secondlevel
CPU cache, the panic is now always at the same place:
0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2937pte = vtopte(pv-pv_va);
2938#else
2939pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
2940#endif
2941tpte = *pte;
2942
2943if (tpte == 0) {
2944printf(TPTE at %p IS ZERO @ VA %08x\n,
2945pte, pv-pv_va);
Try building your kernel with options PMAP_REMOVE_PAGES_CURPROC_ONLY and
see if the panic goes away. If that works, the problem is
pmap_pte_quick().
In looking at pmap_pte_quick, either it is wrong or line 2941 is wrong in
always dereferencing pte. pmap_pte_quick can return NULL (well 0). It
seems like pmap_pte_quick is wrong because vtopte() never returns NULL,
just (PTmap + i386_btop(va)) i.e. a valid base plus some offset.
-Nate
Kernelfile:
http://people.freebsd.org/~mbr/crashes/kernel.debug.bz2 (8 Mb)
Kernelconfig:
http://people.freebsd.org/~mbr/crashes/kernel.CONFIG
Cores:
http://people.freebsd.org/~mbr/crashes/vmcore.1.bz2 (5 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.2.bz2 (7 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.3.bz2 (26 Mb)
Descriptions:
http://people.freebsd.org/~mbr/crashes/vmcore.1.txt
http://people.freebsd.org/~mbr/crashes/vmcore.2.txt
http://people.freebsd.org/~mbr/crashes/vmcore.3.txt
Martin
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: Crashdumps available for download ... please help
Hi, Try building your kernel with options PMAP_REMOVE_PAGES_CURPROC_ONLY and see if the panic goes away. If that works, the problem is pmap_pte_quick(). I'll do ASAP. I'm at work at the moment, and the box in question is at home :). Thanks very much for looking into that ! In looking at pmap_pte_quick, either it is wrong or line 2941 is wrong in always dereferencing pte. pmap_pte_quick can return NULL (well 0). It seems like pmap_pte_quick is wrong because vtopte() never returns NULL, just (PTmap + i386_btop(va)) i.e. a valid base plus some offset. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Nate Lawson wrote:
0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2937pte = vtopte(pv-pv_va);
2938#else
2939pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
2940#endif
2941tpte = *pte;
2942
2943if (tpte == 0) {
2944printf(TPTE at %p IS ZERO @ VA %08x\n,
2945pte, pv-pv_va);
Try building your kernel with options PMAP_REMOVE_PAGES_CURPROC_ONLY and
see if the panic goes away. If that works, the problem is
pmap_pte_quick().
In looking at pmap_pte_quick, either it is wrong or line 2941 is wrong in
always dereferencing pte. pmap_pte_quick can return NULL (well 0). It
seems like pmap_pte_quick is wrong because vtopte() never returns NULL,
just (PTmap + i386_btop(va)) i.e. a valid base plus some offset.
Obvious fix?
#ifndef PMAP_REMOVE_PAGES_CURPROC_ONLY
pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
if (pte == NULL)
#endif
pte = vtopte(pv-pv_va);
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Nate Lawson wrote:
On Tue, 17 Sep 2002, Martin Blapp wrote:
Hope this helps people. After I've disabled the secondlevel
CPU cache, the panic is now always at the same place:
0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2937pte = vtopte(pv-pv_va);
2938#else
2939pte = pmap_pte_quick(pv-pv_pmap, pv-pv_va);
2940#endif
2941tpte = *pte;
2942
2943if (tpte == 0) {
2944printf(TPTE at %p IS ZERO @ VA %08x\n,
2945pte, pv-pv_va);
Try building your kernel with options PMAP_REMOVE_PAGES_CURPROC_ONLY and
see if the panic goes away. If that works, the problem is
pmap_pte_quick().
The problem is that this is hardwired.. line 2902 of pmap.c is:
#define PMAP_REMOVE_PAGES_CURPROC_ONLY
ie: we always use vtopte(), not pmap_pte_quick().
In looking at pmap_pte_quick, either it is wrong or line 2941 is wrong in
always dereferencing pte. pmap_pte_quick can return NULL (well 0). It
seems like pmap_pte_quick is wrong because vtopte() never returns NULL,
just (PTmap + i386_btop(va)) i.e. a valid base plus some offset.
-Nate
Kernelfile:
http://people.freebsd.org/~mbr/crashes/kernel.debug.bz2 (8 Mb)
Kernelconfig:
http://people.freebsd.org/~mbr/crashes/kernel.CONFIG
Cores:
http://people.freebsd.org/~mbr/crashes/vmcore.1.bz2 (5 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.2.bz2 (7 Mb)
http://people.freebsd.org/~mbr/crashes/vmcore.3.bz2 (26 Mb)
Descriptions:
http://people.freebsd.org/~mbr/crashes/vmcore.1.txt
http://people.freebsd.org/~mbr/crashes/vmcore.2.txt
http://people.freebsd.org/~mbr/crashes/vmcore.3.txt
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
[CC'ing David O'Brien as he did the update to 3.39] On Tue, Sep 17, 2002 at 09:38:10AM -0700, Lars Eggert wrote: Robert Suetterlin wrote: I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory FYI I'm seeing the exact same error trying to build -CURRENT under 4.6-RELEASE (just cvs updated). Add me to the list. Culprit is src/usr.bin/file/config.h which unconditionally defines HAVE_STDINT_H though RELENG_4 is missing it. Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Threads issue after latest buildworld
I just cvsup'd -CURRENT two hours ago, built world and kernel, then rebooted...same as always. Now, nautilus-2.0.7 fails to start with a thread abort. Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Fatal error '_waitq_insert: pq_active' at line 319 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 35) Abort (core dumped) I think the problem might be related to the recent KSE commit, and the change to i386's ucontext.h (mc_fpregs was removed). pthread_private.h still references this struct member. There doesn't look to be a good equivalent to mc_fpregs anymore. I see npxgetregs(), but that looks to be KSE'ish. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Hi all, If you don't beleave it or not. I've taken out again (I've already switched them once) one bank of 512M ram and since then I've not had any panics anymore. Can a ram error occur after a system has been fine one month ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
On 17-Sep-2002 Martin Blapp wrote: Hi all, If you don't beleave it or not. I've taken out again (I've already switched them once) one bank of 512M ram and since then I've not had any panics anymore. Can a ram error occur after a system has been fine one month ? Yes. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: Crashdumps available for download ... please help
Hi, I see now another possibility. I've taken out at the same time my Radeon 8500, which I'd also used in the previous system. I just noted that Michael Reifenberger, which has seen the same corruption, has - oh wonder - the same card inside. I'll try again with and without this card, and with the DRAM and without. So maybe we have now a trace where the problem could be. Sorry if I can track this down to hardware. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Martin Blapp wrote: If you don't beleave it or not. I've taken out again (I've already switched them once) one bank of 512M ram and since then I've not had any panics anymore. Can a ram error occur after a system has been fine one month ? No. This is the TLB problem we all keep talking about. Bosko had some code that might have worked around the problem (as opposed to fixing it). Ask if he'll send you the patches (you must be running -current). I just got the most recent IA-32 manuals from Intel in the mail, and they still don't seem to be aware of the issue. Without actually recreating a copy of the GPD (it's just 8K, anyway), you really can't fix the problem; you have to do strange things to CR3 and CR4 to fix it, since there is a chicken-and-egg problem once you are in protected mode. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Terry Lambert wrote: Martin Blapp wrote: If you don't beleave it or not. I've taken out again (I've already switched them once) one bank of 512M ram and since then I've not had any panics anymore. Can a ram error occur after a system has been fine one month ? No. Let me hedge: No, not unless something else has happened to it.; generally, after burn-in, electronics have an incredibly long MTBF. The 512M in/out vs. the problem is symptomatic, IMO. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- 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 /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 17 15:06:35 PDT 2002 -- Kernel build for GENERIC completed on Tue Sep 17 15:31:39 PDT 2002 -- Kernel build for LINT started on Tue Sep 17 15:31:39 PDT 2002 -- === vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /h/des/src/sys/dev/dgb/dgb.c:89: /h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /h/des/src/sys/dev/dgb/dgb.c:92:2: #error The dgb device requires the old isa compatibility shims /h/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /h/des/src/sys/dev/ncv/ncr53c500.c:86: /h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /h/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /h/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /h/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /h/des/src/sys/dev/wl/if_wl.c:218: /h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /h/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /h/des/src/sys/dev/wl/if_wl.c:227:2: #error The wl device requires the old isa compatibility shims /h/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /h/des/src/sys/kern/subr_prof.c:232:2: #error /h/des/src/sys/kern/subr_prof.c:243:2: #error /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:57:2: #error The simos device requires the old pci compatibility shims /h/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Threads issue after latest buildworld
Joe Marcus Clarke wrote: I just cvsup'd -CURRENT two hours ago, built world and kernel, then rebooted...same as always. Now, nautilus-2.0.7 fails to start with a thread abort... I saw the same error starting last night. Mozilla also. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
Terry Lambert wrote: Martin Blapp wrote: Can a ram error occur after a system has been fine one month ? No. This is the TLB problem we all keep talking about... I just got the most recent IA-32 manuals from Intel in the mail, and they still don't seem to be aware of the issue... Is this an Intel-specific problem, then? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Intel Mobile fxp Cardbus cards supported?
Greetings, Is the Intel Mobile Cardbus cards which are based on the Intel 82550 chips supported under FreeBSD -current using the fxp driver? Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cannot install FreeBSD-current 9/10 and 9/17 from floppies
Hi, I bought a second machine to install FreeBSD-current, so that I can learn how to do kernel debugging via a serial cable. I cannot install FreeBSD-current on this machine. The machine is an IBM PIII-450 Here is what I did: (1) Obtained kern.flp and mfsroot.flp floppy images from the 9/17 and 9/10 snapshots of FreeBSD-current. I obtained these from ftp://current.freebsd.org/ (2) After booting from the first floppy (kern.flp), I insert mfsroot.flp. The install hangs at: === Mounting root from ufs:/dev/md0c md0c: raw partition size != slice size md0c: start 0, end 5087, size 5088 md0c: truncating raw partition md0c: rejecting partition in BSD label: it isn't entirely within the slice md0c: start 0, end 5087, size 5088 md0ca: start 0, end 8639, size 8640 spec_getpages: (md0c) I/O read failure: (error=22) bp 0x2031dc vp 0xc0e39000 size: 4096 resid: 4096, a_count: 4096 valid: 0x0 nread: 0, reqpage: 0, pindex: 575, pcount: 1 === Any ideas what the cause of this is? I tried disabling things like PNP in the BIOS, but that didn't fix anything. I had the same problems with the 9/17 and 9/10 floppy images. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
page fault while in kernel mode, cam related ?
hi while trying to upgrade a -current box with an older scsi hd a scsi error seemed to have triggered a panic (actually the first ever on that box): (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 4b 94 df 0 0 20 0 (da0:ahc0:0:0:0): CAM Status: SCSI Status Error (da0:ahc0:0:0:0): SCSI Status: Check Condition (da0:ahc0:0:0:0): RECOVERED ERROR info:4b94f5 csi:b,b9,2,a2 asc:18,2 (da0:ahc0:0:0:0): Recovered data - data auto-reallocated field replaceable unit1 (da0:ahc0:0:0:0): No Recovery Action Needed Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3e fault code = supervisor write, page not present instruction pointer = 0x8:0xc02d3241 stack pointer = 0x10:0xcfd2d954 frame pointer = 0x10:0xcfd2d96c 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 = 15268 (cpp0) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x21: addw%si,0x3e(%ebx) db Context switches not allowed in the debugger. db tr vm_object_pip_add(0,1,0,0,c1f1e000) at vm_object_pip_add+0x21 vm_fault(c0832000,c88c2000,2,0,c21b2b40) at vm_fault+0x212 trap_pfault(cfd2dab8,0,c88c2001) at trap_pfault+0x131 trap(18,10,10,c88c2001,c5c0add8) at trap+0x3ab calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc03025cf, esp = 0xcfd2daf8, ebp = 0xcfd2db44 --- generic_bzero(cfd2dba0,cfd2dbcc,c02be266,cfd2dba0,4) at generic_bzero+0xf spec_vnoperate(cfd2dba0) at spec_vnoperate+0x13 ffs_getpages(cfd2dbd8) at ffs_getpages+0x406 vnode_pager_getpages(c1fac708,cfd2dc8c,10,0) at vnode_pager_getpages+0x62 vm_fault(c27883fc,28304000,1,0,c21b2b40) at vm_fault+0x6d6 trap_pfault(cfd2dd48,1,28304000,28304000,0) at trap_pfault+0xed trap(2f,2f,2f,839e000,83a5008) at trap+0x22b calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x806e373, esp = 0xbfbfeff0, ebp = 0xbfbff008 --- i don't know if fbsd is supposed to panic in case of such an error but i think to remember similar cam/scsi errors under 4-stable that didn't trigger a panic. btw, this box is connected via a serial console at 9600 bps and while typing at the ddb-prompt it swallowed most characters, i.e. i had to type single characters up to four times. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
On Wed, Sep 18, 2002 at 02:53:49 +0200, [EMAIL PROTECTED] wrote: hi while trying to upgrade a -current box with an older scsi hd a scsi error seemed to have triggered a panic (actually the first ever on that box): (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 4b 94 df 0 0 20 0 (da0:ahc0:0:0:0): CAM Status: SCSI Status Error (da0:ahc0:0:0:0): SCSI Status: Check Condition (da0:ahc0:0:0:0): RECOVERED ERROR info:4b94f5 csi:b,b9,2,a2 asc:18,2 (da0:ahc0:0:0:0): Recovered data - data auto-reallocated field replaceable unit1 (da0:ahc0:0:0:0): No Recovery Action Needed That's just an informative message, you had a bad block that was reallocated. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3e fault code = supervisor write, page not present instruction pointer = 0x8:0xc02d3241 stack pointer = 0x10:0xcfd2d954 frame pointer = 0x10:0xcfd2d96c 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 = 15268 (cpp0) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x21: addw%si,0x3e(%ebx) db Context switches not allowed in the debugger. db tr vm_object_pip_add(0,1,0,0,c1f1e000) at vm_object_pip_add+0x21 vm_fault(c0832000,c88c2000,2,0,c21b2b40) at vm_fault+0x212 trap_pfault(cfd2dab8,0,c88c2001) at trap_pfault+0x131 trap(18,10,10,c88c2001,c5c0add8) at trap+0x3ab calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc03025cf, esp = 0xcfd2daf8, ebp = 0xcfd2db44 --- generic_bzero(cfd2dba0,cfd2dbcc,c02be266,cfd2dba0,4) at generic_bzero+0xf spec_vnoperate(cfd2dba0) at spec_vnoperate+0x13 ffs_getpages(cfd2dbd8) at ffs_getpages+0x406 vnode_pager_getpages(c1fac708,cfd2dc8c,10,0) at vnode_pager_getpages+0x62 vm_fault(c27883fc,28304000,1,0,c21b2b40) at vm_fault+0x6d6 trap_pfault(cfd2dd48,1,28304000,28304000,0) at trap_pfault+0xed trap(2f,2f,2f,839e000,83a5008) at trap+0x22b calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x806e373, esp = 0xbfbfeff0, ebp = 0xbfbff008 --- i don't know if fbsd is supposed to panic in case of such an error but i think to remember similar cam/scsi errors under 4-stable that didn't trigger a panic. btw, this box is connected via a serial console at 9600 bps and while typing at the ddb-prompt it swallowed most characters, i.e. i had to type single characters up to four times. It doesn't look like the message above and the panic are related. The panic is in the VM code, I don't see any CAM functions in there. So my guess is that it's just a coincidence. You might try sending mail to the -current list and see if anyone has seen this sort of panic lately. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
On Tue, Sep 17, 2002 at 19:03:22 -0600, Kenneth D. Merry wrote: On Wed, Sep 18, 2002 at 02:53:49 +0200, [EMAIL PROTECTED] wrote: hi while trying to upgrade a -current box with an older scsi hd a scsi error seemed to have triggered a panic (actually the first ever on that box): (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 4b 94 df 0 0 20 0 (da0:ahc0:0:0:0): CAM Status: SCSI Status Error (da0:ahc0:0:0:0): SCSI Status: Check Condition (da0:ahc0:0:0:0): RECOVERED ERROR info:4b94f5 csi:b,b9,2,a2 asc:18,2 (da0:ahc0:0:0:0): Recovered data - data auto-reallocated field replaceable unit1 (da0:ahc0:0:0:0): No Recovery Action Needed That's just an informative message, you had a bad block that was reallocated. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3e fault code = supervisor write, page not present instruction pointer = 0x8:0xc02d3241 stack pointer = 0x10:0xcfd2d954 frame pointer = 0x10:0xcfd2d96c 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 = 15268 (cpp0) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x21: addw%si,0x3e(%ebx) db Context switches not allowed in the debugger. db tr vm_object_pip_add(0,1,0,0,c1f1e000) at vm_object_pip_add+0x21 vm_fault(c0832000,c88c2000,2,0,c21b2b40) at vm_fault+0x212 trap_pfault(cfd2dab8,0,c88c2001) at trap_pfault+0x131 trap(18,10,10,c88c2001,c5c0add8) at trap+0x3ab calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc03025cf, esp = 0xcfd2daf8, ebp = 0xcfd2db44 --- generic_bzero(cfd2dba0,cfd2dbcc,c02be266,cfd2dba0,4) at generic_bzero+0xf spec_vnoperate(cfd2dba0) at spec_vnoperate+0x13 ffs_getpages(cfd2dbd8) at ffs_getpages+0x406 vnode_pager_getpages(c1fac708,cfd2dc8c,10,0) at vnode_pager_getpages+0x62 vm_fault(c27883fc,28304000,1,0,c21b2b40) at vm_fault+0x6d6 trap_pfault(cfd2dd48,1,28304000,28304000,0) at trap_pfault+0xed trap(2f,2f,2f,839e000,83a5008) at trap+0x22b calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x806e373, esp = 0xbfbfeff0, ebp = 0xbfbff008 --- i don't know if fbsd is supposed to panic in case of such an error but i think to remember similar cam/scsi errors under 4-stable that didn't trigger a panic. btw, this box is connected via a serial console at 9600 bps and while typing at the ddb-prompt it swallowed most characters, i.e. i had to type single characters up to four times. It doesn't look like the message above and the panic are related. The panic is in the VM code, I don't see any CAM functions in there. So my guess is that it's just a coincidence. You might try sending mail to the -current list and see if anyone has seen this sort of panic lately. Oops, I missed that this was CCed to the current list, so never mind that. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
walt wrote: This is the TLB problem we all keep talking about... I just got the most recent IA-32 manuals from Intel in the mail, and they still don't seem to be aware of the issue... Is this an Intel-specific problem, then? No. AMD has it too. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download ... please help
On Tue, 17 Sep 2002, Martin Blapp wrote: If you don't beleave it or not. I've taken out again (I've already switched them once) one bank of 512M ram and since then I've not had any panics anymore. Can a ram error occur after a system has been fine one month ? Chances are, if you change an important variable such as memory size, it will change the failure mode for this bug. Carefully marking the memory so you know which is which, find replacement memory of identical size and other characteristics, and see if the failure comes back. If the failure comes back with different memory, the chances of it being a problem with the memory are pretty low. However, if you're going to halve the available memory, you're going to substantially change the behavior of the system for large and parallel builds, because the swapping/paging behavior will probably be quite different, especially if your working set is larger than 512mb and smaller than 1gb. I.e., be careful that tweaks changing the behavior of your system aren't just masking the real bug. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
On Tue, Sep 17, 2002 at 07:03:22PM -0600, Kenneth D. Merry wrote: On Wed, Sep 18, 2002 at 02:53:49 +0200, [EMAIL PROTECTED] wrote: hi while trying to upgrade a -current box with an older scsi hd a scsi error seemed to have triggered a panic (actually the first ever on that box): (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 4b 94 df 0 0 20 0 (da0:ahc0:0:0:0): CAM Status: SCSI Status Error (da0:ahc0:0:0:0): SCSI Status: Check Condition (da0:ahc0:0:0:0): RECOVERED ERROR info:4b94f5 csi:b,b9,2,a2 asc:18,2 (da0:ahc0:0:0:0): Recovered data - data auto-reallocated field replaceable unit1 (da0:ahc0:0:0:0): No Recovery Action Needed That's just an informative message, you had a bad block that was reallocated. i know, just thought this could be somehow related, e.g. something in the vm-systems times out while the reallocation is taking place...whatever... but of course can be coincidence. maybe the cam related in the subject is unfortunate, i didn't mean a bug in cam but after/while the cam handled the error condition. thanks for having a look at it! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
On Tue, Sep 17, 2002 at 11:39:50AM +0200, Robert Suetterlin wrote: Hello! I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory I need more context. Please email a complete build log. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
uhm, i just got another one. i guess the hd is broken and also managed to cause the previous panic. (da0:ahc0:0:0:0): SCB 0x27 - timed out ahc_pci0: Dumping Card State while idle, at SEQADDR 0x8 ACCUM = 0x47, SINDEX = 0x9e, DINDEX = 0x8c, ARG_2 = 0x0 HCNT = 0x0 SCBPTR = 0xb SCSISEQ = 0x12, SBLKCTL = 0x2 DFCNTRL = 0x0, DFSTATUS = 0x29 LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 SSTAT0 = 0x5, SSTAT1 = 0xa STACK == 0x3, 0x105, 0x160, 0x0 SCB count = 200 Kernel NEXTQSCB = 129 Card NEXTQSCB = 129 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 11 2 0 6 15 3 9 1 14 10 8 12 5 4 7 13 Sequencer SCB Info: 0(c 0x68, s 0x7, l 0, t 0xff) 1(c 0x68, s 0x7, l 0, t 0xff) Pending list: 140(c 0x68, s 0x7, l 0), 158(c 0x6c, s 0x7, l 0), 152(c 0x6c, s 0)Kernel Free SCB list: 165 61 101 184 98 88 178 123 176 26 83 62 197 170 8 112 4 sg[0] - Addr 0x52fe000 : Length 4096 sg[1] - Addr 0x71bf000 : Length 4096 sg[2] - Addr 0x602 : Length 4096 sg[3] - Addr 0xb441000 : Length 4096 sg[4] - Addr 0x30e2000 : Length 4096 sg[5] - Addr 0xa703000 : Length 4096 sg[6] - Addr 0x91a4000 : Length 4096 sg[7] - Addr 0x1f05000 : Length 4096 sg[8] - Addr 0x3f46000 : Length 4096 sg[9] - Addr 0x5787000 : Length 4096 sg[10] - Addr 0x80a8000 : Length 4096 sg[11] - Addr 0x1389000 : Length 4096 sg[12] - Addr 0xa9ca000 : Length 4096 sg[13] - Addr 0x6d8b000 : Length 4096 sg[14] - Addr 0x680c000 : Length 4096 sg[15] - Addr 0xa1cd000 : Length 4096 (da0:ahc0:0:0:0): Queuing a BDR SCB (da0:ahc0:0:0:0): Bus Device Reset Message Sent (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc_pci0: Bus Device Reset on A:0. 102 SCBs aborted (da0:ahc0:0:0:0): SCB 0x81 - timed out ahc_pci0: Dumping Card State while idle, at SEQADDR 0x7 ACCUM = 0xa0, SINDEX = 0x9f, DINDEX = 0x8c, ARG_2 = 0x0 HCNT = 0x0 SCBPTR = 0x7 SCSISEQ = 0x12, SBLKCTL = 0x2 DFCNTRL = 0x0, DFSTATUS = 0x29 LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 SSTAT0 = 0x5, SSTAT1 = 0xa STACK == 0x3, 0x105, 0x160, 0xe4 SCB count = 41 Kernel NEXTQSCB = 165 Card NEXTQSCB = 165 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 7 14 12 8 5 10 9 1 4 3 15 6 0 2 11 13 Sequencer SCB Info: 0(c 0x68, s 0x7, l 0, t 0xff) 1(c 0x68, s 0x7, l 0, t 0xff) Pending list: 159(c 0x6c, s 0x7, l 0), 40(c 0x6c, s 0x7, l 0), 43(c 0x6c, s 0x7) Kernel Free SCB list: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34737269
Re: Cannot install FreeBSD-current 9/10 and 9/17 from floppies
Hi, Just to follow up, I tried a few other floppy images, and succeeded with the floppy images that are part of the 8/31 -CURRENT snapshot. I can't figure out what the problem was with the newer floppy images. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] On Tue, Sep 17, 2002 at 08:53:39PM -0400, Craig Rodrigues wrote: Hi, I bought a second machine to install FreeBSD-current, so that I can learn how to do kernel debugging via a serial cable. I cannot install FreeBSD-current on this machine. The machine is an IBM PIII-450 Here is what I did: (1) Obtained kern.flp and mfsroot.flp floppy images from the 9/17 and 9/10 snapshots of FreeBSD-current. I obtained these from ftp://current.freebsd.org/ (2) After booting from the first floppy (kern.flp), I insert mfsroot.flp. The install hangs at: === Mounting root from ufs:/dev/md0c md0c: raw partition size != slice size md0c: start 0, end 5087, size 5088 md0c: truncating raw partition md0c: rejecting partition in BSD label: it isn't entirely within the slice md0c: start 0, end 5087, size 5088 md0ca: start 0, end 8639, size 8640 spec_getpages: (md0c) I/O read failure: (error=22) bp 0x2031dc vp 0xc0e39000 size: 4096 resid: 4096, a_count: 4096 valid: 0x0 nread: 0, reqpage: 0, pindex: 575, pcount: 1 === Any ideas what the cause of this is? I tried disabling things like PNP in the BIOS, but that didn't fix anything. I had the same problems with the 9/17 and 9/10 floppy images. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] 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: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
Stefan Farfeleder [EMAIL PROTECTED] writes: [CC'ing David O'Brien as he did the update to 3.39] On Tue, Sep 17, 2002 at 09:38:10AM -0700, Lars Eggert wrote: Robert Suetterlin wrote: I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory FYI I'm seeing the exact same error trying to build -CURRENT under 4.6-RELEASE (just cvs updated). Add me to the list. Culprit is src/usr.bin/file/config.h which unconditionally defines HAVE_STDINT_H though RELENG_4 is missing it. This is being looked into. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add
On Sun, Sep 15, 2002 at 07:56:09PM -0700, David O'Brien wrote: On Sun, Sep 15, 2002 at 09:47:28PM +, justin wrote: SORRY IF THIS IS A REPEAT! I have recompiled my base the past 2 days now, and pkg_add will segfault signal 10 and core dumps after the second file transfer I can still use it to install the package, but i have to run the command multiple times depending on how many dependancies the port has. If it is only 1 file, it works fine and without problems. What is the exact outout with `pkg_add -v'. Can you compile pkg_add with -g debugging and provide a trace? I can reproduce the problem with pkg_add by doing: pkg_add -v -r cvsupit on a clean system. This happens with the latest sources in /usr/src/usr.sbin/pkg_install/ -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] Script started on Wed Sep 18 00:12:02 2002 rincewind# gdb pkg_add GNU gdb 5.2.0 (FreeBSD) 20020627 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... (gdb) r -v -r cvsupit Starting program: /usr/src/usr.sbin/pkg_install/add/pkg_add -v -r cvsupit looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 setting passive mode opening data connection initiating transfer Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz...+CONTENTS +COMMENT +DESC +INSTALL +REQUIRE +MTREE_DIRS tar command returns 0 status Done. Package 'cvsupit-3.1' depends on 'perl-5.6.1_8'. setting passive mode opening data connection initiating transfer Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/All/perl-5.6.1_8.tbz...+CONTENTS +COMMENT +DESC +INSTALL +DISPLAY +MTREE_DIRS Attempting to record package into /var/db/pkg/perl-5.6.1_8.. Package perl-5.6.1_8 registered in /var/db/pkg/perl-5.6.1_8 Installation of Perl distribution is finished. Please note, that since Perl is also in the base system, this distribution will not be used by default. If you want this version of Perl to be used by default, please type use.perl port Assuming that use.perl script (which was installed with the rest of the Perl distribution) can be found in your PATH (you might have to type `rehash' first, depending upon a shell you use), this action will replace /usr/bin/perl and /usr/bin/suidperl with symbolic links to the versions of these binaries in the Perl distribution. This action will also put some variables into your /etc/make.conf file, so that newly installed ports (not packages!) will use new version of perl, and the system upgrades from the source will not overwrite the changes made. At any time you can also type use.perl system if you wish to revert back to the system version of perl. 'perl-5.6.1_8' loaded successfully. Package 'cvsupit-3.1' depends on 'imake-4.2.0_1'. Program received signal SIGBUS, Bus error. 0x280a0792 in SSL_write () from /usr/lib/libssl.so.2 (gdb) where #0 0x280a0792 in SSL_write () from /usr/lib/libssl.so.2 #1 0x28078129 in _fetch_write () from /usr/lib/libfetch.so.3 #2 0x280781de in _fetch_putln () from /usr/lib/libfetch.so.3 #3 0x28075d61 in fetchListHTTP () from /usr/lib/libfetch.so.3 #4 0x280771c4 in fetchListHTTP () from /usr/lib/libfetch.so.3 #5 0x2807743d in _ftp_request () from /usr/lib/libfetch.so.3 #6 0x28077591 in fetchXGetFTP () from /usr/lib/libfetch.so.3 #7 0x280783b0 in fetchXGet () from /usr/lib/libfetch.so.3 #8 0x280786e5 in fetchXGetURL () from /usr/lib/libfetch.so.3 #9 0x2807871f in fetchGetURL () from /usr/lib/libfetch.so.3 #10 0x0804f5ef in fileGetURL ( base=0x8056860 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz;, spec=0x808d070 imake-4.2.0_1) at file.c:199 #11 0x0804aa97 in pkg_do ( pkg=0x8056860 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz;) at perform.c:297 #12 0x0804a24b in pkg_perform (pkgs=0x8088c60) at perform.c:50 #13 0x08049faf in real_main (argc=-1077936975, argv=0xbfbffb9c) at main.c:215 #14 0x0804c96e in main (argc=673297920, argv=0xbfbffb8c) at pkgwrap.c:88 #15 0x08049b29 in _start () (gdb) quit The program is running. Exit anyway? (y or n) y rincewind# ^Dexit Script done on Wed Sep 18 00:13:37 2002
