'make buildworld' breakage in kdump
Hi, a recently cvsupped copy of the RELENG_5_0 branch breaks in usr.bin/kdump: ===> usr.bin/kdump sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include > ioctl.c /usr/src/usr.bin/kdump/mkioctls: awk: Argument list too long /usr/src/usr.bin/kdump/mkioctls: awk: Argument list too long *** Error code 2 The environment was: tybalt# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin tybalt# which xargs /usr/bin/xargs tybalt# It seems that a manual 'make; make install; make clean' for xargs fixed this - I am just redoing a 'make buildworld'. Regards -Thorsten To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound playback problem with Maestro3.c (?) -- clock issue
Hi Michael, Regarding your linux clock issue: There was a rather lively discussion at forums.gentoo.org about drastic clock sync loss caused by KDE. I don't know if it has been resolved in the 3.1 line, but if you were running linux KDE, you might take a look at that as a cause for the linux clock sync problem. /Paul Michael Ferguson wrote: Hi all, On a probably-unrelated side note, when I was running Linux on the same laptop (ducks), I had issues with the OS clock getting quickly out of sync with the HW clock; typically I would loose five minutes or more every hour. Although I haven't experienced the same thing with FreeBSD, I wonder if there is just something odd about interrupt handling or timing on the Inspiron 8000 line? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 10:16:18 GMT 2003 -- ===> ipfilter touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: subscribe
bleh, okay then, if I have to ;) sorry guys, not the best introduction to the list.. but yeah, hey. -luke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 08 January 2003 15:45 To: Luke Marsden Subject: Re: subscribe No. Subscibe yourself. :) Send an e-mail to [EMAIL PROTECTED] with the line "subscribe freebsd-current" in the body. [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/s
On Tue, Jan 07, 2003 at 11:41:33AM -0500, John Baldwin wrote: > Your 3rd party registered a lock somehow? Does it do mtx_init() and not > do mtx_destroy() when being unloaded? Gah! You hit this one right on the head. I thought I had equivalent mtx_destroy calls for every mtx_init, but there's a section of code that bzero()s a structure containing a mutex before initializing that mutex, so that caused this common mutex to be initialized twice without triggering a panic in witness_init(). The subsequent destroy only removed the one instance. I've fixed said code and now I can load/unload to my little heart's content. :). Thanks for replying. -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 msg49860/pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 16:16:05 GMT 2003 -- ===> ipfilter touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0RC2: does vinum work???
Hi, Has anyone gotten vinum to work using the 5.0RC2 ISO distribution? I've tried creating a raid5, a "raid10", and (finally) a basic, one-drive volume, and newfs fails for all cases, with: # newfs -U /dev/vinum/myvol newfs: /dev/vinum/myvol: can't figure out file system partition I've attached a typescript file (w/added comments) illustrating the problem for the basic, one-drive case. Is vinum broken in 5.0RC2, or am I doing something spectacularly stupid? -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. Script started on Wed Jan 8 09:49:51 2003 # # "resetdrive" annihilates the beginning of a disk, and reinitializes it # for use with vinum, using fdisk/disklabel. # bash-2.05b# ./resetdrive ad4 2048+0 records in 2048+0 records out 1048576 bytes transferred in 0.320496 secs (3271728 bytes/sec) *** Working on device /dev/ad4 *** fdisk: invalid fdisk partition table found 2048+0 records in 2048+0 records out 1048576 bytes transferred in 0.319751 secs (3279351 bytes/sec) bash-2.05b# fdisk ad4 *** Working on device /dev/ad4 *** parameters extracted from in-core disklabel are: cylinders=158816 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=158816 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 160086465 (78167 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 95/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: bash-2.05b# disklabel ad4s1 # /dev/ad4s1c: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 158815 sectors/unit: 160086465 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1600864650unused0 0# (Cyl.0 - 158815*) h: 1600864650 vinum # (Cyl.0 - 158815*) bash-2.05b# cat /tmp/vinum.cfg drive d1 device /dev/ad4s1h volume myvol plex org concat sd length 160086000s drive d1 bash-2.05b# vinum vinum -> create /tmp/vinum3.cfg 1 drives: D d1State: up /dev/ad4s1h A: 0/78167 MB (0%) 1 volumes: V myvol State: up Plexes: 1 Size: 76 GB 1 plexes: P myvol.p0C State: up Subdisks: 1 Size: 76 GB 1 subdisks: S myvol.p0.s0 State: up D: d1 Size: 76 GB vinum -> l -V 1 drives: Drive d1: Device /dev/ad4s1h Created on baal.soco.agilent.com at Wed Jan 8 09:50:50 2003 Config last updated Wed Jan 8 09:50:50 2003 Size: 81964270080 bytes (78167 MB) Used: 81964167680 bytes (78167 MB) Available: 102400 bytes (0 MB) State: up Last error: none Active requests:0 Maximum active: 0 Free list contains 1 entries: OffsetSize 160086265 200 1 volumes: Volume myvol: Size: 81964032000 bytes (78166 MB) State: up Flags: 1 plexes Read policy: round robin Plex 0:myvol.p0(concat), 76 GB 1 plexes: Plex myvol.p0: Size: 81964032000 bytes (78166 MB) Subdisks:1 State: up Organization: concat Part of volume myvol Subdisk 0: myvol.p0.s0 state: up size 81964032000 (78166 MB) offset 0 (0x0) 1 subdisks: Subdisk myvol.p0.s0: Size: 81964032000 bytes (78166 MB) State: up Plex myvol.p0 at offset 0 (0 B) Drive d1 (/dev/ad4s1h) at offset 135680 (132 kB) vinum -> quit bash-2.05b# newfs -U /dev/vinum/myvol newfs: /dev/vinum/myvol: can't figure out file system partition bash-2.05b# exit Script done on Wed Jan 8 09:51:09 2003
installworld 4->5 and perl still there afterwards
Hi, after following src/UPDATING for an update from 4.7-REL to RELENG_5_0 this afternoon on a test machine I recognized that there still is a /usr/bin/perl afterwards. Now I ask myself if there is a cleaner way to update from 4 to 5 (apart from reinstalling) to get an almost mere 5_0 ? Any shell scripts to clean up ? A make mrproper ? Or does one need to manually work on every find / \! -newer last-cvsup-log -print output line with some grep -v and rm -i ? If this is documented or has been discussed before I would be happy with the link to the docs or an message id. Thanks in advance. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld 4->5 and perl still there afterwards
"Bjoern A. Zeeb" wrote: > after following src/UPDATING for an update from 4.7-REL to RELENG_5_0 > this afternoon on a test machine I recognized that there still is a > /usr/bin/perl afterwards. > > Now I ask myself if there is a cleaner way to update from 4 to 5 > (apart from reinstalling) to get an almost mere 5_0 ? > > Any shell scripts to clean up ? A make mrproper ? > > Or does one need to manually work on every > find / \! -newer last-cvsup-log -print > output line with some grep -v and rm -i ? > > If this is documented or has been discussed before I would be happy > with the link to the docs or an message id. First message in thread "perl5.6.1 wrapper", ed, 6 Nov 2002 17:47:51 -0800 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=830574+0+archive/2002/freebsd-current/20021110.freebsd-current Feel free to fix the install process; no one else is going to, since the rules are that you can't call it FreeBSD unless the first CDROM exactly matches the "official" distribution, and it's installer sucks. You can call it "BjoernBSD (or just "Bjoern Free"? 8-) 8-?)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
if_dc attach patch
Here is an updated patch for dc. Can you try it? * Remove bogus locking * Move intr setup, ether_ifattach to end * add proper resource freeing to a case that missed it (!mac) * update resource freeing for error cases after intr move -Nate Index: if_dc.c === RCS file: /home/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.85 diff -u -r1.85 if_dc.c --- if_dc.c 27 Nov 2002 07:04:10 - 1.85 +++ if_dc.c 8 Jan 2003 18:49:22 - @@ -1927,13 +1927,13 @@ if (!(command & PCIM_CMD_PORTEN)) { printf("dc%d: failed to enable I/O ports!\n", unit); error = ENXIO; - goto fail_nolock; + goto fail; } #else if (!(command & PCIM_CMD_MEMEN)) { printf("dc%d: failed to enable memory mapping!\n", unit); error = ENXIO; - goto fail_nolock; + goto fail; } #endif @@ -1944,36 +1944,12 @@ if (sc->dc_res == NULL) { printf("dc%d: couldn't map ports/memory\n", unit); error = ENXIO; - goto fail_nolock; + goto fail; } sc->dc_btag = rman_get_bustag(sc->dc_res); sc->dc_bhandle = rman_get_bushandle(sc->dc_res); - /* Allocate interrupt */ - rid = 0; - sc->dc_irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, - RF_SHAREABLE | RF_ACTIVE); - - if (sc->dc_irq == NULL) { - printf("dc%d: couldn't map interrupt\n", unit); - bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); - error = ENXIO; - goto fail_nolock; - } - - error = bus_setup_intr(dev, sc->dc_irq, INTR_TYPE_NET | - (IS_MPSAFE ? INTR_MPSAFE : 0), - dc_intr, sc, &sc->dc_intrhand); - - if (error) { - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->dc_irq); - bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); - printf("dc%d: couldn't set up irq\n", unit); - goto fail_nolock; - } - DC_LOCK(sc); - /* Need this info to decide on a chip type. */ sc->dc_info = dc_devtype(dev); revision = pci_read_config(dev, DC_PCI_CFRV, 4) & 0x00FF; @@ -2162,6 +2138,8 @@ mac = pci_get_ether(dev); if (!mac) { device_printf(dev, "No station address in CIS!\n"); + bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); + error = ENXIO; goto fail; } bcopy(mac, eaddr, ETHER_ADDR_LEN); @@ -2184,8 +2162,6 @@ if (sc->dc_ldata == NULL) { printf("dc%d: no memory for list buffers!\n", unit); - bus_teardown_intr(dev, sc->dc_irq, sc->dc_intrhand); - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->dc_irq); bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); error = ENXIO; goto fail; @@ -2245,8 +2221,6 @@ if (error) { printf("dc%d: MII without any PHY!\n", sc->dc_unit); - bus_teardown_intr(dev, sc->dc_irq, sc->dc_intrhand); - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->dc_irq); bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); error = ENXIO; goto fail; @@ -2266,11 +2240,6 @@ } /* -* Call MI attach routine. -*/ - ether_ifattach(ifp, eaddr); - - /* * Tell the upper layer(s) we support long frames. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); @@ -2304,14 +2273,37 @@ } #endif - DC_UNLOCK(sc); - return(0); + /* +* Call MI attach routine. +*/ + ether_ifattach(ifp, eaddr); + + /* Allocate interrupt */ + rid = 0; + sc->dc_irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, + RF_SHAREABLE | RF_ACTIVE); + + if (sc->dc_irq == NULL) { + printf("dc%d: couldn't map interrupt\n", unit); + bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); + error = ENXIO; + goto fail; + } + + error = bus_setup_intr(dev, sc->dc_irq, INTR_TYPE_NET | + (IS_MPSAFE ? INTR_MPSAFE : 0), + dc_intr, sc, &sc->dc_intrhand); + + if (error) { + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->dc_irq); + bus_release_resource(dev, DC_RES, DC_RID, sc->dc_res); + printf("dc%d: couldn't set up irq\n", unit); + } fail: - DC_UNLOCK(sc); -fail_nolock: - mtx_destroy(&sc->dc_mtx); - ret
system wedges running dd with of=/dev/fd0
On a -current cvsuped on Jan2-2003 uname -a FreeBSD k7.jibe.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jan 8 09:21:54 MST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 To reproduce error... cd /somedir where somedir has a valid floppy image file like kern.flp Then... dd if=kern.flp of=/dev/fd0 and machine wedges. In the best cases using a GENERIC kernel the screen goes blank, keyboard is inactive, hard drive light is on 100%. Have to recycle input power to get back in control. WARNING..WARNING..WARNING... In worst cases like the 1st time I noticed this, I was running a custom kernel and using the /sysutils/sdd port. In addition to all the above nasty symptoms on subsequent power up the machine was dead. BIOS had been butchered. I had to go onto the motherboard and force a BIOS reset to factory defaults and then reconfig the BIOS to get the system back to a usable state. VERY UGLY I've tried a lot of test permutations that i'll not go into here, but the above dd incantation fails every invocation. Also note that on this same harddrive I have a partition that runs FreeBSD 4.7R and dd and sdd to/from the floppy work flawlessly. Which makes me tend to believe that this is not a hardware problem. In GENERIC these are all on options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Yet nothing is trapped and I see nothing logged in /var/log/messages. I also have dumpdev="/dev/ad4s4b" dumpdir="/usr/flameout" in my /etc/rc.conf and nothing is getting picked up by savecore in there on reboot. Can anyone else duplicate this? If so then a PR is in order. If not I'll re-cvsup and rebuild and test again and repost for further help. As the cusp of 5.0 Release draws near I am distressed to have run into a problem of this severity. -bob- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: bg fsck
Hello all, I'm using 5.0-RC2 and after disconnecting a firewire HD and unclean shutdown the system is panicing after reboot (I can login) and a few minutes with the following message: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4e1 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02188ec stack pointer = 0x10:0xcdc4e4d0 frame pointer = 0x10:0xcdc4e4f0 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 = 495 (fsck_ufs) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? I have a HPT370 controller (Dawicontrol DC100) with RAID1 mirror and mountig root from ar0s1a. The ad0 firewire device isn't connected and set to noauto in fstab! All the values of the panic message are varying but the process is always fsck_ufs and the fault code is always "supervisor write, page not present", also the code segment lines are always the same. Please tell me if I can provide more infos, but I'm not subscribed so please cc directly. Best regards, -Harry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0RC2: does vinum work???
Vinum is running fine here on 5.0 for already quite some time. the trick is most likely: newfs -T ufs /dev/vinum/vinum0 building a raid5 in vinum goes spectactular easy: vinum raid5 /dev/ad4s1h /dev/ad5s1h /dev/ad6s1h /dev/ad7s1h vinum init vinum0.p0 --WjW > Has anyone gotten vinum to work using the 5.0RC2 ISO distribution? > I've tried creating a raid5, a "raid10", and (finally) a basic, > one-drive volume, and newfs fails for all cases, with: > > # newfs -U /dev/vinum/myvol > newfs: /dev/vinum/myvol: can't figure out file system partition > > I've attached a typescript file (w/added comments) illustrating the > problem for the basic, one-drive case. > > Is vinum broken in 5.0RC2, or am I doing something spectacularly > stupid? > > -- > Darryl Okahata > [EMAIL PROTECTED] > > DISCLAIMER: this message is the author's personal opinion and does not > constitute the support, opinion, or policy of Agilent Technologies, or > of the little green men that have been following him all day. > > N '²æìr¸zǧvf¢Ú&j:+v¨· è®"¶§²æìr¸yúÞy»rêëz{bØ^nr¡ûazg¬±¨
Re: 5.0RC2: does vinum work???
"Willem Jan Withagen" <[EMAIL PROTECTED]> write: > Vinum is running fine here on 5.0 for already quite some time. > > the trick is most likely: > > newfs -T ufs /dev/vinum/vinum0 Nope. No joy: # newfs -T ufs /dev/vinum/myvol newfs: /dev/vinum/myvol: can't figure out file system partition Since it's working for you, the problem is probably related to newfs (existing vinum volumes are probably fine). Arg. Out of desperation, I tried using "vinum0" as the volume name, instead of "myvol". It worked (the "-T" isn't needed). Foo. Arg. OK, I'll now try putting numbers at the end of volume names. Thanks for the help. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0RC2: does vinum work???
Darryl Okahata wrote: "Willem Jan Withagen" <[EMAIL PROTECTED]> write: Vinum is running fine here on 5.0 for already quite some time. the trick is most likely: newfs -T ufs /dev/vinum/vinum0 Nope. No joy: # newfs -T ufs /dev/vinum/myvol newfs: /dev/vinum/myvol: can't figure out file system partition Since it's working for you, the problem is probably related to newfs (existing vinum volumes are probably fine). Arg. Out of desperation, I tried using "vinum0" as the volume name, instead of "myvol". It worked (the "-T" isn't needed). Foo. Arg. Yep, the naming is the problem. Afaik due to the GEOM system newfs has changed. The vinum volume name must either end in '0' or 'a' to allow the newfs operation... however there is some message in current which says that someone (grog?) is working on it. -- didi http://checkrdf.sourceforge.net/ - -> for your daily news needs on your FreeBSD box <- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bg fsck
Harald Schmalzbauer wrote: Hello all, I'm using 5.0-RC2 and after disconnecting a firewire HD and unclean shutdown the system is panicing after reboot (I can login) and a few minutes with the following message: [...] Please tell me if I can provide more infos, but I'm not subscribed so please cc directly. Best regards, -Harry On Dec the 14th was a similar message on the current-list. I recommend to boot in single user mode, fsck'ing your disks, reboot in multi-user mode and cvsup your system. After a rebuild it may work. Hope it helps a little. Best regards, Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bg fsck
I was also getting these same repetitive page fault panics on 5.0-RC2 related to fsck_ufs running after a hard crash. Booting single user and doing a manual fsck resolved it until the next system crash, then they normally occurred again. Don't know if this would apply to you, but in my case re-installing the entire system on UFS1 instead of UFS2 put an end to the panics. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: panic: bg fsck
Jeff Walters wrote: > I was also getting these same repetitive page fault panics on 5.0-RC2 > related to fsck_ufs running after a hard crash. Booting single user > and doing a manual fsck resolved it until the next system crash, then > they normally occurred again. > > Don't know if this would apply to you, but in my case re-installing > the entire system on UFS1 instead of UFS2 put an end to the panics. I used UFS1 not 2, but I got reply from M. K. McKusick that this was fixed the day after RC2 was released, so it seems the problem is solved. Haven't tried yet though. Thanks all, -Harry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0RC2: does vinum work???
On Wednesday, 8 January 2003 at 10:00:59 -0800, Darryl Okahata wrote: > Hi, > > Has anyone gotten vinum to work using the 5.0RC2 ISO distribution? > I've tried creating a raid5, a "raid10", and (finally) a basic, > one-drive volume, and newfs fails for all cases, with: > > # newfs -U /dev/vinum/myvol > newfs: /dev/vinum/myvol: can't figure out file system partition > > I've attached a typescript file (w/added comments) illustrating the > problem for the basic, one-drive case. > > Is vinum broken in 5.0RC2, or am I doing something spectacularly > stupid? Vinum is broken in RC2. I committed the fix yesterday. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0RC2: does vinum work???
On Wednesday, 8 January 2003 at 13:29:06 -0800, Darryl Okahata wrote: > "Willem Jan Withagen" <[EMAIL PROTECTED]> write: > >> Vinum is running fine here on 5.0 for already quite some time. >> >> the trick is most likely: >> >> newfs -T ufs /dev/vinum/vinum0 > > Nope. No joy: > > # newfs -T ufs /dev/vinum/myvol > newfs: /dev/vinum/myvol: can't figure out file system partition > > Since it's working for you, the problem is probably related to newfs > (existing vinum volumes are probably fine). The problem was that at one point newfs wanted a volume label and wouldn't work unless it got one. So I gave it one and didn't notice that it only worked as long as the last character of the volume name is a valid partition identified (a-h or 0-7). newfs is now fixed, so I backed out the change, but I forgot about it on the RELENG_5_0 branch until Jörg Wunsch reminded me yesterday. Sorry for the confusion. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 -- ===> vx touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/vx. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Wed, Jan 08, 2003 at 11:25:12PM +, Mike Barcroft said words to the effect of; > Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html > > -- > >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include > -- > >>> stage 4: building libraries > -- > >>> stage 4: make dependencies > -- > >>> stage 4: building everything.. > -- > >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 > -- > ===> vx > touch: >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: > No such file or directory > *** Error code 1 FWIW, I can't reproduce this locally, it must be a problem with the tinderbox. I haven't seen Mike around lately, hopefully he can see what's going on soon. Sorry for the spam. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Jake Burkholder <[EMAIL PROTECTED]> writes: > Apparently, On Wed, Jan 08, 2003 at 11:25:12PM +, > Mike Barcroft said words to the effect of; > > -- > > >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 > > -- > > ===> vx > > touch: >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: > No such file or directory > > *** Error code 1 > > FWIW, I can't reproduce this locally, it must be a problem with the > tinderbox. I haven't seen Mike around lately, hopefully he can see > what's going on soon. > > Sorry for the spam. Hmm, I'll try clearing the obj directory and see if that helps. I did have some trouble with the filesystem the tinderbox runs on. fsck may have deleted some files that left things in an unexpected state. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System freeze running -current
On Fri, Jan 03, 2003 at 11:16:57AM -0800, Nate Lawson wrote: > Sounds like an atkbd or syscons problem. > Did you suspend the laptop and resume before this happens? No. However, it happened to me today shorty after I issued a sysctl -w hw.acpi.cpu.economy_speed=8. (Why does it default to 4 anyway?) > How does "unset acpi_load" at the boot prompt change things? Well, I can't reproduce it consistently, so it'll be hard to determ- ine if disabling ACPI does the trick. I also noticed I was able to drop into the debugger and the keyboard works fine in it. Can you suggest what I should be looking for? > -Nate Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System freeze running -current
Hi all, On Sat, 4 Jan 2003 17:55:25 + Trent Nelson <[EMAIL PROTECTED]> wrote: > No. However, it happened to me today shorty after I issued a sysctl > -w hw.acpi.cpu.economy_speed=8. (Why does it default to 4 anyway?) It reminded me of my tiny local patch. --- src/sys/dev/acpica/acpi_cpu.c.orig Thu Oct 17 02:28:52 2002 +++ src/sys/dev/acpica/acpi_cpu.c Mon Dec 23 12:58:28 2002 @@ -328,7 +328,7 @@ if (speed < CPU_MAX_SPEED) { /* mask the old CLK_VAL off and or-in the new value */ - clk_val = CPU_MAX_SPEED << cpu_duty_offset; + clk_val = (CPU_MAX_SPEED - 1) << cpu_duty_offset; p_cnt &= ~clk_val; p_cnt |= (speed << cpu_duty_offset); Virtually yours, Taku -- YAMAMOTO, Taku <[EMAIL PROTECTED]> Digital circuits are made from analog parts. -- Don Vonada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NVIDIA driver compilation failed
On Thu, 2 Jan 2003, Scott Long wrote: > It looks like sys/filedesc.h needs to be included in nv-freebsd.h This got me up and running again on -current compiled 12/31. Thanks Scott! Now that I'm used to the better performance of the nvidia drivers, it's really noticable when it's not there. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message