Re: PPP modem dial is completely broken
On Tue, Jun 12, 2001 at 10:45:58 +0930, Daniel O'Connor wrote: On 11-Jun-2001 Andrey A. Chernov wrote: With new PPP I can't dial to my provider anymore. Two variants: 1) PPP says Clearing choked output queue and connection stuck forever with carrier on. Nothing else happens. 2) PPP says Too many IPCP NAKs sent - abandoning negotiation and drop carrier forever without further redialing. About months old PPP works fine with the same config. Is it a 'normal' modem, or a USB one? Normal one external modem. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
On Tue, Jun 12, 2001 at 15:25:27 +1000, Bruce Evans wrote: On Tue, 12 Jun 2001, Andrey A. Chernov wrote: I just found that msdosfs can't mount legal Extended partition because required info is few blocks later in that case, not immediately as for Primary partition. Is it known problem, or I am first who notice that? Does anybody have some fix for that? Extended partititons aren't mountable (even under DOS/Windows), since they are just containers for logical drives (and further extended partitions). Just mount the logical drive (slice) that you want. Where is such slice then? I have ad0s1 for FreeBSD, ad0s2 for Primary and ad0s3 for Extended container of logical drive. Real fat32 code started in ad0s3 a bit later, but I don't have a device name to mount it (or I miss something). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
Hello Ache, On Tue, Jun 12, 2001 at 12:08:22PM +0400, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 15:25:27 +1000, Bruce Evans wrote: On Tue, 12 Jun 2001, Andrey A. Chernov wrote: I just found that msdosfs can't mount legal Extended partition because required info is few blocks later in that case, not immediately as for Primary partition. Is it known problem, or I am first who notice that? Does anybody have some fix for that? Extended partititons aren't mountable (even under DOS/Windows), since they are just containers for logical drives (and further extended partitions). Just mount the logical drive (slice) that you want. Where is such slice then? I have ad0s1 for FreeBSD, ad0s2 for Primary and ad0s3 for Extended container of logical drive. Real fat32 code started in ad0s3 a bit later, but I don't have a device name to mount it (or I miss something). Well, hm this is even in the FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#MOUNT-DOS (Question 7.8: How do I mount a secondary DOS partition?) In your situation I would try ad0s5 and onwards. If you do not have the device node under /dev, so create it:-) (No worries I have also forgotten how to do such mounts on occasion before:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
On Tue, Jun 12, 2001 at 01:01:02PM +0400, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 10:47:43 +0200, Szilveszter Adam wrote: In your situation I would try ad0s5 and onwards. If you do not have the device node under /dev, so create it:-) (No worries I have also forgotten how to do such mounts on occasion before:-) Thanks, it works. I was confused by 'devfs' this time which not show ad0s5 slice under /dev until it is actualy mounted. Yes, devfs really takes some getting used to in the beginning, at least it has for me:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's happened to the generation of CTM?
Peter Jeremy wrote: On 2001-Jun-11 21:46:55 -0500, Steve Hocking [EMAIL PROTECTED] w rote: I see that cvs-cur stuff hasn't been generated since the beginning of May - cvs-cur _is_ being generated[1], it just not being mirrored on ftp.freebsd.org at present. When I asked Jordan about it after his ftp.freebsd.org is back announcement, he indicated that CTM is one of the still-outstanding problems. [1] Well, it died last weekend, but hopefully that will be restored shortly. Well, the person to talk to about that right now is me since I've got the care/feeding hat for ftp-master on at the moment. 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
handle_written_filepage: active pagedep
I updated my notebook today and I got some messages on my console. handle_written_filepage: active pagedep handle_written_filepage: active pagedep handle_written_filepage: active pagedep ... Can I ignore these messages? Or something wrong in sys/ufs/ffs/ffs_softdep.c? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: handle_written_filepage: active pagedep
On Tue, Jun 12, 2001 at 19:07:44 +0900, Jun Kuriyama wrote: I updated my notebook today and I got some messages on my console. handle_written_filepage: active pagedep handle_written_filepage: active pagedep handle_written_filepage: active pagedep ... I can confirm that I saw them too with recent kernel -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: handle_written_filepage: active pagedep
I got panic with recently updated box. Brief trackback is here: panic() deallocate_dependencies() softdep_setup_freeblocks() ffs_truncate() handle_workitem_remove() softdep_setup_remove() ufs_dirremove() ufs_rmdir() ufs_vnoperate() rmdir() syscall() syscall_with_err_pushed() -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
Warner == Warner Losh [EMAIL PROTECTED] writes: Warner In summary: Warner o Use the same config file you used before. Warner o Update pccardd Warner o Add -I -i 9 to pccardd_flags (if your pcic's irq is 9). Warner o rebuild and reinstall the kernel. Warner o reboot. Send your panics to me. :-) I just did that. I got a panic, which I could not save (I cannot panic From ddb, it just doesn't work). ddb reports the faulty process as being ddb, and it relates to trap 12 being called ... (I don't remember the exact message unfortunately, I should find a null cable and use gdb). Here is my latest dmesg in case you see something wrong. The pcic irq is 9 here, right? Sam -- Samuel Tardieu -- [EMAIL PROTECTED] 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 #8: Tue Jun 12 11:40:44 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TRILLIAN Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (645.20-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134152192 (131008K bytes) avail memory = 126197760 (123240K bytes) Preloaded elf kernel kernel at 0xc0437000. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf50 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcb0-0xfcbf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfc60-0xfc7f at device 7.2 on pci0 pci_cfgintr_unique: hard-routed to irq 9 pci_cfgintr: 0:7 INTD routed to irq 9 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB Mouse, rev 1.10/4.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. pci0: bridge, PCI-unknown at 7.3 (no driver attached) pci0: serial bus, FireWire at 8.0 (no driver attached) pcm0: Yamaha DS-1E (YMF744) mem 0xfecf-0xfecf7fff irq 9 at device 9.0 on pci0 pci0: simple comms at 10.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfcc0-0xfcff mem 0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 fxp0: Ethernet address 08:00:46:0c:b4:c7 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci_cfgintr_unique: hard-routed to irq 9 pci_cfgintr: 0:12 INTA routed to irq 9 pcic0: Ricoh RL5C475 PCI-CardBus Bridge irq 9 at device 12.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pccard0: PC Card bus (classic) on pcic0 pci0: memory, flash at 13.0 (no driver attached) orm0: Option ROMs at iomem 0xc-0xcbfff,0xdc000-0xd on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A spic0: Sony Programmable I/O Controller at port 0x10a0-0x10a4 on isa0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources atspeaker0: AT speaker at port 0x61 on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources IPsec: Initialized Security Association Processing. ad0: 11513MB IBM-DARA-212000 [23392/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s2a PGP signature
Patch to restore WARNS feature
Hi!
The attached patch enables us to restore the -Werror bit of
the WARNS feature by fixing relevant headers and adding one
new header, complex.h, aligned with the POSIX.1-200x draft.
I did not fix the CSRG's libm (-DWANT_CSRG_LIBM) because it
does not compile with the current sources for the reason of
missing library functions.
Also, the -traditional-cpp bit in games/adventure/Makefile
correlares badly with -nostdinc and WARNS=2.
Please review (tested).
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.203
diff -u -p -r1.203 Makefile.inc1
--- Makefile.inc1 2001/06/11 18:09:08 1.203
+++ Makefile.inc1 2001/06/12 12:39:19
@@ -200,7 +200,7 @@ WMAKEENV= ${CROSSENV} \
DESTDIR=${WORLDTMP} \
INSTALL=sh ${.CURDIR}/tools/install.sh \
PATH=${TMPPATH}
-WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1 -DNO_WERROR
+WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
# install stage
IMAKEENV= ${CROSSENV} \
Index: games/adventure/Makefile
===
RCS file: /home/ncvs/src/games/adventure/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- games/adventure/Makefile2001/05/20 05:37:46 1.10
+++ games/adventure/Makefile2001/06/12 12:39:19
@@ -4,7 +4,6 @@
PROG= adventure
SRCS= main.c init.c done.c save.c subr.c vocab.c wizard.c io.c data.c crc.c
MAN= adventure.6
-CFLAGS+=-traditional-cpp
HIDEGAME=hidegame
CLEANFILES=data.c setup setup.o
Index: include/Makefile
===
RCS file: /home/ncvs/src/include/Makefile,v
retrieving revision 1.146
diff -u -p -r1.146 Makefile
--- include/Makefile2001/06/07 05:04:53 1.146
+++ include/Makefile2001/06/12 12:39:19
@@ -8,7 +8,8 @@
CLEANFILES= osreldate.h version vers.c
SUBDIR= rpcsvc rpc
-FILES= a.out.h ar.h assert.h bitstring.h ctype.h db.h dirent.h disktab.h \
+FILES= a.out.h ar.h assert.h bitstring.h complex.h ctype.h db.h \
+ dirent.h disktab.h \
dlfcn.h elf.h elf-hints.h err.h fnmatch.h fstab.h \
fts.h glob.h grp.h strhash.h \
hesiod.h histedit.h ieeefp.h ifaddrs.h iso646.h langinfo.h \
Index: include/complex.h
===
RCS file: complex.h
diff -N complex.h
--- /dev/null Tue Jun 12 03:18:33 2001
+++ complex.h Tue Jun 12 15:39:19 2001
@@ -0,0 +1,60 @@
+/*-
+ * Copyright (c) 2001 The FreeBSD Project.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef _COMPLEX_H
+#define _COMPLEX_H
+
+#ifdef __GNUC__
+#define _Complex __complex__
+#define _Complex_I 1.0fi
+#endif
+
+#define complex_Complex
+#define I _Complex_I
+
+#include sys/cdefs.h
+
+__BEGIN_DECLS
+
+double cabs __P((double complex));
+float cabsf __P((float complex));
+double cimag __P((double complex));
+float cimagf __P((float complex));
+double creal __P((double complex));
+float crealf __P((float complex));
+
+__END_DECLS
+
+#ifdef __GNUC__
+#define cimag(z) (__imag__ (z))
+#define cimagf(z) (__imag__ (z))
+#define creal(z) (__real__ (z))
+#define crealf(z) (__real__ (z))
+#endif
+
+#endif /* _COMPLEX_H */
Index: include/fts.h
Re: PPP modem dial is completely broken
With new PPP I can't dial to my provider anymore. Two variants: 1) PPP says Clearing choked output queue and connection stuck forever with carrier on. Nothing else happens. 2) PPP says Too many IPCP NAKs sent - abandoning negotiation and drop carrier forever without further redialing. About months old PPP works fine with the same config. Can you send me a copy of the LCP IPCP logs (``set log lcp ipcp phase'') ? Cheers. -- Andrey A. Chernov http://ache.pp.ru/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
Sam == Samuel Tardieu [EMAIL PROTECTED] writes: Sam I just did that. I got a panic, which I could not save (I cannot Sam panic From ddb, it just doesn't work). ddb reports the faulty Sam process as being ddb, and it relates to trap 12 being called Sam ... (I don't remember the exact message unfortunately, I should Sam find a null cable and use gdb). Some more info: I just borrowed an Aironet card, and it works just fine by adding -I -i 9. It seems to be only my Psion Dacom Gold Card that has a problem. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] PGP signature
Re: Unrecognised CBCP packet [strange problems with ppp(8)]
From: [EMAIL PROTECTED] (Brian Somers) Date: Fri 8 Jun, 2001 Subject: Re: Unrecognised CBCP packet [strange problems with ppp(8)] To be honest, I have no idea what's going on here. It doesn't even look as if you sent any data. I think you may have to ask your ISP why they're closing the connection :/ I just recently switched to user mode ppp and I get these, apparently when my ISP closes the connection as expected after an idle time. Don't know if this is relevant to the situation being discussed, though... Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM causes segfault in login(1)
Hi, I've noticed that new PAM segfaults when I'm typing non-existing login at console login prompt. Please fix. -Maxim FreeBSD/i386 (big_brother) (ttyv0) login: max1 pid 372 (login), uid 0: exited on signal 11 (core dumped) FreeBSD/i386 (big_brother) (ttyv0) login: max Password: Welcome to FreeBSD! Erase is backspace. bash-2.05$ gdb /usr/bin/login /tmp/core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... Core was generated by `login'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)... done. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)... done. Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done. Reading symbols from /usr/lib/pam_nologin.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/pam_unix.so...done. Reading symbols from /usr/lib/pam_permit.so...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x28074e33 in crypt_md5 () from /usr/lib/libcrypt.so.2 (gdb) bt #0 0x28074e33 in crypt_md5 () from /usr/lib/libcrypt.so.2 #1 0x28074c94 in crypt () from /usr/lib/libcrypt.so.2 #2 0x28132aee in pam_sm_authenticate (pamh=0x8055000, flags=0, argc=1, argv=0x804f100) at pam_unix.c:95 #3 0x2807bae5 in pam_getenvlist () from /usr/lib/libpam.so.1 #4 0x2807bdf1 in _pam_dispatch () from /usr/lib/libpam.so.1 #5 0x2807b18b in pam_authenticate () from /usr/lib/libpam.so.1 #6 0x804ae41 in free () #7 0x8049fea in free () #8 0x8049b61 in free () (gdb) up #1 0x28074c94 in crypt () from /usr/lib/libcrypt.so.2 (gdb) up #2 0x28132aee in pam_sm_authenticate (pamh=0x8055000, flags=0, argc=1, argv=0x804f100) at pam_unix.c:95 95 crypt(password, xx); (gdb) print password $1 = 0x1 Address 0x1 out of bounds (gdb) q bash-2.05$
RE: Couple Giant not locked at vm_object.c:261 panics I had to
On 09-Jun-01 Richard Todd wrote:
Backtraces posted here in hopes they might enlighten someone.
This is with kernel source from June 6 (specifically,
Sticky Date: 2001.06.06.22.16.24 according to cvs status). The machine
is a dual PII/400; dmesg follows the backtraces from the two panics. If you
want more information from these two core files, please let me know.
Note that the first panic is somewhat muddled by the fact that, while
syncing disks from the vm_object.c panic, it apparently paniced again with
Giant locked at i386/trap.c:1153. That probably confuses the issue
greatly.
Yes, I need the first traceback, not the second. One question: are you using
ktrace? ddb is your friend here, as it can do a traceback when you have the
first panic.
P.S. Stupid -current question: How does one tell what process was running
that triggered a panic? This used to be findable with p *curproc in
gdb, but that doesn't seem to work anymore.
You have to look at the list of per-cpu data (look at the gd_allcpu list). In
ddb you can use 'show pcpu' to look at per-cpu data. At some point, gdb needs
to be taught the notion of a 'current CPU' and be taught a way to access
per-cpu data of the current CPU.
21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:478
478 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc026b35f in boot (howto=256) at ../../kern/kern_shutdown.c:321
#2 0xc026b7d1 in panic (fmt=0xc0484808 mutex %s not owned at %s:%d)
at ../../kern/kern_shutdown.c:600
#3 0xc0263c25 in _mtx_assert (m=0xc0576ca0, what=1,
file=0xc04ab834 ../../vm/vm_object.c, line=261)
at ../../kern/kern_mutex.c:567
#4 0xc03f0fee in vm_object_reference (object=0xc8bbc1e0)
at ../../vm/vm_object.c:261
#5 0xc03d6872 in ffs_write (ap=0xc8ce0e80)
at ../../ufs/ufs/ufs_readwrite.c:421
#6 0xc025e175 in ktrwrite (vp=0xc8b67680, kth=0xc112df00, uio=0x0)
at vnode_if.h:303
#7 0xc025dadb in ktrpsig (vp=0xc8b67680, sig=6, action=0, mask=0xc8b24090,
code=0) at ../../kern/kern_ktrace.c:202
#8 0xc0270204 in postsig (sig=6) at ../../kern/kern_sig.c:1542
#9 0xc042983e in userret (p=0xc8b23ee0, frame=0xc8ce0fa8, oticks=2655)
at ../../i386/i386/trap.c:175
#10 0xc042c603 in ast (framep=0xc8ce0fa8) at ../../i386/i386/trap.c:1320
#11 0xc0417b00 in doreti_ast ()
Ok, this one is the ktrace bogon that was recently brought to my attention.
--
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
Can a program ignore all signals?
I'm trying to obtain a dump of a (working) cd disk on FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001 I also have a 4.3-STABLE machine but I cannot test on it because it has no cd... The machine is all ide/ata, one hd, one cd and a writer. ---[ short-dmesg ]--- atapci0: VIA 82C586 ATA33 controller port ... ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 [...] ad0: 6197MB IBM-DHEA-36480 [12592/16/63] at ata0-master UDMA33 acd0: CD-RW YAMAHA CRW4001 at ata1-master PIO3 acd1: CDROM ATAPI CD-ROM DRIVE 40X MAXIMUM at ata1-slave PIO4 ---[ /short-dmesg ]--- # isoinfo -i /dev/acd0c -l shows me a dir listing (w/out mounting it), also disk mount fine as iso_9660 (no extension, short names, only level-1, no RR nor Joliet) I tryed with (from my user and from root): # cp /dev/acd0c /tmp/mydump.iso Activity led on cd stay on, nothing happens :-( Killing process fail. Any signal fail. From same shell (tcsh) neither ^C, ^Z, ^\ or any other key combination works nor from another shell (either from same user and from root) with all signals showed by kill -l. Tryed more and more... Killing shell leave process running, with PPID=1 instead of PPID=(same pid of tcsh) Only shutdown stop it, but with message: some processes would not die; ps axl advised After reboot all partitions are clean, no need of fsck. Maybe cp is the wrong command to obtaining an iso image dump, but why it survive kill? Is normal? Pilot error? How can I make a copy of a self made (or even better of _ANY_ data cd) without archiving all iso images on hd? I noticed /dev/acd0t1 appears (I'm using DEVFS) under /dev after isoinfo. Can I (must ?) use that instead of acd0c? Yes, under another os (?) I am able to copy it :-( Ciao++ Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock recursion in uipc_mbuf.c
This is from today's current. Can you spot the problem from this or do you need a backtrace? recursed on non-recursive lock (sleep mutex) mbuf free list lock @ ../../kern/uipc_mbuf.c:573 -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa God made everything out of nothing, but the nothingness shows through. -- Paul Valery To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock recursion in uipc_mbuf.c
Although I'm ripping all this out and replacing it with new code within [hopefully] the next week, a backtrace would be nice nonetheless. On Tue, Jun 12, 2001 at 06:00:34PM -0500, Michael Harnois wrote: This is from today's current. Can you spot the problem from this or do you need a backtrace? recursed on non-recursive lock (sleep mutex) mbuf free list lock @ ../../kern/uipc_mbuf.c:573 -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa God made everything out of nothing, but the nothingness shows through. -- Paul Valery Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Couple Giant not locked at vm_object.c:261 panics I had to
In fbsd-current John Baldwin writes: On 09-Jun-01 Richard Todd wrote: Note that the first panic is somewhat muddled by the fact that, while syncing disks from the vm_object.c panic, it apparently paniced again with Giant locked at i386/trap.c:1153. That probably confuses the issue greatly. Yes, I need the first traceback, not the second. One question: are you using ktrace? ddb is your friend here, as it can do a traceback when you have the first panic. Yeah, I am using ktrace, and now that I think of it, yeah, a ktraced process was probably running when those panics occured. Unfortunately, ddb is not my friend, as I'm usually running X. :-( P.S. Stupid -current question: How does one tell what process was running that triggered a panic? This used to be findable with p *curproc in gdb, but that doesn't seem to work anymore. You have to look at the list of per-cpu data (look at the gd_allcpu list). In ddb you can use 'show pcpu' to look at per-cpu data. At some point, gdb needs to be taught the notion of a 'current CPU' and be taught a way to access per-cpu data of the current CPU. Ah. Okay. #10 0xc042c603 in ast (framep=0xc8ce0fa8) at ../../i386/i386/trap.c:1320 #11 0xc0417b00 in doreti_ast () Ok, this one is the ktrace bogon that was recently brought to my attention. Cool. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New SMP Mbuf Allocator (PATCH and TESTING request)
Hi -current -alpha, If you run -CURRENT on multiprocessor alpha, please please please read this! :-) The final version (or next to final, depending on how this final testing stage goes) of the new mbuf allocator which I have been working on for the past 1.5 months and which I've already mentionned on -arch is now ready. I plan to commit the new bits within the next week. However, as is usually the case with commits of this magnitude, I'd like a few more tests to be run by a few more people. I've been testing the allocator myself (in several different ways, mainly resource exhaustion simulations) for the past couple of weeks and have been able to catch and fix a couple of bugs. Also, jake, jlemon, and Silby (Mike Silbersack) have provided me with some reviews, all of which have been integrated into the latest version of the patch (below). The latest version of the mb_alloc code, applying to -CURRENT as of 5 minutes ago can be found here: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff People who have the following hardware are needed to help test the patch: 1- UP -CURRENT systems (Intel Alpha) 2- SMP -CURRENT systems (Intel) 3- SMP -CURRENT systems (Alpha) *** Especially important *** who are *not* using the if_vx.c driver [*] [*] The if_vx.c driver is broken for the Alpha, and is marked so by this patch. Before committing this, I plan to first fix the driver but, obviously, for now, if you are using if_vx, you won't be able to help with testing. :-( To test the patch: apply, build, reboot, do network-related things, check stats with `netstat -m', etc. For those looking at the code: Finally, a few things should be noted about the code itself (if you're just helping test, feel free to skip this part): - I disabled mbtypes[] related statistics _FOR NOW_. This is because if I were to presently enable them, I wouldn't be able to consistently update them (unless I do it atomic()ally, which is not so good for overall performance). I plan to re-enable them later on, but would prefer to wait and go over them (perhaps clean them up - add/remove types as needed - many are if 0'd anyway) rather than rush and waste time doing it now. - The patch is big. sys/mbuf.h includes need to also #include sys/malloc.h _BEFORE_ because sys/mbuf.h requires MALLOC_DECLARE() to be defined. - counters for m_ext objects are now all malloc()ed. This will likely eventually change for what concerns clusters (I am looking at storing the cluster counter in the cluster 2 region itself). For other object types, I plan to leave malloc() as the standard allocator for the counters, seeing as how the external objects are not allocated in a PCPU fashion anyway. That's it! This patch also sets up the way to more mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c code with uipc_mbuf2.c code, and ridding ourselves of the latter, etc.). It also moves a bundle of mbuf related things out of sys/conf/param.c and into subr_mbuf.c, where they will now belong. :-) Best Regards and PLEASE help test (especially if you have alpha hardware!!!), -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
Right, will do some testing, thanks.. can you give us a bit more than a week tho? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote: Right, will do some testing, thanks.. can you give us a bit more than a week tho? Your prompt reply is extremely encouraging. Thanks! :- The reason I said in the next week is actually because on Sat. June 23rd (not this upcoming one, but the one after), I should be flying off to Yugoslavia (actually to London, and only then to Yugoslavia). I will be gone for 3 weeks and seeing as how maintaining this huge diff is a real (especially given the state of -CURRENT, as I'm sure you know :-)), I would really like to commit it before then. Preferably not this next Thursday (this week) but the thursday next week, to give me a 1.5 day `buffer zone' in case of emergency (The Infamous Pointy-Hat Award). I've given it considerable testing on Intel hardware and don't really expect any problems on alpha, but better be safe than accidently break alpha and have some very peeved developers on my tail. :-) Cheers and thanks again, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
In message [EMAIL PROTECTED] Szilveszter Adam writes: : Thanks, it works. I was confused by 'devfs' this time which not show ad0s5 : slice under /dev until it is actualy mounted. : : Yes, devfs really takes some getting used to in the beginning, at least it : has for me:-) I'm not sure I like this whole magically appearing on first access device thing :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: handle_written_filepage: active pagedep
In message [EMAIL PROTECTED] Jun Kuriyama writes: : Can I ignore these messages? Or something wrong in : sys/ufs/ffs/ffs_softdep.c? SOFTUPDATES are not safe in current. Maybe I should write an UPDATING entry. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
In message [EMAIL PROTECTED] Samuel Tardieu writes: : I just did that. I got a panic, which I could not save (I cannot panic : From=20ddb, it just doesn't work). ddb reports the faulty process as : being ddb, and it relates to trap 12 being called ... (I don't : remember the exact message unfortunately, I should find a null cable : and use gdb). I'll need a stack traceback to track this down. Maybe you've told me before, but what kind of card are you using? : Here is my latest dmesg in case you see something wrong. The pcic irq : is 9 here, right? According to the dmesg you've sent, that is correct. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
In message [EMAIL PROTECTED] Samuel Tardieu writes: : fine by adding -I -i 9. It seems to be only my Psion Dacom Gold Card : that has a problem. OK. This is the second report of a modem failing (but mine worked, grump) so I'll look into this some more. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
On Wed, 13 Jun 2001, Bosko Milekic wrote: On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote: Right, will do some testing, thanks.. can you give us a bit more than a week tho? Your prompt reply is extremely encouraging. Thanks! :- The reason I said in the next week is actually because on Sat. June 23rd (not this upcoming one, but the one after), I should be flying off to Yugoslavia (actually to London, and only then to Yugoslavia). I will be gone for 3 weeks and seeing as how maintaining this huge diff is a real (especially given the state of -CURRENT, as I'm sure you know :-)), I would really like to commit it before then. Preferably not this next Thursday (this week) but the thursday next week, to give me a 1.5 day `buffer zone' in case of emergency (The Infamous Pointy-Hat Award). Okay- good- this gives me a bit of headroom to tackle this- there's about 10 days. I've given it considerable testing on Intel hardware and don't really expect any problems on alpha, but better be safe than accidently break alpha and have some very peeved developers on my tail. :-) Cheers and thanks again, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM causes segfault in login(1)
I've noticed that new PAM segfaults when I'm typing non-existing login at console login prompt. Please fix. This current, right? I'll sort it out. Thanks for the debug-sleuthing! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
