Pick
Hey Bro,
Check out this pick. It's GUARANTEED TO WIN.
FAVORITE LINE UNDERDOG
Raiders 4 Bucs
Take RAIDERS.
My source is NEVER wrong.
Get back to me when you win and have fun counting your money!!!
Take it easy.
Jeff
7441NCrV7-535ZsiU0041Pzcv0-388bKki7964GStQ7-99l43
2465lFyu0-136wohf4336xQgz7-245saYd1636Fl37èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: if_sis.c failed to attach my SiS630 ethernet controller withthe latest commit
I found the same problem in my FreeBSD box. Isn't anyone have further informations about this problem? *** my environment is following: - FIC PA-2013 motherboard (VIA MVP3 chipsets) - SiS900 NIC *** dmesg says: *** Jan 11 23:15:32 rulue kernel: sis0: port 0xe800-0xe8ff mem 0xea008000-0xea008fff irq 10 at device 9.0 on pci0 Jan 11 23:15:32 rulue kernel: sis0: Ethernet address: 00:40:26:ef:b0:c8 Jan 11 23:15:32 rulue kernel: sis0: MII without any PHY! Jan 11 23:15:32 rulue kernel: device_probe_and_attach: sis0 attach returned 6 *** "pciconf -vl" says: *** agp0@pci0:0:0: class=0x06 card=0x chip=0x05971106 rev=0x04 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C597/597AT/598MVP Apollo VP3/MVP3 System Controller' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x chip=0x85981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'VT82C598MVP/694x Apollo MVP3/Pro133x PCI to AGP Bridge' class= bridge subclass = PCI-PCI isab0@pci0:7:0: class=0x060100 card=0x chip=0x05861106 rev=0x47 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C586/A/B PCI to ISA Bridge' class= bridge subclass = PCI-ISA atapci0@pci0:7:1: class=0x01018a card=0x chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82 EIDE Controller (All VIA Chipsets)' class= mass storage subclass = ATA uhci0@pci0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x02 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class= serial bus subclass = USB pcib2@pci0:7:3: class=0x060400 card=0x chip=0x30401106 rev=0x10 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT86C586/A/B Power Management Controller' class= bridge subclass = PCI-PCI sis0@pci0:9:0: class=0x02 card=0x030e1154 chip=0x09001039 rev=0x02 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet pcm0@pci0:11:0: class=0x040100 card=0x00041073 chip=0x00041073 rev=0x05 hdr=0x00 vendor = 'Yamaha Corporation' device = 'YMF724 PCI Audio Controller' class= multimedia subclass = audio none0@pci1:0:0: class=0x03 card=0xff03102b chip=0x0521102b rev=0x01 hdr=0x00 vendor = 'Matrox Graphics Inc' device = 'MGA-G200B Chipset (AGP)' class= display subclass = VGA -- Toshiomi Moriki From: Shizuka Kudo <[EMAIL PROTECTED]> Subject: if_sis.c failed to attach my SiS630 ethernet controller with the latest commit > Dear all, > > I have tracked down the change on sys/pci/if_sis.c ver. 1.61 failed to attach my SiS >ethernet > interface. I have an ASUS TUSI-M, a SiS630 motherboard and running the latest >-current. After > backed out if_sis.c to ver. 1.60, the ethernet works fine. > > Here's the dmesg extract related to the ethernet interface. I has turned on verbose >boot, but it > doesn't give me further information. > > sis0: port 0xd400-0xd4ff mem 0xe780-0xe7800fff irq 14 at >device 1.1 on > pci0 > sis0: Ethernet address: 00:e0:18:00:00:03 > sis0: MII without any PHY! > device_probe_and_attach: sis0 attach returned 6 > > Regards, > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RELEASE failing on Thinkpad T30
> You are missing the src-sys-crypto collection in your supfile. > Either use the src-all collection (*strongly* recommended) or else > read the examples in /usr/share/examples/cvsup carefully and make > sure you are getting all the collections you need. I guess submitting a patch to ports/net/cvsupit that would include this selection would be a better way, eh? :) (i use cvsupit to make the cvsup file, so that's why i didn't even know i was missing something :) Thanks! Dana Lacoste Ottawa, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Required kernel config file change soon
Ok, this has been commited. Expect build breakage if you don't add one of these options or use GENERIC. Cheers, Jeff On Sun, 26 Jan 2003, Jeff Roberson wrote: > I'm about to commit code that will make one of : > > options SCHED_4BSD > > or > > options SCHED_ULE > > mandatory. This will go in a few hours from now. I will update all of > the standard config files to account for this change. SCHED_4BSD selects > the old scheduler in case you're wondering. Failure to specify one of the > two or specifying both will generate compile errors. I will add code to a > header file at some point to check this at make depend time. > > Cheers, > Jeff > > > 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
HEADS UP: Required kernel config file change soon
I'm about to commit code that will make one of : options SCHED_4BSD or options SCHED_ULE mandatory. This will go in a few hours from now. I will update all of the standard config files to account for this change. SCHED_4BSD selects the old scheduler in case you're wondering. Failure to specify one of the two or specifying both will generate compile errors. I will add code to a header file at some point to check this at make depend time. Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I've just had a massive file system crash
On Sun, 2003-01-26 at 08:08, David Schultz wrote: > Good. I was referring to IDE in this case, because I assume > that's what Greg's laptop uses. The ATA driver flushes the cache > when the device is closed, but I don't think that happens during > shutdown. It probably needs to register a shutdown hook like the > SCSI driver. Also, the driver is a bit optimistic about how long > the flush will take; it times out after 5 seconds, whereas the ATA > spec says a flush can take up to 30 seconds. I am wondering if I experienced this problem with my -stable laptop.. I shut it down and then booted it up later to find fsck having a nice good chew on the drive (deleting REAMS of files). I stopped it and then ripped it out of the lappy and mounted it read only to recover most of my files. Lots of things in /etc got toasted, and it was rather annoying to recover from :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acquiring duplicate lock of same type: "system map"
Kris Kennaway wrote: > > bento found the following about 5 minutes after I upgraded it to 5.0. > > acquiring duplicate lock of same type: "system map" > 1st system map @ ../../../vm/vm_map.c:2168 > 2nd system map @ ../../../vm/vm_kern.c:325 Thanks for the stack trace. I've finally flagged the system map mutex as duplicate ok, which it is. The commit was a few minutes ago. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Losing time on apm -Z (despite pmtimer)
I have acpi disabled and apm enabled in /boot/device.hints
because acpi didn't do standby properly: apm -Z wouldn't turn off the
screen backlight, and on reawakening the screen would be messed up.
(acpiconf -s {2,3} didn't work either.) With acpi, the following
problem doesn't exist. It also didn't exist on 4-STABLE.
When I put the laptop into standby (apm -Z) -- suspend doesn't work --
the clock stays where it was before standby, when reawakened. (eg, if
standby'd at 10:20 and reawakened at 11:00, it still shows 10:20).
I have "device pmtimer" in my kernel config, and
hint.pmtimer.0.at="isa"
in /device/hints. dmesg shows
pmtimer0 on isa0
This is -CURRENT cvsupped and built Jan 21, 2003.
Any ideas? Any more information I can give?
Thanks,
Rahul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Patch to teach config(8) about "platforms".
This patch is needed for the MIPS port's infrastructure, and will be
needed for the PowerPC one, as given ports may support any number of
platforms, on those architectures (and arguably, the same applies to
i386 vs. pc98, but historically...). What it does is it sets up a
build-time (and install-time, given right MACHINE_ARCH vs. MACHINE)
include directory as an analogue to , where we
need it. For kernels with a "platform" setting, it also sets the
appropriate option for it. For example "platform sgimips" implies
"options SGIMIPS". Below are patches to makefile glue and config(8)
itself.
For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in like:
#include
To let the platform determine the endianness, as the port may support
many such configurations with different values.
And note that while it is tempting to have be on
systems with MACHINE == MACHINE_ARCH, this breaks things like mkioctl.
%%%
diff -dur src/include/Makefile mips/include/Makefile
--- src/include/MakefileFri Jan 24 00:34:40 2003
+++ src/include/MakefileThu Jan 23 22:46:13 2003
@@ -80,7 +80,7 @@
.endfor
copies:
-.for i in ${LDIRS} ${LSYMSUBDIRS} machine crypto
+.for i in ${LDIRS} ${LSYMSUBDIRS} platform machine crypto
if [ -L ${DESTDIR}/usr/include/$i ]; then \
rm -f ${DESTDIR}/usr/include/$i; \
fi
@@ -95,6 +95,11 @@
cd ${.CURDIR}/../sys; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 opencrypto/*.h \
${DESTDIR}/usr/include/crypto
+.if ${MACHINE_ARCH} != ${MACHINE} &&
+exists(${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE})
+ cd ${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE}; \
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
+ ${DESTDIR}/usr/include/platform
+.endif
.if exists(${.CURDIR}/../sys/${MACHINE_ARCH}/include)
cd ${.CURDIR}/../sys/${MACHINE_ARCH}/include; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
@@ -118,6 +123,10 @@
rm -rf ${DESTDIR}/usr/include/$i
ln -s ../../../sys/$i ${DESTDIR}/usr/include/$i
.endfor
+ rm -rf ${DESTDIR}/usr/include/platform
+.if ${MACHINE_ARCH} != ${MACHINE} && exists(../../sys/${MACHINE_ARCH}/${MACHINE})
+ ln -s ../../sys/${MACHINE_ARCH}/${MACHINE} ${DESTDIR}/usr/include/platform
+.endif
rm -rf ${DESTDIR}/usr/include/machine
ln -s ../../sys/${MACHINE_ARCH}/include ${DESTDIR}/usr/include/machine
diff -dur src/sys/conf/kmod.mk mips/sys/conf/kmod.mk
--- src/sys/conf/kmod.mkFri Jan 24 00:35:37 2003
+++ src/sys/conf/kmod.mkThu Jan 23 22:47:11 2003
@@ -145,7 +145,7 @@
.endif
.endif
-_ILINKS=@ machine
+_ILINKS=@ machine platform
all: objwarn ${PROG}
@@ -170,10 +170,18 @@
.error "can't find kernel source tree"
.endif
+.if ${MACHINE_ARCH} != ${MACHINE} && exists(${SYSDIR}/${MACHINE_ARCH}/${MACHINE})
+PLATFORMPATH= ${SYSDIR}/${MACHINE_ARCH}/${MACHINE}
+.else
+PLATFORMPATH= machine
+.endif
+
${_ILINKS}:
@case ${.TARGET} in \
machine) \
path=${SYSDIR}/${MACHINE_ARCH}/include ;; \
+ platform) \
+ path=${PLATFORMPATH} ;; \
@) \
path=${SYSDIR} ;; \
esac ; \
diff -dur src/usr.sbin/config/config.h mips/usr.sbin/config/config.h
--- src/usr.sbin/config/config.hThu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/config.hFri Nov 1 11:16:59 2002
@@ -91,9 +91,11 @@
* being used. It uses the name of the machine in choosing
* files and directories. Thus if the name of the machine is ``i386'',
* it will build from ``Makefile.i386'' and use ``../i386/inline''
- * in the makerules, etc.
+ * in the makerules, etc. It also *may* know about a platform, which
+ * is a superconfiguration of a given machine.
*/
char *machinename;
+char *platformname;
/*
* For each machine, a set of CPU's may be specified as supported.
Only in mips/usr.sbin/config: config.o
diff -dur src/usr.sbin/config/config.y mips/usr.sbin/config/config.y
--- src/usr.sbin/config/config.yThu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/config.yFri Nov 1 11:16:59 2002
@@ -14,6 +14,7 @@
%token HINTS
%token IDENT
%token MAXUSERS
+%token PLATFORM
%token PROFILE
%token OPTIONS
%token MAKEOPTIONS
@@ -135,6 +136,10 @@
cp->cpu_name = $2;
cp->cpu_next = cputype;
cputype = cp;
+ } |
+ PLATFORM Save_id
+ = {
+ platformname = $2;
} |
OPTIONS Opt_list
|
Only in mips/usr.sbin/config: lang.c
diff -dur src/usr.sbin/config/lang.l mips/usr.sbin/config/lang.l
--- src/usr.sbin/config/lang.l Thu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/lang.l Fri Nov 1 11:16:59 2002
@@ -73,6 +73,7 @@
{ "machine",ARCH }, /* MACHINE is defined in /sys/param.h */
{ "makeoptions", MAKEOP
Re: acquiring duplicate lock of same type: "system map"
On Sat, Jan 25, 2003 at 12:59:25PM -0600, Alan L. Cox wrote: > Kris Kennaway wrote: > > > > bento found the following about 5 minutes after I upgraded it to 5.0. > > > > acquiring duplicate lock of same type: "system map" > > 1st system map @ ../../../vm/vm_map.c:2168 > > 2nd system map @ ../../../vm/vm_kern.c:325 > > Thanks for the stack trace. I've finally flagged the system map mutex > as duplicate ok, which it is. The commit was a few minutes ago. Thankyou! Kris msg50912/pgp0.pgp Description: PGP signature
Re: panic in fork() on SMP 5.0-RELEASE
On Sat, Jan 25, 2003 at 12:38:28PM -0800, Nate Lawson wrote: > The question is, why? I suspect something to do with memory due to the > second two bytes being a valid kernel address. How about a dmesg? > [forgot to cc: [EMAIL PROTECTED]] Are you suspecting faulty memory? See attached dmesg.boot. -- Morten Rodal Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RELEASE #0: Sun Jan 19 17:03:57 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp Preloaded elf kernel "/boot/kernel/kernel" at 0xc05e2000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc05e20b4. Preloaded elf module "/boot/kernel/snd_sb16.ko" at 0xc05e2160. Preloaded elf module "/boot/kernel/snd_sbc.ko" at 0xc05e2210. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc05e22bc. Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc05e2368. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05e2414. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 469749760 (447 MB) avail memory = 449974272 (429 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 19 -> irq 2 IOAPIC #0 intpin 18 -> irq 7 agp0: mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 IOAPIC #0 intpin 16 -> irq 11 nvidia0: mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 2 at device 4.2 on pci0 usb0: 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: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. Timecounter "PIIX" frequency 3579545 Hz pci0: at device 4.3 (no driver attached) ahc0: port 0xd000-0xd0ff mem 0xd580-0xd5800fff irq 2 at device 6.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xb800-0xb83f irq 7 at device 10.0 on pci0 xl0: Ethernet address: 00:10:4b:3e:23:58 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xcc000-0xd0fff,0xc-0xcb7ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 5,1 on isa0 pcm0: on sbc0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec ad0: 16479MB [33483/16/63] at ata0-master UDMA33 ad2: 43979MB [89355/16/63] at ata1-master UDMA33 acd0: DVD-ROM at ata0-slave PIO4 Waiting 15 seconds for SCSI devices to settle cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: cd present [327986 x 2048 byte records] da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 5.000MB/s transfers (5.000MHz, offset 15), Tagged Queueing Enabled da0: 8191MB (16777215 512 byte sectors: 255H 63S/T 1044C) SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a msg50911/pgp0.pgp Description: PGP signature
Re: I've just had a massive file system crash
Thus spake Nate Lawson <[EMAIL PROTECTED]>: > On Fri, 24 Jan 2003, David Schultz wrote: > > Thus spake Greg Lehey <[EMAIL PROTECTED]>: > > > I've been thinking about what happened, and I have a possibility: the > > > session before shutdown included a lot of writing to that file system, > > > and I did a shutdown -p. It's possible that the shutdown powered off > > > the system before the disk had flushed its cache. For the moment I'm > > > avoiding shutdown -p, but when I get home I'll try to provoke it > > > again. > > > > FreeBSD's ``fix'' for this problem is the same as Windows 98's. > > Specifically, there is a 5-second delay (tuneable: > > kern.shutdown.poweroff_delay) after all buffers are flushed but > > before the power is cut. Maybe we ought to be sending FLUSH > > CACHE commands to all drives and waiting for them to finish. > > da(4) does a SYNC CACHE (see daclose() and dashutdown()). Good. I was referring to IDE in this case, because I assume that's what Greg's laptop uses. The ATA driver flushes the cache when the device is closed, but I don't think that happens during shutdown. It probably needs to register a shutdown hook like the SCSI driver. Also, the driver is a bit optimistic about how long the flush will take; it times out after 5 seconds, whereas the ATA spec says a flush can take up to 30 seconds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in fork() on SMP 5.0-RELEASE
On Sat, 25 Jan 2003, Morten Rodal wrote: > The system is running 5.0-RELEASE with a pretty standard kernel (just > removed all the drivers I don't use and added SMP support). I think > the load of the system might have been high at the moment as I had > just started > > cd /usr/ports && make -j8 clean The problem is uap is invalid in this frame: #15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at /usr/src/sys/kern/kern_fork.c:124 The question is, why? I suspect something to do with memory due to the second two bytes being a valid kernel address. How about a dmesg? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic in fork() on SMP 5.0-RELEASE
Is this a known panic? I tried to search the mailinglist archives to
see if somebody had posted something similar, but I couldn't find
anything.
The system is running 5.0-RELEASE with a pretty standard kernel (just
removed all the drivers I don't use and added SMP support). I think
the load of the system might have been high at the moment as I had
just started
cd /usr/ports && make -j8 clean
before I went to eat dinner. When I came back a few hours later it at
rebooted, with this panic.
I have attached the backtrace of this (dual?) panic. I have never
poked in the kernel source code before, so if there is anything else
you need to know just ask and I'll see what I can do.
--
Morten Rodal
Script started on Sat Jan 25 21:17:42 2003
slurp# gdb -k kernel.0 vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01bdb48
stack pointer = 0x10:0xe3ac4c04
frame pointer = 0x10:0xe3ac4cac
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 = 580 (sh)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 5d18h59m34s
Dumping 447 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01d4bea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc021a852 in bwrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:796
#4 0xc021bf46 in vfs_bio_awrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc019e203 in spec_fsync (ap=0xe3ac49f4) at
/usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc019d558 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc02a9c62 in ffs_sync (mp=0xc3a37000, waitfor=2, cred=0xc1376e80, td=0xc035e900)
at vnode_if.h:612
#8 0xc022fb9b in sync (td=0xc035e900, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc01d47cb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc030b662 in trap_fatal (frame=0xe3ac4bc4, eva=0) at
/usr/src/sys/i386/i386/trap.c:844
#12 0xc030b312 in trap_pfault (frame=0xe3ac4bc4, usermode=0, eva=20) at
/usr/src/sys/i386/i386/trap.c:758
#13 0xc030ae02 in trap (frame=
{tf_fs = -475267048, tf_es = -1070792688, tf_ds = -988741616, tf_edi =
-1070209248, tf_esi = -988528640, tf_ebp = -475247444, tf_isp = -475247632, tf_ebx =
582, tf_edx = -989019040, tf_ecx = -988528640, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071916216, tf_cs = 8, tf_eflags = 66195, tf_esp = -1053458112, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:445
#14 0xc02f3918 in calltrap () at {standard input}:99
#15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at
/usr/src/sys/kern/kern_fork.c:124
#16 0xc030b9bc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 135258112, tf_ebp =
-1077938280, tf_isp = -475247244, tf_ebx = 135236344, tf_edx = 135236332, tf_ecx =
-1077938240, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134723859, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077938324, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1033
#17 0xc02f396d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Jan 25 21:18:04 2003
msg50908/pgp0.pgp
Description: PGP signature
Re: rcconf.sh error
Fixed. Thanks! -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50907/pgp0.pgp Description: PGP signature
Re: HEADS UP: new wi driver
> dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's. This > required the application know whether it was talking to a > prims/wavelan/symbol card so was replaced by WI_RID_SCAN_APS which > provides a device-independent interface. I changed wicontrol to > deal with this; it would be good if dstumbler did likewise. > Otherwise I can look at adding a backwards compatibility entry for > WI_RID_SCAN_REQ. I've updated the sources with the new wlan request type and I'm not getting anyfurther than before. All of the bsd-airtools have all kinds of nifty hacks to support the various interfaces and quirks of each of the cards. I think I'm going to dable with the various bsd-airtools and update them to use the same interface that wicontrol does and see if I can't kill off as many card specific quirks as I can. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Opening /dev/tty in session leader after controlling terminal is revoked causes panic.
In message <[EMAIL PROTECTED]>, "Peter Edwards" writes: >The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process >has its P_CONTROLT flag set, then it's session has a valid vnode for it's >controlling terminal. This doesn't hold if the terminal was revoked. Can you try this patch ? Index: tty_tty.c === RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v retrieving revision 1.46 diff -u -r1.46 tty_tty.c --- tty_tty.c 19 Jan 2003 11:03:07 - 1.46 +++ tty_tty.c 25 Jan 2003 19:39:15 - @@ -70,10 +70,12 @@ return; if (strcmp(name, "tty")) return; - if (curthread->td_proc->p_flag & P_CONTROLT) - *dev = curthread->td_proc->p_session->s_ttyvp->v_rdev; - else + if (!(curthread->td_proc->p_flag & P_CONTROLT)) + *dev = ctty; + else if (curthread->td_proc->p_session->s_ttyvp == NULL) *dev = ctty; + else + *dev = curthread->td_proc->p_session->s_ttyvp->v_rdev; } static void -- 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: firewire hangs on Thinkpad
This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I've just had a massive file system crash
On Fri, 24 Jan 2003, David Schultz wrote: > Thus spake Greg Lehey <[EMAIL PROTECTED]>: > > I've been thinking about what happened, and I have a possibility: the > > session before shutdown included a lot of writing to that file system, > > and I did a shutdown -p. It's possible that the shutdown powered off > > the system before the disk had flushed its cache. For the moment I'm > > avoiding shutdown -p, but when I get home I'll try to provoke it > > again. > > FreeBSD's ``fix'' for this problem is the same as Windows 98's. > Specifically, there is a 5-second delay (tuneable: > kern.shutdown.poweroff_delay) after all buffers are flushed but > before the power is cut. Maybe we ought to be sending FLUSH > CACHE commands to all drives and waiting for them to finish. da(4) does a SYNC CACHE (see daclose() and dashutdown()). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Opening /dev/tty in session leader after controlling terminal is revoked causes panic.
Attached is a panic and patch a patch for the problem in the Subject line.
The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process
has its P_CONTROLT flag set, then it's session has a valid vnode for it's
controlling terminal. This doesn't hold if the terminal was revoked.
Cheers,
Peter Edwards.
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x88
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc020795a
stack pointer = 0x10:0xcdd7e7b8
frame pointer = 0x10:0xcdd7e7c8
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 = 986 (mozilla-bin)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 20h40m24s
Dumping 256 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192[CTRL-C to abort] 208 224 240
---
#0 doadump () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) p/a 0xc020795a
$1 = 0xc020795a
(kgdb) bt
#0 doadump () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:232
#1 0xc01d1969 in boot (howto=260) at
/pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:364
#2 0xc01d1bc3 in panic () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:531
#3 0xc0214ea0 in bdwrite (bp=0xc7783bf0) at
/pub/FreeBSD/current/src/sys/kern/vfs_bio.c:955
#4 0xc028abab in ffs_update (vp=0xc27d3b18, waitfor=0)
at /pub/FreeBSD/current/src/sys/ufs/ffs/ffs_inode.c:125
#5 0xc029f62f in ffs_fsync (ap=0xcdd7e5c0) at
/pub/FreeBSD/current/src/sys/ufs/ffs/ffs_vnops.c:315
#6 0xc029e5f7 in ffs_sync (mp=0xc2691000, waitfor=2, cred=0xc0eb6e80, td=0xc034f000)
at vnode_if.h:612
#7 0xc022a7db in sync (td=0xc034f000, uap=0x0)
at /pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:138
#8 0xc01d154c in boot (howto=256) at
/pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:273
#9 0xc01d1bc3 in panic () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:531
#10 0xc02f9c42 in trap_fatal (frame=0xcdd7e778, eva=0)
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:844
#11 0xc02f9922 in trap_pfault (frame=0xcdd7e778, usermode=0, eva=136)
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:758
#12 0xc02f93f0 in trap (frame=
{tf_fs = -841547752, tf_es = -841547760, tf_ds = -1069416432, tf_edi =
-1033343948, tf_esi
= -
841487372, tf_ebp = -841488440, tf_isp = -841488476, tf_ebx = -841488376, tf_edx =
-841488260,
tf_ec
x = -1070401078, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071613606, tf_cs =
8,
tf_eflags
= 66050, tf_esp = -841488264, tf_ss = -1070401082})
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:445
#13 0xc02e94a8 in calltrap () at {standard input}:98
#14 0xc0195f38 in devfs_lookupx (ap=0x0) at
/pub/FreeBSD/current/src/sys/fs/devfs/devfs_vnops.c:382
#15 0xc01961db in devfs_lookup (ap=0xcdd7e914)
at /pub/FreeBSD/current/src/sys/fs/devfs/devfs_vnops.c:448
#16 0xc021ed12 in lookup (ndp=0xcdd7ebcc) at vnode_if.h:52
#17 0xc021e71b in namei (ndp=0xcdd7ebcc) at
/pub/FreeBSD/current/src/sys/kern/vfs_lookup.c:181
#18 0xc0231eb9 in vn_open_cred (ndp=0xcdd7ebcc, flagp=0xcdd7eccc, cmode=420,
cred=0xc2afb500)
at /pub/FreeBSD/current/src/sys/kern/vfs_vnops.c:122
#19 0xc0231e59 in vn_open (ndp=0x0, flagp=0x0, cmode=0)
at /pub/FreeBSD/current/src/sys/kern/vfs_vnops.c:86
#20 0xc022b683 in kern_open (td=0xc264d8c0, path=0x0, pathseg=UIO_USERSPACE,
flags=1538,
mode=438)
at /pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:662
#21 0xc022b490 in open (td=0x0, uap=0x0) at
/pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:625
#22 0xc02f9f6a in syscall (frame=
{tf_fs = -65489, tf_es = -1078001617, tf_ds = -1078001617, tf_edi = 703138768,
tf_esi =
678015
352, tf_ebp = -1077956120, tf_isp = -841486988, tf_ebx = 677213476, tf_edx = 1537,
tf_ecx =
67801535
2, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 677550019, tf_cs = 31, tf_eflags =
518,
tf_esp =
-1077956148, tf_ss = 47}) at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:1033
#23 0xc02e94fd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) disas ctty_clone
Dump of assembler code for function ctty_clone:
0xc0207910 :push %ebp
0xc0207911 : mov%esp,%ebp
0xc0207913 : sub$0x10,%esp
0xc0207916 : mov%ebx,0xf
Re: I've just had a massive file system crash
On Fri, Jan 24, 2003 at 11:03:52PM -0800, David Schultz wrote: > FreeBSD's ``fix'' for this problem is the same as Windows 98's. > Specifically, there is a 5-second delay (tuneable: > kern.shutdown.poweroff_delay) after all buffers are flushed but > before the power is cut. Maybe we ought to be sending FLUSH > CACHE commands to all drives and waiting for them to finish. I've heard is longer then 5sec on more recent systems like 2000 or XP. I even heard one claim that some shops were using 30sec internally. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg50901/pgp0.pgp Description: PGP signature
Re: HEADS UP: new wi driver
> > : dstumbler breaks; on startup it reports > > : "unable to ioctl device socket: Input/output error". > > > > As root or no? > > I have a rebuilt system finally that I could test this against and I'm > actually getting a different error message on startup of dstumbler: > > error: unable to ioctl device socket: Invalid argument > > From ktrace: > > 43042 dstumbler CALL sigaction(0x12,0x280b5850,0) > 43042 dstumbler RET sigaction 0 > 43042 dstumbler CALL socket(0x2,0x2,0) > 43042 dstumbler RET socket 3 > 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) > 43042 dstumbler RET ioctl -1 errno 22 Invalid argument > 43042 dstumbler CALL sigaction(0x12,0x280b5838,0x280b5850) > 43042 dstumbler RET sigaction 0 > 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) > 43042 dstumbler RET poll 0 > 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) > 43042 dstumbler RET poll 0 > 43042 dstumbler CALL write(0x1,0x806,0x5e) > 43042 dstumbler GIO fd 1 wrote 94 bytes >"\^[[52;22H\^[[34m\^[[1m[\^[[31m error: unable to ioctl device socket: \ > Invalid argument \^[[C\^[[39;49m\^[[m\^O" > dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's. This required the application know whether it was talking to a prims/wavelan/symbol card so was replaced by WI_RID_SCAN_APS which provides a device-independent interface. I changed wicontrol to deal with this; it would be good if dstumbler did likewise. Otherwise I can look at adding a backwards compatibility entry for WI_RID_SCAN_REQ. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: firewire hangs on Thinkpad
hmm, I have no problem with my FireWire CardBus card. If you can get traceback in DDB, please send it to me. cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=4000 fwohci1: mem 0x88004000-0x88007fff,0x88008000-0x880087ff irq 9 at device 0.0 on cardbus0 fwohci1: PCI bus latency was changing to 250. fwohci1: OHCI version 1.0 (ROM=1) fwohci1: No. of Isochronous channel is 4. fwohci1: EUI64 00:c0:d0:00:00:f8:56:6a fwohci1: Phy 1394a available S400, 2 ports. fwohci1: Link S400, max_rec 2048 bytes. firewire1: on fwohci1 if_fwe1: on firewire1 if_fwe1: Fake Ethernet address: 02:c0:d0:f8:56:6a fwohci1: BUS reset fwohci1: node_id = 0x8800ffc0, non CYCLEMASTER mode firewire1: 3 nodes, maxhop <= 2, cable IRM = 2 firewire1: new bus manager 2 firewire1: New S400 device ID:00d03200a412006a firewire1: New S400 device ID:00a0b00a00060633 firewire1: Device SBP-II /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Fri, 24 Jan 2003 15:48:23 +0100, Andrea Campi wrote: > > Hi all, > > I'm having a bad time trying to get a firewire cardbus adapter to work. > First of all, let me say that I'm under no pressure - I just bought it to > test our firewire implementation but I have no pressing need for it. > > Anyway, new kernel from last night, when I insert the card I get the following: > > cardbus0: Expecting link target, got 0x42 > cardbus0: Resource not specified in CIS: id=10, size=800 > cardbus0: Resource not specified in CIS: id=14, size=4000 > cardbus0: Resource not specified in CIS: id=18, size=800 > fwohci0: mem 0x880 >08000-0x880087ff,0x88004000-0x88007fff,0x88008800-0x88008fff irq 11 at device 0.0 on >cardbus0 > fwohci0: PCI bus latency was changing to 250. > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channel is 4. > fwohci0: EUI64 00:01:fb:00:00:00:00:6e > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwohci0: BUS reset > fwohci0: BUS reset > fwohci0: node_id = 0xc000ffc0, CYCLEMASTER mode > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > > > Sometimes it hangs the machine solid to the point I can't enter DDB, other > times it takes a few seconds during which the machine is responsive, other > times DDB is usable. I wasn't able to determine any rule to explain the > different behaviors, but if anybody has any idea, I can try go get to DDB > again and get any required info. > > Bye, > Andrea > > -- > Where do you think you're going today? > > 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: [PATCH] Asus A7N8X Deluxe, nForce2 and 3com MAC, Broadcom/Altima PHY
On Sat, Jan 18, 2003 at 02:46:38PM -0800, David O'Brien wrote: > On Sat, Jan 18, 2003 at 06:46:40PM +0200, Mikko Hyvarinen wrote: > > Hi again,O > > > > I find it outright odd that the partial patch that didn't help much got > > committed quickly but the final fix that makes things work didn't. > > > > Is there something wrong with the patch or did it just slip through the > > cracks somewhere? > > I got busy last week. I just happen to have a few free minutes when the > 1st patch came in, and I have a big interest in AMD platforms. I've got > too many things on my plate for today to probably get to the 2nd patch. > Other committers, please don't think I feel ownership of this patch. Thank you for the commit. Now the support for this board is on a good basic level. I suppose there is not much hope of getting support for the nVidia MAC integrated to the MCP (southbridge) since even the Linux drivers are binary-only with a thin glue layer, and no specs seem to be available on nVidia website, not even in the developer sections. Regards, MSH -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM & disklabel
On Sat, Jan 25, 2003 at 10:17:39 +0100, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Michael Reifenberger > writes: > >On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: > >... > >> Don't use the '-r' option, it gets confused because geom::BSD does > >> not lie to it. > >Yes, that seems to work... > >Time to say good bye for '-r' ? > > Well, we still need it for writing the first disklabel on an otherwise > empty disk, but I think it could be implied in that case. -B implies -r too. Currenty this check prevents my bootblocks from writting. -- 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: GEOM & disklabel
In message <[EMAIL PROTECTED]>, Michael Reifenberger writes: >On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: >... >> Don't use the '-r' option, it gets confused because geom::BSD does >> not lie to it. >Yes, that seems to work... >Time to say good bye for '-r' ? Well, we still need it for writing the first disklabel on an otherwise empty disk, but I think it could be implied in that case. -- 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: GEOM & disklabel
On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... > Don't use the '-r' option, it gets confused because geom::BSD does > not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? 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
Changes to pw/pw_user.c
I sent this message off about 12 hours ago, and I have not seen it appear anywhere. Since then I have received plenty of other messages on the mailing lists (including messages I sent after I sent this one). So, I'm resending this one... On Jan 24/2003, Max Khon wrote to freebsd-current: hi, there! Can we enable using '$' in usernames in pw? The patch is attached. Other variant is to enable using '$' only at end of user name. Here is a patch which allows a '$' as the last character of a userid or a group name. Technically this is based on a patch that Terry Lambert wrote, but by the time I was done with it I imagine it's not recognizable. This has been tested on i386 and sparc64 (beast.freebsd.org seems to be down right now, so I can't do a test-compile on alpha). This version of the patch only changes the pw_checkname() routine, and also includes the previous version of pw_checkname() so you can see how both the old and new routines behave on any given value. This also improves the error messages, and (IMO) makes the routine a lot easier to follow. Assuming there are no objections to this, I plan to rip out everything that's between the #ifdef/endif's of TESTING_PW, and commit the rest to -current sometime next week. I have no plans to MFC this change, but I'll also do that if people want it MFC'ed. Please look it over, and maybe run it through some tests, and let me know of any feedback to it. (Should this print out some kind of warning message that using '$' is generally not a good idea?) Instead of including the patch in my message (which I did the first time), I've put it up at: http://people.freebsd.org/~gad/pw/pw_user-c.diff -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
INVARIANTS-related fs panic on alpha
One of the alpha package clients panicked with this. It was under very high load at the time (25 simultaneous package builds): fatal kernel trap: trap entry = 0x2 (memory management fault) faulting va= 0xdeadc0dedeadc0e6 type = access violation cause = store instruction pc = 0xfc53453c ra = 0xfc53b2a8 sp = 0xfe001da15b30 curthread = 0xfc003e33b930 pid = 3, comm = g_up Stopped at add_to_worklist+0xac: stq a0,0x8(t0) <0xdeadc0dedeadc0e6> db> trace add_to_worklist() at add_to_worklist+0xac handle_written_inodeblock() at handle_written_inodeblock+0x5e8 softdep_disk_write_complete() at softdep_disk_write_complete+0xac bufdone() at bufdone+0x19c bufdonebio() at bufdonebio+0x1c biodone() at biodone+0x28 g_dev_done() at g_dev_done+0xd8 biodone() at biodone+0x28 g_io_schedule_up() at g_io_schedule_up+0x4c g_up_procbody() at g_up_procbody+0x9c fork_exit() at fork_exit+0x100 exception_return() at exception_return --- root of call graph --- db> msg50893/pgp0.pgp Description: PGP signature
lock order reversal (arp mutex/radix node head)
lock order reversal
1st 0xc03bbde0 arp mutex (arp mutex) @ ../../../netinet/if_ether.c:151
2nd 0xc6149e7c radix node head (radix node head) @ ../../../net/route.c:549
Debugger("witness_lock")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c031e895,c6149e7c,c033b2a0,c033b2a0,c033b2f6) at Debugger+0x55
witness_lock(c6149e7c,8,c033b2f6,225,0) at witness_lock+0x667
_mtx_lock_flags(c6149e7c,0,c033b2f6,225,c01bc2e4) at _mtx_lock_flags+0xb2
rtrequest1(2,df0d1c44,0,0,c638e680) at rtrequest1+0x5a
rtrequest(2,c638e680,0,0,0) at rtrequest+0x4b
arptfree(c612eb40,0,7530,97,7) at arptfree+0x76
arptimer(0,0,c03344ed,bf,1d9e6) at arptimer+0x80
softclock(0,0,c0331543,230,c21ab720) at softclock+0x19c
ithread_loop(c21a8e00,df0d1d48,c03313b4,361,0) at ithread_loop+0x182
fork_exit(c01a4650,c21a8e00,df0d1d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xdf0d1d7c, ebp = 0 ---
db>
Kris
msg50892/pgp0.pgp
Description: PGP signature
