Re: problems with sysinstall
Sergey Matveychuk [EMAIL PROTECTED] wrote: Don't use chainloader with FreeBSD. Use 'kernel /boot/loader' instead. This is documented in the GRUB info doc. Again, I have set this exact system up with redhat on the first disk and it works perfectly. Grub do not supporting UFS2. So only way to boot -current is chainloader. Boot -current using the Windows XP bootloader. Unfortunately, I don't know of a single site with correct/complete information, but here are two pages to get you started (BACKUP your Windows partition before using the information in the following): http://bsdatwork.com/sections.php?op=viewarticleartid=3 (Also read the OpenBSD section for additional WinXP info.) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#NT-BOOTLOADER -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
Kevin Oberman [EMAIL PROTECTED] wrote: Great to hear that it's working. Now I just wonder why you had to do this. My T30 has standard IRQs (most everything shares 11) and I have not seen this. My fxp0 works fine with CURRENT and has worked for quite some time, maybe since pre-5.0-Release. I typically update the system about once a week. Has the OP used ``hw.pci.allow_unsupported_io_range=1''? I had to use this with my A31 to prevent nasty fxp-related crashes in 5.1-RELEASE. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
Jesse Guardiani [EMAIL PROTECTED] wrote: 1.) When in X Windows (this never happened in Linux. What gives?) Another WAG: have you tried this kernel option?: options SC_NO_SUSPEND_VTYSWITCH It prevented X11 from crashing my A31 (but didn't help with the display corruption). -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
Jesse Guardiani [EMAIL PROTECTED] wrote: Help! This APM BIOS suspends fine under Linux (2.4.18 kernel)! I've tried everything I can think of to get suspend working under 5.1-RELEASE! Wild-a** guess: ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed I don't get this in my dmesg (and I have an A31, where apm seems to work). As you say it seems to be hanging during ATA reset, perhaps this has something to do with it? Is there any way to disable the ata1-slave? BIOS? Kernel setting??? -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: programs not running under strace
Christopher Nehren [EMAIL PROTECTED] wrote: Has anyone else experienced anything like this? I'm thinking that it could possibly have something to do with the scheduler, but I'm probably wrong. Perhaps the same problem that affects truss, also affects strace? (See the recent 5.1 release TODO messages for details.) -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot0cfg
Kevin Oberman [EMAIL PROTECTED] wrote: For any system less than about 4 year old and may older systems, you really want to use this option. The other possibility, if both FreeBSD and XP are installed on the same disk, is to just use XP's boot selector to select which one to boot. It can be a lot easier than having to deal with boot sector issues. For more information, see: http://bsdatwork.com/sections.php?op=viewarticleartid=3 (This is for the case where Windows FreeBSD are on the SAME drive.) (Also read the OpenBSD section for additional WinXP info.) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#NT-BOOTLOADER -- 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: NTLDR missing after 5-RELEASE install
walt [EMAIL PROTECTED] wrote: For example, IIRC, I just went thru this myself (although it's all so routine now I can't even remember what I do to bail out anymore) when I installed XP on a brand new disk and then installed FBSD afterwards. I got the MBR screwed up just like you, then ran the XP install disk in Repair mode which got XP to boot again but overwrote the FBSD booter. So all I did was boot my trusty GRUB floppy and reinstalled GRUB on the MBR in about 60 seconds and -- done. A better way is to *NOT* install any special boot loader, and just use Win2K/XP's boot mechanism to switch between 2K/XP and FreeBSD. The advantage here is that you don't have to touch the boot sector which, as we've seen, can cause problems with some desktops/laptops. For more information, see: http://bsdatwork.com/sections.php?op=viewarticleartid=3 (This is for the case where Windows FreeBSD are on the SAME drive.) (Also read the OpenBSD section for additional WinXP info.) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#NT-BOOTLOADER -- 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: NTLDR missing after 5-RELEASE install
[EMAIL PROTECTED] (George Hartzell) wrote: I'm pretty sure that it's not operator error on my part, since it happened several times. I suspect that there aren't that many people playing with 5.0 that don't install the standard boot stuff, and so that path isn't exercised too much. I installed 5.0 with the booteasy MBR on my IBM laptop, and it worked fine. The problem I had was that *ANY* MBR-based boot program interfered with IBM's special product recovery software, and so I instead decided to just use Win2K/XP's boot mechanism to boot FreeBSD (as I explained in my previous message). [ Yes, FreeBSD and XP (in my case) would still have worked if I kept booteasy, but I really wanted to keep IBM's product recovery software, and so I switched to using 2K/XP's method. In hindsight, that's probably the best approach, as it doesn't require any MBR changes or boot floppies/CDs. ] -- 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: NTLDR missing after 5-RELEASE install
[EMAIL PROTECTED] (George Hartzell) wrote: Only differences are which partition we mark active and what boot loader lives there. True, but that's the key point: ... and what boot loader lives there. There are times when not touching the boot loader is desirable. While GRUB, booteasy, and others are quite perfectly usable for many people, some of us may be better off with an untouched MBR. -- 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: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
Terry Lambert [EMAIL PROTECTED] wrote: I think this is an expected problem with a lot of concatenation, whether through Vinum, GEOM, RAIDFrame, or whatever. This comes about for the same reason that you can't mount -u to turn Soft Updates from off to on: Soft Updates does not tolerate dirty buffers for which a dependency does not exist, and will crap out when a pending dirty buffer causes a write. Does this affect background fsck, too (on regular, non-vinum filesystems)? From what little I know of bg fsck, I'm guessing not, but I'd like to be sure. Thanks. -- 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: background fsck deadlocks with ufs2 and big disk
Vallo Kallaste [EMAIL PROTECTED] wrote: I'll second Brad's statement about vinum and softupdates interactions. My last experiments with vinum were more than half a year ago, but I guess it still holds. BTW, the interactions showed up _only_ on R5 volumes. I had 6 disk (SCSI) R5 volume in Compaq Proliant 3000 and the system was very stable before I enabled softupdates.. and of course after I disabled softupdates. In between there were crashes and nasty problems with filesystem. Unfortunately it was production system and I hadn't chanche to play. Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. -- 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: background fsck deadlocks with ufs2 and big disk
David Schultz [EMAIL PROTECTED] wrote: IIRC, Kirk was trying to reproduce this a little while ago in response to similar reports. He would probably be interested in any new information. I don't have any useful information, but I do have a data point: My 5.0-RELEASE system recently mysteriously panic'd, which resulted in a partially trashed UFS1 filesystem, which caused bg fsck to hang. Details: * The panic was weird, in that only the first 4-6 characters of the first function (in the panic stacktrace) was displayed on the console (sorry, forgot what it was). Nothing else past that point was shown, and the console was locked up. Ddb was compiled into the kernel, but ctrl-esc did nothing. * The UFS1 filesystem in question (and I assume that it was UFS1, as I did not specify a filesystem type to newfs) is located on a RAID5 vinum volume, consisting of five 80GB disks. * Softupdates is enabled. * When bg fsck hung (w/no disk activity), I could break into the ddb. Unfortunately, I don't know how to use ddb, aside from ps. * Disabling bg fsck allowed the system to boot. However, fg fsck failed, and I had to do a manual fsck, which spewed lots of nasty SOFTUPDATE INCONSISTENCY errors. * Disturbingly (but fortunately), I then unmounted the filesystem (in multi-user mode) and re-ran fsck, and fsck still found errors. There should not have been any errors, as fg fsck just finished running. [ Unfortunately, I've forgotten what they were, and an umount/fsck done right now shows no problems. I think the errors were one of the incorrect block count errors. ] * After the fsck, some files were partially truncated ( corrupted?). After investigating, I believe these truncated files (which were NOT recently modified) were in a directory in which other files were being created/written at the time of the panic. -- 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: background fsck deadlocks with ufs2 and big disk
Brad Knowles [EMAIL PROTECTED] wrote: You know, vinum softupdates have had bad interactions with each other for as long as I can remember. Has this truly been a consistent thing (as I seem to recall), or has this been an on-again/off-again situation? Ah, yaaah. Hmm This is the first I've heard of that, but I can see how that could be. Could vinum be considered to be a form of (unintentional) write-caching? That might explain how the filesystem got terribly hosed, but it doesn't help with the panic. Foo. [ This is on a system that's been running in the current state for around a month. So far, it's panic'd once (a week or so ago), and so I don't have any feel for long-term stability. We'll see how it goes. ] -- 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: ACPI thermal panics ThinkPad 600X
Tom Rhodes [EMAIL PROTECTED] wrote: ACPI gives me hell on my IBM Thinkpad A31, also. Yet since it does not crash anything I just leave it be waiting for the day when the ACPI hackers have time to fix it :) It may not necessarily be a FreeBSD problem (or, not only). While there may be issues with FreeBSD's ACPI, there are definitely issues with the A31 BIOS: http://sourceforge.net/mailarchive/message.php?msg_id=3597168 -- 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: ACPI thermal panics ThinkPad 600X
Terry Lambert [EMAIL PROTECTED] wrote: A more useful reference, I think, is: http://sourceforge.net/mailarchive/message.php?msg_id=3597172 If you add similar code to FreeBSD to detect and patch the BIOS table, this fixes the problem in FreeBSD, as well (though adding the code is somewhat tricky: YMMV, knowledge of both FreeBSD and Linux required; sorry, I do not have a patch against -current). Yah, I think the correct/updated version is at: http://www.poupinou.org/acpi/ibm_ecdt.html However, I think I'll pray and wait for an IBM BIOS fix. I'm not yet that desperate. ;-( In the meantime, I'll muddle through with apm. -- 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: APM and ACPI fail on Toshiba Satellite
Cliff L. Biffle [EMAIL PROTECTED] wrote: I sort of expected ACPI to fail after watching everyone else, but the killer here is that APM doesn't seem to work either once ACPI is disabled. Its error messages are less interesting. When compiled into the kernel, there are no error messages, but the /dev/apm device doesn't appear. Is this line in /boot/device.hints?: hint.apm.0.disabled=1 I got bit by this, too. -- 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
gbde vnode md devices?
Has anyone gotten gbde working with vnode md devices (file-based)? I'm trying to create a gbde-managed device from a file, and I keep on getting various ioctl() failures. See attached log file. Thanks, -- 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. # # First attempt: use entire md device for gbde # su-2.05b# cd /tmp su-2.05b# dd if=/dev/zero bs=1k count=16k of=foo 16384+0 records in 16384+0 records out 16777216 bytes transferred in 2.256249 secs (7435888 bytes/sec) su-2.05b# ll foo* -rw-r--r-- 1 root wheel 16777216 Feb 2 12:06 foo su-2.05b# mdconfig -a -t vnode -f /tmp/foo md0 su-2.05b# ll /dev/md* crw-r- 1 root operator4, 17 Jan 27 22:50 /dev/md0 crw--- 1 root wheel 95, 0x00ff Jan 27 22:50 /dev/mdctl su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock Enter new passphrase: Reenter new passphrase: Wrote key 0 at 1400320 su-2.05b# gbde attach md0 -l /tmp/foo.lock Enter passphrase: gbde: ioctl(GEOMCONFIGGEOM): Invalid argument # # Second attempt: use first slice for gbde # su-2.05b# mdconfig -d -u md0 su-2.05b# rm foo* su-2.05b# dd if=/dev/zero bs=1k count=16k of=foo 16384+0 records in 16384+0 records out 16777216 bytes transferred in 2.365870 secs (7091352 bytes/sec) su-2.05b# ll foo -rw-r--r-- 1 root wheel 16777216 Feb 2 12:10 foo su-2.05b# mdconfig -a -t vnode -f /tmp/foo md0 su-2.05b# fdisk -I md0 *** Working on device /dev/md0 *** fdisk: invalid fdisk partition table found su-2.05b# fdisk md0 *** Working on device /dev/md0 *** parameters extracted from in-core disklabel are: cylinders=520 heads=1 sectors/track=63 (63 blks/cyl) parameters to be used for BIOS calculations are: cylinders=520 heads=1 sectors/track=63 (63 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 32697 (15 Meg), flag 80 (active) beg: cyl 1/ head 0/ sector 1; end: cyl 519/ head 0/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED su-2.05b# gbde init /dev/md0s1 -L /tmp/foo.lock Enter new passphrase: Reenter new passphrase: Wrote key 0 at 312320 su-2.05b# gbde attach md0s1 -l /tmp/foo.lock Enter passphrase: gbde: ioctl(GEOMCONFIGGEOM): Invalid argument # # Third attempt: use a partition for gbde # su-2.05b# mdconfig -d -u md0 su-2.05b# rm foo* su-2.05b# dd if=/dev/zero bs=1k count=16k of=foo 16384+0 records in 16384+0 records out 16777216 bytes transferred in 2.267865 secs (7397802 bytes/sec) su-2.05b# mdconfig -a -t vnode -f /tmp/foo md0 su-2.05b# fdisk -I md0 *** Working on device /dev/md0 *** fdisk: invalid fdisk partition table found su-2.05b# disklabel md0s1 disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device
Re: gbde vnode md devices?
[EMAIL PROTECTED] wrote: su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock Don't use the -L and -l arguments unless you have to. Thanks, but that was what I originally tried, and I still got the gbde: ioctl(GEOMCONFIGGEOM): Invalid argument error. In other words, I get the same error regardless of whether or not I use the -L/-l options. [ Sorry for being unclear, but I originally tried gbde(8) without -L or -l. I switched to using -L and -l because that's what the man page showed, and I assumed that the man page knew something I didn't. ] -- 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: gbde vnode md devices?
Sorry, I'm being forgetful: I'm getting these errors under 5.0-RELEASE. -- 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: gbde vnode md devices?
[EMAIL PROTECTED] wrote: Can you please try this: mdconfig -a -t malloc -s 4m -u 75 gbde init /dev/md75 gbde attach md75 Nope, exact same error. -- 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
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: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED 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
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: USB issues with Apollo KT133A mobo
Cliff L. Biffle [EMAIL PROTECTED] wrote: Could be. The ATA controller was also flaking out under 4.7, but is solid as a rock under 5.0-DP2, which is why I'm sticking with it despite other potential bugs. I can burn CDs now! Many (most? all?) KT133A-based motherboards have a known issue with the PCI bus that often results in an IDE transfer problem. However, this was fixed (IIRC) in FreeBSD around the 4.5/4.6 timeframe (maybe earlier). [ Hmmm. You're probably seeing another problem with 4.7. ] In the discussion link you sent me, they discuss the controller disabling the port due to excessive current draw...would it re-enable the port when I simply un/replug the mouse? Normally I'd expect that to require a reboot. (The mouse does come back when I remove it and reinsert it, and generally X doesn't even notice.) I don't know how FreeBSD handles it. Under Windows, a dialog box pops up when an overcurrent situation occurs, and the box contains a button that'll reset and re-enable the bus. The KT133 discussion suggests it's a hardware problem, which wouldn't surprise me...this particular mobo is a very early Athlon board, and the chipset may be buggy. Motherboards using the VIA KT133A chipset generally do not have a good reputation. -- 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: USB issues with Apollo KT133A mobo
Daniel O'Connor [EMAIL PROTECTED] wrote: Many (most? all?) KT133A-based motherboards have a known issue with the PCI bus that often results in an IDE transfer problem. However, this was fixed (IIRC) in FreeBSD around the 4.5/4.6 timeframe (maybe earlier). [ Hmmm. You're probably seeing another problem with 4.7. ] I have motherboards where this fix doesn't work :( You have tried -current, right? (I assume that you have, but I just want to make sure.) Cliff mentioned that -current works for him, but 4.7 doesn't. I haven't searched the archives very hard, but I could only find a reference to the VIA patch being applied to -current (Soren's post of around December 26, 2001). I haven't tried rummaging through the CVS logs. I've always assumed that the VIA patch was MFC'd, but I can't any verification of this. -- 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: USB issues with Apollo KT133A mobo
Cliff L. Biffle [EMAIL PROTECTED] wrote: More specifically, all USB devices lose power. The device nodes stay in /dev and there are no notices to dmesg about the loss until I unplug and replug them, at which time it says 'port error: restarting port N' where N is generally 0, depending on which controller it is. It then redetects my hardware. 1. IIRC, USB ports on KT133A motherboards were buggy (???). 2. Drawing too much power from the USB ports can cause the ports to shut down. The absolute maximum limit is 500mA, which isn't much (some 2.5 USB hard disks can draw MUCH more, which violates the spec, and sometimes works, and sometimes doesn't). Here's another discussion on this: http://groups.google.com/groups?hl=enlr=lang_enie=UTF-8threadm=ajedc5%24bej%241%40paris.btinternet.comrnum=1 -- 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: Compaq Evo n115
Ilya Novoselov [EMAIL PROTECTED] wrote: This seems to be the important part: pcm0: VIA VT82C686A port 0x1850-0x1853,0x1854-0x1857,0x1000-0x10ff irq 5 at device 7.5 on pci0 So that works, but still no sound, but I don't get any error either. This line tells that sound device is detected and working problem, maybe you just need to adjust mixer with aumix or something? If you look at the referenced linux patch, you'll see a workaround for a no sound problem. Perhaps that's the problem? -- 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: cc1 crashes with SIGBUS while building XFree86-Server-4.2.0_2
Fluid [EMAIL PROTECTED] wrote: How about signal 4? I was rebuilding my -current the other day and I kept getting mostly signal 4 errors (in different places) with a couple of signal 10's and 11's. I tried finding a run-down of what the various errors meant, but I couldn't find a thing. The signal number mapping is in /usr/include/sys/signal.h. [ Um, if you don't know what the signals mean, you might not want to be running -current. ] SIGILL (signal 4) is usually not good (e.g., bad RAM, IDE data corruption, etc.). The weird thing is that when I switched terminals in KDE (i.e. opened a new Konsole window), my build problems ceased. Possible bad RAM: the new window allocated enough memory such that a bad spot in memory was allocated to the new Konsole's process, and not randomly to the build processes. Windows XP runs on the same box with no problems (i.e. will run for weeks without a reboot) so I'm a little hesitant to blame my hardware. This doesn't necessarily mean much. Windows will either not stress the hardware as much, or will use RAM in different ways. I seem to recall hearing rumors that Windows allocates memory from the top down. If so, and if FreeBSD allocates memory from the bottom up (I don't know), that could explain why you do not appear to be seeing the problem under xp. However, as other people are having mysterious problems with -current, it could be a software problem. -- 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: rtld messing up?
Last month, Mark Murray [EMAIL PROTECTED] wrote: In ports/lang/gcl, a program is undumped, and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. I've also have had that same problem when I tried to build the port, but was never able to find the reason for the program to segfault, I even opened a PR on that. The program seems to work on NetBSD btw.=20 PR ports/34661 :-) Has anyone gotten any further on this? I took a look at ports/34661, but nothing new has been added to it. Using 4-STABLE (sorry, I'm not using -current), I took a quick stab at the problem (having dealt with XEmacs undump issues in a past life), but I haven't gotten anywhere, yet: XEmacs uses unexelf.c, whereas gcl uses unexec.c. Changing gcl to use unexelf.c didn't change anything, but the next step is to compare the two unexelf.c's (they are different). The core stack trace seems to imply that there's some constructor initialization issue that undump isn't handling properly. -- 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: rtld messing up?
[ cc'd to ports (re: ports/34661). The problem here is that gcl, in
ports/lang, is not building due to a core dump. This patch might
fix it. ]
I wrote:
PR ports/34661 :-)
Using 4-STABLE (sorry, I'm not using -current), I took a quick stab
at the problem (having dealt with XEmacs undump issues in a past life),
but I haven't gotten anywhere, yet:
Well, the problem appears to be that undump() isn't properly
adjusting the ELF section headers. The bug also seems to exist in
XEmacs (and probably GNU Emacs as well), but it's only triggered if a
small section (less than 32 bytes in size) exists before the BSS
section. Hacky, ugly, not-for-public-consumption kludgy patch attached.
Apply in the o subdirectory. Line numbers will be off, but the patch
should apply fine otherwise. Due to non-functioning makefile
dependencies, you'll have to manually delete o/unixsave.o (or do a
make clean) after applying this patch.
I'm not sure if the patch is 100% correct, but it should be close.
I probably won't have any more time to clean up the patch (e.g.,
eliminate the code duplication and debugging code), and so it would be
nice if someone else could do that and submit it.
--
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.
*** unexelf.c.orig Thu Mar 22 14:54:58 2001
--- unexelf.c Wed Apr 3 21:48:40 2002
***
*** 935,944
= OLD_SECTION_H (old_bss_index-1).sh_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#else
if (round_up (NEW_SECTION_H (nn).sh_offset,
OLD_SECTION_H (old_bss_index).sh_addralign)
! = new_data2_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#endif
/* Any section that was originally placed after the section
header table should now be off by the size of one section
--- 948,972
= OLD_SECTION_H (old_bss_index-1).sh_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#else
+ # if 1
+ if (round_up (NEW_SECTION_H (nn).sh_offset,
+ OLD_SECTION_H (nn).sh_addralign 0 ? OLD_SECTION_H
+(nn).sh_addralign : 1) == new_data2_offset OLD_SECTION_H(nn).sh_size 0 ||
+ round_up (NEW_SECTION_H (nn).sh_offset,
+ OLD_SECTION_H (nn).sh_addralign 0 ? OLD_SECTION_H
+(nn).sh_addralign : 1)
+ new_data2_offset) {
+ # else
if (round_up (NEW_SECTION_H (nn).sh_offset,
OLD_SECTION_H (old_bss_index).sh_addralign)
! = new_data2_offset) {
! # endif
! # ifdef DEBUG
! fprintf(stderr,
! Rounding up section %d, old: 0x%08x, new: 0x%08x\n,
! nn, NEW_SECTION_H (nn).sh_offset,
! NEW_SECTION_H (nn).sh_offset + new_data2_size);
! # endif
NEW_SECTION_H (nn).sh_offset += new_data2_size;
+ }
#endif
/* Any section that was originally placed after the section
header table should now be off by the size of one section
Re: Just a reminder
Robert Watson [EMAIL PROTECTED] wrote: Ah, very cool indeed. :-) It seems to me the kernel entry point should be mi_start() rather than main(), however. Shouldn't it be mi_startup(), instead? Also, that page, while very useful for casual browsers, just uses global. Anyone knee-deep in the kernel should be using global directly (or cscope, which is my preference), as you'll then be able to browse your locally-modified version of the code. -- 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: unknown PNP hardware
Mike Smith [EMAIL PROTECTED] wrote: It's written for 4.X, but might work for -current (you'll have to disable the checks for 4.X, at the very least). You use it like this: dmesg | scanirq It's completely obsoleted by devinfo and pciconf's '-v' flag. Sorry. 8) Cool! I didn't want to support it, anyway. ;-) -- 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: Headsup! KSE Nay-sayers speak up!
Jim Bryant [EMAIL PROTECTED] wrote: FreeBSD is going to be left in the dust unless both the SMPng *AND* KSE proje cts are integrated into 5.0. Is there some reason why KSE couldn't be integrated ASAP *AFTER* 5.0 is released? [ Personally, I'd like to see it in 5.0, but, with all the qualms that people seem to have, I'm curious as to why it can't be integrated immediately after 5.0 is cut? This way, Julian's MFCs are reduced, and it gives people more time to pound on KSE. ] -- 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: unknown PNP hardware
Alexander Langer [EMAIL PROTECTED] wrote: Thus spake David W. Chapman Jr. ([EMAIL PROTECTED]): I'm running -current as of an hour ago. I've gotten this since I've been running 4.2-stable, any ideas on how I can find out what it belongs to? Statically wired ISA devices. unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources 501 are the sio ports for example. Look up some PNP devices listings, they're probably all listed in your device.hints. Going off on a slight tangent, I wrote a perl script months ago that parsed the output of dmesg, and tried to determine which IRQs were used, and for what. One of the side-effects of this script is that it also tried to identify unknown PCI devices (but *only* if an IRQ is used), using an (old) hard-coded table originally obtained from: http://www.yourvote.com/pci/pcidev.csv You can get the script from: ftp://ftp.sonic.net/pub/users/darrylo/freebsd/scanirq.gz It's written for 4.X, but might work for -current (you'll have to disable the checks for 4.X, at the very least). You use it like this: dmesg | scanirq -- 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: Lucent Orinoco Gold PCCard?
Nick Sayer [EMAIL PROTECTED] wrote:
Christopher Masto wrote:
I am told that the Apple "AirPort Base Station", which is $399, works
well and can be configured with the Java-based thing in the ports
collection. I am further told that the Lucent/ORiNOCO RG-1000 base
station is virtually identical, although more expensive and somehow
inferior, although I don't understand the exact inferiorities.
It is inferior in two ways:
Also, there are other alternatives to the AirPort (which is closer
to $299 than $399). One is the Buffalo AirStation (around $280-$340,
depending on options -- see
http://www.melcoinc.com/english/network/air.html). Other, cheaper,
access points have been mentioned here in earlier messages. The
AirStation is sold in the US by TechWorks (http://www.techworks.com)
among possibly others.
I've got an AirStation, and it's not bad. Like most access points,
it has only 40-bit encryption, though. It's configurable via a web
browser, using password-protected web pages. However, because of this,
the configuration needs to be done via a secure, wired lan, as the web
passwords are transmitted in plain text.
--
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: Lucent Orinoco Gold PCCard?
I wrote: Also, there are other alternatives to the AirPort (which is closer to $299 than $399). One is the Buffalo AirStation (around $280-$340, I forgot to mention that the AirStation supposedly supports roaming between access points. I haven't tried it, though. -- 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: [sound] PCI ESS support
Julian Elischer [EMAIL PROTECTED] wrote: I have 1)the usual DSMaestro2E 3-02-98.pdf datasheet, 2)some small stuff I grabbed off ftp.esstech.com.tw (nolonger exists on the site?) and I have just got this doc. is anyone going to work on this? Well, I was going to take Ville-Pertti Keinonen's ([EMAIL PROTECTED]) ESS2 mixer code and turn it into an LKM, which I'd then try to add sound output using the Linux code. However, I'm not familiar with how one accesses interrupts and DMA under FreeBSD, and so it would take me a while. If anyone else would like to do it, that's fine with me. My dell seems to have one of these things in it. As does mine. ;-( I really want sound output on my 7500. -- 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: Why not gzip iso images?
Anatoly Vorobey [EMAIL PROTECTED] wrote: On Wed, Mar 15, 2000 at 08:14:37AM -0500, Matt Heckaman wrote: It's been my experience that gzipping an ISO (or other compression tools) do not make enough different to justify the time it takes to both compress and uncompress these things. For example, the time needed to un-gzip the ISO could be longer than the time it would take to download the space that was saved by it. Alas, that is just not true for many of us who are in bandwidth-poor countries. Over here, it can take 3 to BIGNUM hours to download an ISO image (there aren't any up-to-date local mirrors), depending on time of day and the phase of the moon. I think compression would definitely help. While you are right about the download/gunzip times, compression doesn't help that much. As has been mentioned in -hackers, the ISO images only compress by 3% or so, or around ~20MB. So, instead of a 640MB ISO image, you have a 620MB image. Is the 20MB significant? (I don't know.) -- 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: [sound] PCI ESS support
[EMAIL PROTECTED] (Munehiro Matsuda) wrote: If you are tring to write a driver for it, I still have some docs around. If you need them, let me know. If you have anything more than the ESS datasheets (like real ESS docs), I'd like to get a copy. Thanks, -- 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: [sound] PCI ESS support
[EMAIL PROTECTED] (Munehiro Matsuda) wrote:
No, I don't have real ESS docs.
Thanks, anyway.
I have 1)the usual DSMaestro2E 3-02-98.pdf datasheet, 2)some small stuff
I grabbed off ftp.esstech.com.tw (nolonger exists on the site?) and
There are hidden files on ftp.esstech.com.tw. Just go to:
ftp://ftp.esstech.com.tw/PCIAudio/Maestro2E/
"PCIAudio" is an hidden directory.
3)source code for Maestro 2E Board Test (BTM2E.EXE) program which I
downloaded from ftp://ftp.alsa-project.org/pub/manuals/ess/maestro.tar.gz.
Thanks for the pointer. I'll check it out.
--
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: error wich devices ad*
"joanra" [EMAIL PROTECTED] wrote: I have done all what you have told me to do, but it still doesn't work. Now i have another problem, i have removed the DEVICES WD* (as you told me) and i can't mount partitions. It mounts WD on / but just as READ-ONLY and i can't do anything, How could i mount it whith writing permisions to continue trying things?? At this point, you're slightly screwed -- you can probably fix your system, but it's going to take some work. I hope you have backups. -Mensaje original- De: Nick Hibma [EMAIL PROTECTED] Boot with kernel.old and remake all your devices: cp /usr/src/etc/MAKEDEV /dev/MAKEDEV cd /dev sh MAKEDEV all This will probably only work if you did an installworld, as MAKEDEV needs the new version of /sbin/mknod; the old, existing version won't work. Also note that "MAKEDEV all" doesn't make the slice devices (e.g., /dev/ad0s1a); you'll have to explicitly tell MAKEDEV to build those. If you didn't do an installworld, but did rebuild the kernel and attempted to mess with /dev, the general procedure for fixing this is: [ DANGER: I HAVE NOT TESTED THE FOLLOWING PROCEDURE. I AM CREATING THE FOLLOWING PROCEDURE FROM MEMORY, AND SO IT MAY BE MISSING KEY PARTS, WHICH COULD DESTROY ALL DATA ON YOUR SYSTEM. MAKE SURE YOU HAVE BACKED UP YOUR SYSTEM BEFORE TRYING ANY OF THE FOLLOWING. ] 1. Boot from a fixit floppy/CDROM. In the past, I've used a FreeBSD 3.3-RELEASE CDROM for this. [ I'm also amazed that the following procedure works, given that I'm running -current binaries under 3.3-RELEASE. ] 2. Mount the hard disk. I generally mount it as "/mnt". 3. Do (assuming /mnt as the mount point): cd /mnt mv dev dev.old mkdir dev cd dev cp /mnt/usr/src/etc/MAKEDEV . 4. If you did a buildworld: cp /mnt/usr/obj/usr/src/sbin/mknod/mknod /sbin If you did not do a buildworld (yes, this is messy, but it should work): cd /mnt/usr/src/sbin/mknod make cp mknod /sbin 5. Do: cp /mnt/usr/src/etc/group /etc # Needed for group "wheel" cd /mnt/dev sh ./MAKEDEV all sh ./MAKEDEV ad2s1a # since you use the ad2 slices NOTE 1: the first time you run MAKEDEV, it may complain about missing programs; if so, put/install the missing programs into the correct locations, and re-run MAKEDEV (until no errors occur). NOTE 2: You don't have to execute "sh MAKEDEV ad2s1b", etc., to make the other slice devices; running "sh MAKEDEV ad2s1a" will create all of the "ad2s1*" devices. and make sure you update /etc/fstab as well. wd - ad, wcd - acd. Then do a to clean up your device tree: cd /dev rm -f wcd* wd* rwcd* rwd* Nick On Thu, 20 Jan 2000, joanra wrote: Hi when i run freebsd, display: Mounting root from ufs: /dev/ad2s1a no such device ad setrootbyname failed ffs_mountroot: can't find rootvp root mount failed: 6 mounting root from ufs: wd2s1a swapon: /dev/ad2s1b: device not configure Automatic reboot in ptogress can't open /dev/ad2s1a: device not configured my fstab: # DeviceMountpoint /dev/ad2s1b none /dev/ad2s1a / /dev/ad2s1f /usr /dev/ad2s1e /var /dev/cd0c /cdrom cd9660 proc/proc anyone help me please? P.S: i recompiled a new kernel, and i create the new devices ad*, and my hd is seconday thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ 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: Problems with the ATA-driver
Soren Schmidt [EMAIL PROTECTED] wrote: It seems Nick Hibma wrote: If you end up doing this, can you have the driver print a line letting people know this is intentional? i.e., ad0: DMA disabled: This drive does not properly support DMA mode. ad0: To force DMA for this drive (at your own risk) set flags 0xXX. Let's not go the Linux way and make the boot messages slow down booting. Agreed. While this can be moved into the man page, I don't see how a message like this can significantly slow down booting, unless you have a slow serial console. However, a pointer is still useful; I'd suggest a shorter message like: ad0: DMA disabled: See ad(4) man page for possible reasons. (Replace "ad" with the name of the ata man page.) If you're really concerned about boot messages and boot speed, all messages for configured devices should be suppressed and only printed for boot -v; only errors, warnings, and unconfigured device info should be displayed. Today, the "non-verbose" boot messages are pretty verbose. Examples include: ata-pci0: Busmastering DMA supported Having this line is no different from the above "DMA disabled ..." message (although, yes, the messages are from different drivers). lpt0: Interrupt-driven port If you're really concerned about boot speed, this line can be merged with the main lpt0 line, e.g. use: lpt0: generic printer on ppbus 0, Interrupt-driven port instead of: lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port (And yes, I did take a look at the code to see if this is possible, and it easily is.) acd0: supported read types: CD-R, CD-DA, DVD-ROM, DVD-R acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: 120mm data disc loaded, unlocked Again, these are probably "boot -v" information. If you're really concerned about boot speed, you should be concerned about this. [ Personally, I like the way dmesg is now, but I guess some people don't. ] -- 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: HEADSUP: wd driver will be retired!
Poul-Henning Kamp [EMAIL PROTECTED] wrote: Once we have established that the new driver doesn't leave a large number of people stranded it will be killed for good. I think this is a key issue, if not *THE* key issue. Please correct me if I'm wrong, but PHK and others are basically saying: 1. If we allow the old drivers to exist, many people will not use the new drivers, and the new drivers will get little testing. 2. We, therefore, need to force people to use the new drivers by getting rid of the old ones. The concerns that other people have are: 1. "I'm worried about ATA. It was just called ``alpha-quality'' a few days ago, and now you want to promote it to something past ``beta-quality'', where, during a typical beta-test, both old and new drivers coexist. I'm worried about the stability of the ATA drivers." The timing is extremely unfortunate. Many people would have much fewer concerns (or "whining", as has been poorly said) if there were a "testing period" longer than a few days (where the ATA drivers are the default, but the old wd drivers still existed). 2. Functionality is currently missing. I hope I'm wrong, but the attitude seems to be: "If the ATA drivers are missing functionality, either fix it yourself or send hardware to the developers. If you can't fix it, you shouldn't be running -current". Well, this is fine to say, but I'd like to point out: * Many -current users have newer hardware, and tend to have fewer hardware that may not be supported by the new ATA drivers. Many -current users can afford to buy newer hardware (or do so because of business/consulting reasons). * I believe that many users of -release or -stable (who are not running -current and are not reading -current) tend to use older hardware -- the kind that may not be supported by the ATA drivers. The problem here is that we are potentially preventing users of older hardware from running 4.0-release/-stable when it comes out, because no one running -current has an example of their older hardware, and we removed the old drivers which may have worked. In other words, it's unclear as to whether or not the new driver will leave any significant number of people stranded, even if all -current developers test the h*ll out of ATA. -- 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: trek73
Matthew Dillon [EMAIL PROTECTED] wrote: I found a copy of the C version of trek73 in my Amiga archives. This is the trek73 originally written in HP-2000 Basic that was rewritten by Dave Pare and Chris Williams in C and seriously enhanced by a bunch of people including me in my early college years circa 1985. Wow. Talk about ancient history. Out of curiosity, how different is this version from the one (V4.0) posted to comp.sources.games back in December, 1987? Just FYI, if this is the Jeff Okamoto I'm thinking about, he's with HP. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, 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: trek73
Matthew Dillon [EMAIL PROTECTED] wrote:
Hmm... it looks like the one I have is older. It looks like Jeff had
made a huge number of enhancements between 1985 and 1988! Pretty cool,
actually, though neither game is multi-player.
Well, for multi-player, we had the most fun with "xtrek" (the early
version -- not the later, ultra-enhanced releases). For those of you
too young to remember ;-), xtrek was an X11, multi-player (up to 16?),
real-time game where you flew a ship (e.g., Federation, Klingon,
Romulan, or Orion) and tried to kill the other players. You could also
conquer your opponent's planets, but few people did that, as it was much
more fun to go after other players. The view was 2D/top-down, looking
down into a flat map of the universe, upon which your ships flew.
Back around '88 or '89, we used to have a fair number of people
playing after-hours. Although it had very primitive graphics by today's
(or even yesterday's) standards, xtrek was easy-to-learn, easy-to-play,
and a blast to play. It was extremely maddening to watch your opponent,
who you were sure was toast, due to the massive photon torpedo burst you
sent his way, deftly weave and avoid the torpedos, and kill you with a
point-blank phaser blast. For all it's simplicity, skill played a
significant part.
We only stopped playing xtrek when I foolishly upgraded to one of
the latest-and-greatest, ultra-feature-burdened versions. No one played
it, as it was too difficult to play, and the play was unbalanced.
One thing about the early xtrek: it was a funky program, as it
wasn't client/server-based (later versions were, but they weren't as
much fun to play). It was basically a single program/server, which
opened up a window on each player's display. Still, performance was
pretty good (on a *local* LAN), even on ten-year-old RISC hardware.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, 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: Why Adaptec 1540 bombing?
Warner Losh [EMAIL PROTECTED] wrote: If you can send me this card, I can see what I can do about making it work with the aha driver. There are problems with CAM and this hardware's use of transfer residuals which might make it hard to get working. If he can't, I've got a 1540A somewhere (in theory ;-) that I'd be willing to lend out (if the address is in the US). It's been years since I've used it, and so I'm not 100% sure that it still works, though. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, 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: modules: how to use?
The Hermit Hacker [EMAIL PROTECTED] wrote: Figuring one of the things a friend of mine raves about Linux for is their kld's, I'd start playing with ours... [ Going off on a slight tangent ... ] You may have gone beyond this, but a good introduction to klds is an article called, "Attacking FreeBSD with Kernel Modules", at: http://thc.pimmel.com Click on "Articles", followed by "Attacking FreeBSD with Kernel Modules (example modules)". I'm not sure how up-to-date it is, though. Strange, but true. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, 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: New PnP code does not work for me(?)
Peter Wemm [EMAIL PROTECTED] wrote: We're not doing this because we enjoy pain and suffering, it's because it'll be better and more robust in the long run. Unfortunately, there was no canonical list of logical ID's on the cards we used to recognize. So I repeat for the list.. If you've got a card that used to work or does work under BIOS backwards compat preconfig with 'controller pnp0' disabled, please send us a dmesg and pnpinfo -v so we can add the ID's. 'controller pnp0' is quite likely to become non-optional soon so we can use the motherboard resource lists. I want to publicly thank Peter Wemm for posting a reply that is courteous, informative, and useful. Recently, there has been too much noise in this and other FreeBSD lists/groups where other people have been abrupt to the point of rudeness. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, 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: gcc optimizer in -current system ...
"Zach N. Heilig" [EMAIL PROTECTED] wrote:
The application for the tests is mpg123.
test mp3 playing time: 373 seconds.
[ ... ]
1) No Optimization
225.08 real 224.30 user 0.23 sys
[ ... ]
2) -O3 -mcpu=i486 -march=i486 -fomit-frame-pointer -fschedule-insns
-fschedule-insns2
141.92 real 141.43 user 0.10 sys
What do these timings represent? As you say the mp3 playing time
is 373 seconds, but the "real" times vary, the timings don't appear to
be the playing/processing of the mp3 file.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, 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: ccd build failure
In the interests of peace and harmony (;-), I'd like to submit the
attached perl script, which lists the status of cvs-controlled files.
In particular, it's very useful for determining which files have been
modified but not committed, like:
i386/linux/linux_file.cLocally Modified
kern/imgact_elf.c Locally Modified
CVS is severely lacking in many areas (it is all we have, though), and
one thing it is missing is an easy way of showing concise file status.
As a result, it's easy to forget about locally-modified files. This
perl script will list all files, in the current directory and below,
that do not have a status of "Up-to-date", such as those which have been
locally modified or which need updating.
To use this script, just cd to some directory that contains cvs-
controlled files and run the script. A list of non-up-to-date files in
the current directory and below will be listed. Note that this script
isn't particularly fast, as it has to execute a cvs command in each and
every directory (due to cvs deficiencies). As examples, the script
takes around 3 minutes to run under /usr/src/sys, and around 30 minutes
for /usr/src (checked out via "cvs checkout src").
[ My (local, mirrored via cvsup) repository is accessed via pserver
over 128K ISDN, and so there's a good chance that many people will see
better performance. ]
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
#! /usr/bin/perl
###
#
# File: cvsinfo
# RCS: $Header: $
# Description:
# Author: Darryl Okahata
# Created: Wed Jul 15 14:52:01 1998
# Modified: Thu Sep 23 11:35:35 1999 (Darryl Okahata) [EMAIL PROTECTED]
# Language: CPerl
# Package: N/A
#
# (C) Copyright 1998, Hewlett-Packard, all rights reserved.
#
###
$listfile = ".changed-files";
###
require 'getopts.pl';
Getopts('ac');
$all_status = 1 if ($opt_a);
$update_changed_file = 1 if ($opt_c);
require "pwd.pl";
initpwd;
$top_dir = $ENV{'PWD'};
###
open(DIRS, "find . -type d | sort |") || die "$!";
while ($dir = DIRS) {
chdir($top_dir);# make sure we're in a known location
chop($dir);
$dir =~ s|^\./||;
$dir = '.' if ($dir eq '');
#print "$dir\n";
next if (!-d "$dir/CVS");
process_dir($dir);
}
close(DIRS);
if ($update_changed_file) {
unlink($listfile);
open(OUT, "$listfile") || die "$listfile: $!";
if ($#update_files = 0) {
foreach $file (sort @update_files) {
print OUT "$file\n";
}
}
close(OUT);
}
exit 0;
###
sub process_dir
{
local($dir) = @_;
local($file, $status, $cmd);
#print "$dir\n";
chdir($dir);
$cmd = "cvs status -l";
open(IN, "$cmd 21 |") || die "$!";
while (IN) {
if (/^File:\s+([^\s]+)\s+Status:\s+(.+)$/i){
$file = $1;
$status = $2;
if ($all_status || $status ne 'Up-to-date') {
if ($status eq 'Needs Patch') {
$status = 'Needs Updating';
}
printf("%-50s %s\n", ($dir eq '.') ? $file : "$dir/$file",
$status);
if ($status =~ /Locally Modified/) {
push(@update_files, $file);
}
}
} elsif (/\[status\s+aborted\]/) {
die "$_\n";
}
# print;
}
close(IN);
}
Re: ccd build failure
Oliver Fromme [EMAIL PROTECTED] wrote:
Uhm... Maybe I misunderstand what your 100-line perl script
does, but I use the following 3-line shell script instead:
#!/bin/sh -
cvs status | grep '^File:' | grep -v 'Status: Up-to-date$'
true
This works (and is faster), but it doesn't give you concise,
nicely-formatted pathnames. Personally, I prefer status like:
i386/linux/linux_file.cLocally Modified
kern/imgact_elf.c Locally Modified
instead of:
cvs server: Examining aaa ...
cvs server: Examining bbb ...
cvs server: Examining ccc ...
cvs server: Examining ddd ...
cvs server: Examining eee ...
File: linux_file.c Status: Locally Modified
cvs server: Examining fff ...
cvs server: Examining ggg ...
File imgact_elf.c Status: Locally Modified
I think the script's output is easier to read.
[ Hmmm, but you do incidentally bring up a point: it's better to parse
the output of "cvs status -R", instead of the ugly way used by the
script. I've attached a newer, faster version. Instead of taking
around 3 minutes to list the status below /usr/src/sys, this new
version takes around 1 minute. I've also applied Anton's fix. ]
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
#! /usr/bin/perl
###
#
# File: cvsinfo
# RCS: $Header: $
# Description: List CVS files in the current directory and below that are
# not up-to-date. These files are typically those which have
# been modified or need updating.
#
# This is a new, rewritten, version, thanks to feedback from
# Anton Berezin [EMAIL PROTECTED] and
# Oliver Fromme [EMAIL PROTECTED].
#
# Usage:
#
# cvsinfo [-a] [-l]
#
# Options:
#
# -a Show status of all files, and not just those which
# are not up-to-date.
#
# -l Show status of files in the current directory only.
# Do not recurse into subdirectories.
#
# Author: Darryl Okahata
# Created: Thu Sep 23 14:32:34 1999
# Modified: Thu Sep 23 14:45:03 1999 (Darryl Okahata) [EMAIL PROTECTED]
# Language: CPerl
# Package: N/A
# Status: Experimental
#
# (C) Copyright 1999, Hewlett-Packard, all rights reserved.
#
###
###
require 'getopts.pl';
Getopts('al');
$all_status = 1 if ($opt_a);
# Explicitly specify options, just in case the user has overridden them in
# ~/.cvsrc.
if ($opt_l) {
$recursive = "-l";
} else {
$recursive = "-R";
}
$dir = ".";
open(IN, "cvs status $recursive 21 |") || die "$!";
while(IN) {
if (/^cvs\s+server:\s+Examining\s+([^\s].*)$/) {
$dir = $1;
} elsif (/^File:\s+(?:no\s+file\s+)?([^\s]+)\s+Status:\s+(.+)$/i){
$file = $1;
$status = $2;
if ($all_status || $status ne 'Up-to-date') {
if ($status eq 'Needs Patch') {
$status = 'Needs Updating';
}
printf("%-50s %s\n", ($dir eq '.') ? $file : "$dir/$file",
$status);
if ($status =~ /Locally Modified/) {
push(@update_files, $file);
}
}
} elsif (/\[status\s+aborted\]/) {
die "$_\n";
}
}
Re: [re]writable cdrom drive
Matthew Dillon [EMAIL PROTECTED] wrote: Finally, when you pipe mkisofs to cdrecord directly it is possible to fall behind enough that an error may occur. The CD writer needs a continuous stream. There are two solution to this if it occurs: First, write at a slower rate (speed=1 or speed=2 rather then the default 4), or you need to mkisofs to an image file and then cdrecord from the image file. Another possibility, if you have the RAM, is to use the team(1) program (it's in the ports) to buffer the data as it goes to the burner. You basically put it into the pipeline between mkisofs and cdrecord, and it buffers up to 5MB in memory (default, adjustable). Of course, you've got to have enough RAM to not go into swap during the operation. It's a very nice program, and I've been told that, with enough memory (32-64MB), you can be running X11 and compiling programs while the CD is burning (this is with a 2X burner, though). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, 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: How to upgrade from 3.3 to 4 - Clarification please!
Jag [EMAIL PROTECTED] wrote:
Alexander Langer wrote:
Yes. Probably you've not built/booted a -current kernel before you build wo
rld.
Do you mean that I should build a new kernel *before* I do buildworld?
Is that possible?
Yes and yes.
Some clarification would be great. I've looked at the FreeBSD Diary
about staying current and the checking the handbook, but can't get this
to work... help?
If you try to use -current, the handbook (unfortunately) and any
web site (such as FreeBSD diary) are likely to be of little help (and,
in this case, are misleading), due the constantly-changing nature of
-current. As others have said, in numerous postings since seemingly
time immemorial, anyone who wants to use -current must also follow the
-current mailing list (and preferably others). At the very least (if
you've just joined -current), one should scan through the old -current
archives for at least a month or two back. *THOROUGHLY reading
/usr/src/UPDATING is also a must.
Yes, this does appear to be a lot of work, but, if you do this, you
get to find out about problems like "you must first build a kernel" (and
also the method for doing so). Also, you may run into other problems.
You'll find out about any if you read -current.
Also note that -current is not guaranteed to work. As -current is
used for developing new features and additions, it can be buggy, and may
completely crash and burn at times. Use it at your own risk.
--
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
