Re: Unable to mount ext2fs partition
Hi Rahul, The mount capability has to be included as a kernel option in a custom build kernel. I forget exactly what it's called (I'm writing in another OS on the system, so I can't check it right now), but I think it's something like this: option EXT2FS Have you included that in your kernel build? /Paul Rahul Siddharthan wrote: Paul A. Mayer wrote: I had to install the e2fstools port before I could access my e2fs partitions after installing -current. Thereafter everything has been fine. No problems with the disk, etc. Hm, didn't know about this port.. but it still doesn't include a mount program, and I still can't mount the partition even after installing the port. I don't want to fsck it and risk screwing it up: it's a real linux system (ie, a dual-boot machine) and the linux continues to boot perfectly nicely. But here's what I get with an e2fsck -n : # e2fsck -n /dev/ad0s2 e2fsck 1.27 (8-Mar-2002) The filesystem size (according to the superblock) is 714892 blocks The physical size of the device is 0 blocks Either the superblock or the partition table is likely to be corrupt! Abort? no /dev/ad0s2: clean, 136602/357632 files, 456658/714892 blocks So what does that mean? Any way to fix it? The only thing that is a problem is if your e2fs partion(s) are mounted and your system crashes Not a problem for me (it's likely to be mounted read-only anyway, and I can always boot into linux to fix it if it's dirty) - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
On Sun, 5 Jan 2003, Paul A. Mayer wrote: Thanks for this info. It's way beyond my technical understanding (which is truely minimal!), but I think I get the idea. What would this look like as a series of commands? Or better yet, what's the right way to share data between FreeBSD -current/coming and linux in a dual boot situation? ... Which is the real objective, (not playing with e2fs! ;.-) Well, what I do in practice is only mount ext2fs partitions as needed (mostly ro), so that most crashes don't leave them dirty. This works well enough since I only need them occasionally. Booting Linux to run e2fsck is easiest. I used the ext2fs utilities mainly to run fs benchmarks starting with clean file systems. Booting Linux to run mke2fs and e2fsck for every stage is not so easy. Unfortunately my shell script for doing this hasn't been updated to work with non-block devices. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proper -current if_attach locking?
On Fri, 3 Jan 2003, Nate Lawson wrote: NLI was looking into some could sleep messages and found some bogus NLlocking in the attach routine of many drivers. Several init a mtx in NLtheir softc and then lock/unlock it in their attach routine. This, of NLcourse, does nothing to provide exclusive access to a device. I assume NLthere is going to be a global IF_LOCK or something to be used in attach NLroutines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd login
ryan beasley wrote: On Fri, Jan 03, 2003 at 02:54:57PM -0200, Daniel C. Sobral wrote: Alas, that *did* work. My first attempt (replying to another message) was done with wrong permissions. Question... it did not have this trouble before Dec 13, but Dec 30 it had (no worlds in between). The sshd_config I use is the standard one. So... why? Hm, no idea. Did you possibly change anything that'd stop the kernel from returning ICMP port unreachables to sshd, like packet filtering on lo0, or turning on blackhole(4), etc? Those are the first things that'd come to mind explaining the sudden delays as the local lookup attempts would've begun the instant you were using OpenSSH + privilege separation + chroot. Now that you mention it... This does coincide with me noticing I hadn't brought over the rc.sysctl I use on the other firewalls, which includes blackhole(4). Ok, mystery solved. Question, though... why is it querying the reverse if I specifically *told* it not to? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Uh-oh -- WHY am I suddenly thinking of a VENERABLE religious leader frolicking on a FORT LAUDERDALE weekend? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
On Sun, 5 Jan 2003, Nate Lawson wrote: On Mon, 6 Jan 2003, Bruce Evans wrote: - spec_print() is of low quality: it doesn't print the device name or number. - devfs_print() would be reachable but doesn't exist, so vprint() prints even lower quality output for devfs since there nothing prints an inode number either. I was the one who left vprint in a not-so-desirable state. I plan to fix it very soon if you can tell me what info should be printed at what layer. For instance, several fs's print the device but this is probably unnecessary since specfs could do this. Care to elaborate? You didn't break this :-). Printing \n\t before VOP_PRINT() in vprint() works poorly for printing the output in log files. It would be better to have everything on one line for grepping on the string in the vprint() call. ufs only prints the device of the file system. Most file systems need to do that for themself since even having a device for the file system is fs-dependent. OTOH, v_rdev is in the vnode and there are fs-independent ways to get its name[s], so it can be printed directly by vprint() However, I prefer to let lower layers handle it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_ssh broken in recent (as of yesterday) -current?
On Fri, 03 Jan 2003 03:19:28 +0100 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Alexander Leidinger [EMAIL PROTECTED] writes: Dag-Erling, any ideas? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/46628 Fixed a couple of minutes ago. Just tested with a world from yesterday: it doesn't segfault anymore, but there's no ssh-agent running. No messages in xdm-errors, .xsession-errors, XFree86.0.log or messages. Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Jan 6 03:02:53 PST 2003 -- Kernel build for GENERIC completed on Mon Jan 6 03:35:12 PST 2003 -- Kernel build for LINT started on Mon Jan 6 03:35:12 PST 2003 -- === vinum Makefile, line 4445: warning: duplicate script for target geom_bsd.o [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/security/mac_lomac/mac_lomac.c: In function `mac_lomac_ass [...] /h/des/src/sys/security/mac_lomac/mac_lomac.c:1070: warning: passing arg [...] /h/des/src/sys/security/mac_lomac/mac_lomac.c:1081: warning: int format, [...] *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HOWTO: Basic-block profiling on -current.
I have committed the bits needed to use GCC's basicblock profiling on -current. Make sure to recompile the kernbb(8) program first. Here's an simple example how to profile a single file (vfs_bio.c): cd /sys/i386/conf config YOURKERNEL cd ../compile/YOURKERNEL make depend make all rm vfs_bio.o make vfs_bio.o DEBUG=--test-coverage --profile-arcs make all make install reboot # run your test. kernbb cd /sys/i386/compile/YOURKERNEL gcov vfs_bio.c # examine vfs_bio.c.gcov If you want to profile multiple files, you just give them all the same treatment as vfs_bio. It's perfectly possible to profile the entire kernel if you want to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 01:33:14AM -0800, David O'Brien wrote: Agreed. I'd love to hear from fanf what the changes are to unifdef that causes this change in exit code. I accidentally cocked up the exit codes in my first major revision of unifdef. It so happens that a few days later markm ripped out the Perl and Tcl support from vi, which meant that it started using unifdef in its build. The incorrect exit value happened to be 0 instead of 1 so things were happy until I restored the odd documented behaviour in my second major revision. Apologies for the disruption. I did check the uses of unifdef in the tree (including vi and telnet), but I didn't realise that ignored errors would cause problems. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: WIND: VARIABLE OR NORTHEAST 2 OR 3. FAIR. GOOD. MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proper -current if_attach locking?
On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: On Fri, 3 Jan 2003, Nate Lawson wrote: NLI was looking into some could sleep messages and found some bogus NLlocking in the attach routine of many drivers. Several init a mtx in NLtheir softc and then lock/unlock it in their attach routine. This, of NLcourse, does nothing to provide exclusive access to a device. I assume NLthere is going to be a global IF_LOCK or something to be used in attach NLroutines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. Only using lock in softc can't assure its exclusive access because there are some cases of changing some values in ifnet struct outside of device driver routines. Most of the NIC drivers don't have its own locks for now, and using both IFNET_*LOCK() and its own softc lock can't make everything in sync. There should be two use of locks IMO: one or more per-device locks in driver softc for manipulating per-device private data protection, and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Maybe these locks should be adaptive or spin And IFNET_*LOCK() should remain for adding/removing ifnet struct to the global ifnet whose type is ifnethead. In case of ifqueue, it should not need to acquire its ifnet lock because ifqueue has its own mutex. -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getpwnam_r missing
Hi, While trying to build the latest Qt (3.1.1) from original sources, it fails because it cannot find getpwnam_r, which we appear to be missing in -CURRENT at the moment, marked: /* * XXX missing getpwnam_r() and getpwuid_r(). */ Qt tries to use this conditionally, using: #if defined(QT_THREAD_SUPPORT) defined(_POSIX_THREAD_SAFE_FUNCTIONS) So, QT_THREAD_SUPPORT is defined (because I enabled -thread in their configure), and -CURRENT must be defining _POSIX_THREAD_SAFE_FUNCTIONS otherwise the code would not attempt to build that section otherwise. Are there plans to implement getpwnam_r (and getpwduid_d) before 5.0 release? If so, I'll hold back on bugging Trolltech about a fix, otherwise I'll ask them for a patch in future releases to take the missing function into account. Regards, Andy -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
--
Kernel build for LINT started on Mon Jan 6 03:35:12 PST 2003
--
=== vinum
Makefile, line 4445: warning: duplicate script for target geom_bsd.o [...]
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...]
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...]
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...]
cc1: warnings being treated as errors
/h/des/src/sys/security/mac_lomac/mac_lomac.c: In function `mac_lomac_ass [...]
/h/des/src/sys/security/mac_lomac/mac_lomac.c:1070: warning: passing arg [...]
/h/des/src/sys/security/mac_lomac/mac_lomac.c:1081: warning: int format, [...]
*** Error code 1
These new truncated lines only make problems harder to solve.
Anyway, the problem is the 5th argument to vn_extattr_get() should be
an int *, but it's passing a size_t *. It looks like most consumers
of vn_extattr_get() would prefer a size_t *, so maybe the interface
should be changed.
This patch should resolve the problem without changing
vn_extattr_get()'s interface:
%%%
Index: mac_lomac.c
===
RCS file: /work/repo/src/sys/security/mac_lomac/mac_lomac.c,v
retrieving revision 1.6
diff -u -r1.6 mac_lomac.c
--- mac_lomac.c 10 Dec 2002 16:20:33 - 1.6
+++ mac_lomac.c 6 Jan 2003 15:53:02 -
@@ -49,6 +49,7 @@
#include sys/malloc.h
#include sys/mount.h
#include sys/proc.h
+#include sys/stdint.h
#include sys/systm.h
#include sys/sysproto.h
#include sys/sysent.h
@@ -1067,7 +1068,7 @@
bzero(temp, buflen);
error = vn_extattr_get(vp, IO_NODELOCKED, MAC_LOMAC_EXTATTR_NAMESPACE,
- MAC_LOMAC_EXTATTR_NAME, buflen, (char *)temp, curthread);
+ MAC_LOMAC_EXTATTR_NAME, (int *)buflen, (char *)temp, curthread);
if (error == ENOATTR || error == EOPNOTSUPP) {
/* Fall back to the fslabel. */
mac_lomac_copy_single(source, dest);
@@ -1077,8 +1078,9 @@
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
- printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
- buflen);
+ printf(
+ mac_lomac_associate_vnode_extattr: bad size %ju\n,
+ (uintmax_t)buflen);
return (EPERM);
}
bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: pam_ssh broken in recent (as of yesterday) -current?
Alexander Leidinger [EMAIL PROTECTED] writes: Just tested with a world from yesterday: it doesn't segfault anymore, but there's no ssh-agent running. Harrumph. Did you try reverting pam_ssh.c? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Mon, 6 Jan 2003, Mike Barcroft wrote:
These new truncated lines only make problems harder to solve.
Anyway, the problem is the 5th argument to vn_extattr_get() should be an
int *, but it's passing a size_t *. It looks like most consumers of
vn_extattr_get() would prefer a size_t *, so maybe the interface should
be changed.
I think the problem originated because uio_resid is 'int', but iovec's
len is size_t. I agree the right answer is to use size_t as the argument
to vn_extattr_{get,set}(). Will that cause type problems with the resid
field, however?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Mike Barcroft [EMAIL PROTECTED] writes:
@@ -1077,8 +1078,9 @@
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
- printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
- buflen);
+ printf(
+ mac_lomac_associate_vnode_extattr: bad size %ju\n,
+ (uintmax_t)buflen);
return (EPERM);
}
bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
Oops, I forgot we have %z in printf(9) now. That would obviously be
better.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Gerhard Sittig [EMAIL PROTECTED] wrote: Although the above case is special from what I learnt in another message in this thread (I managed to delete it after seeing it so I cannot quote it here). ISTR that the non zero exit status comes from a tool with the following convention: 0 is absolutely OK, 1 is not perfect but still plausible enough to get accepted most of the time, and 2 is a real error, never OK. I believe that unifdef got its exit status values from diff. (The use of the word trouble in the DIAGNOSTICS section is indicative.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: VARIABLE 1 OR 2 LOCALLY 3 OR 4. ISOLATED WINTRY SHOWERS. MAINLY GOOD. MODERATE DECAYING SLIGHT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HOWTO: Basic-block profiling on -current.
On Mon, Jan 06, 2003 at 02:28:52PM +0100, Poul-Henning Kamp wrote: I have committed the bits needed to use GCC's basicblock profiling on -current. Make sure to recompile the kernbb(8) program first. Here's an simple example how to profile a single file (vfs_bio.c): cd /sys/i386/conf config YOURKERNEL cd ../compile/YOURKERNEL make depend make all rm vfs_bio.o make vfs_bio.o DEBUG=--test-coverage --profile-arcs make all make install reboot # run your test. kernbb cd /sys/i386/compile/YOURKERNEL gcov vfs_bio.c # examine vfs_bio.c.gcov If you want to profile multiple files, you just give them all the same treatment as vfs_bio. It's perfectly possible to profile the entire kernel if you want to. Hey Poul-Henning! Thanks! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Added volume stepping to mixer
Last week I modified the mixer to support volume stepping. Having a
keyboard with volume control on it, it has come in very handy to be able
to use the mixer to increase/decrease the volume. I submitted the
changes to send-pr and have an open ticket. For those that are
interested, Im including the diff against mixer.c v1.17.
http://www.freebsd.org/cgi/query-pr.cgi?pr=46679
Sample usage:
Increasing:
[daren@wee mixer]$mixer -i 5:5
Increasing the mixer vol from 40:40 to 45:45.
[daren@wee mixer]$
Decreasing:
[daren@wee mixer]$mixer -d vol 10
Decreasing the mixer vol from 45:45 to 35:35.
[daren@wee mixer]$
*** mixer_new.c Wed Jan 1 13:26:23 2003
--- mixer.c Wed Jan 1 13:32:41 2003
***
*** 3,8
--- 3,9
*
* updated 1/1/93 to add stereo, level query, broken
* devmask kludge - [EMAIL PROTECTED]
+ * updated 1/1/03 to add volume stepping - [EMAIL PROTECTED]
*
* (C) Craig Metz and Hannu Savolainen 1993.
*
***
*** 13,19
#ifndef lint
static const char rcsid[] =
! $FreeBSD: src/usr.sbin/mixer/mixer.c,v 1.17 2002/12/30 04:23:08 jmallett Exp $;
#endif /* not lint */
#include err.h
--- 14,20
#ifndef lint
static const char rcsid[] =
! $FreeBSD: src/usr.sbin/mixer/mixer.c,v 1.11.2.6 2001/07/30 10:22:58 dd Exp $;
#endif /* not lint */
#include err.h
***
*** 35,41
{
int i, n;
! printf(usage: mixer [-f device] [-s] [[dev [voll[:volr]] | recsrc | {^|+|-|=}rec recdev] ... ]\n);
printf( devices: );
for (i = 0, n = 0; i SOUND_MIXER_NRDEVICES; i++)
if ((1 i) devmask) {
--- 36,42
{
int i, n;
! printf(usage: mixer [-f device] [-s] [-i|-d] [[dev [voll[:volr]] | recsrc | {^|+|-|=}rec recdev] ... ]\n);
printf( devices: );
for (i = 0, n = 0; i SOUND_MIXER_NRDEVICES; i++)
if ((1 i) devmask) {
***
*** 91,96
--- 92,99
int devmask = 0, recmask = 0, recsrc = 0, orecsrc;
int dusage = 0, drecsrc = 0, shortflag = 0;
int l = 0, r = 0, t = 0;
+ bool volumeInc = false;
+ bool volumeDec = false;
char ch;
char *name;
***
*** 102,108
else if (!strcmp(argv[0], mixer3))
name = strdup(/dev/mixer2);
! while ((ch = getopt(argc, argv, f:s)) != -1)
switch (ch) {
case 'f':
name = strdup(optarg);
--- 105,111
else if (!strcmp(argv[0], mixer3))
name = strdup(/dev/mixer2);
! while ((ch = getopt(argc, argv, f:sid)) != -1)
switch (ch) {
case 'f':
name = strdup(optarg);
***
*** 110,115
--- 113,124
case 's':
shortflag = 1;
break;
+ case 'i':
+ volumeInc = true;
+ break;
+ case 'd':
+ volumeDec = true;
+ break;
default:
dusage = 1;
}
***
*** 181,195
continue;
}
if ((t = sscanf(*argv, %d:%d, l, r)) 0) {
dev = 0;
}
else if((dev = res_name(*argv, devmask)) == -1) {
warnx(unknown device: %s, *argv);
dusage = 1;
break;
}
!
switch(argc 1 ? sscanf(argv[1], %d:%d, l, r) : t) {
case 0:
if (ioctl(baz, MIXER_READ(dev),bar)== -1) {
--- 190,206
continue;
}
+ // Check if device is specified
if ((t = sscanf(*argv, %d:%d, l, r)) 0) {
dev = 0;
}
+ // read and verify the device
else if((dev = res_name(*argv, devmask)) == -1) {
warnx(unknown device: %s, *argv);
dusage = 1;
break;
}
! // Read in the volume changes
switch(argc 1 ? sscanf(argv[1], %d:%d, l, r) : t) {
case 0:
if (ioctl(baz, MIXER_READ(dev),bar)== -1) {
***
*** 208,213
--- 219,259
case 1:
r = l;
case 2:
+
+ // Read the current volum
+ if(ioctl(baz, MIXER_READ(dev), bar) == -1)
+ {
+ warn(MIXER_READ);
+ continue;
+ }
+
+ int leftVolume = bar 0x7f;
+ int rightVolume = (bar 8) 0x7f;
+
+ if(volumeInc || volumeDec)
+ {
+ // Read the current volume for stepping
+ if(ioctl(baz, MIXER_READ(dev), bar) == -1)
+ {
+ warn(MIXER_READ);
+ continue;
+ }
+
+ int leftVolume = bar 0x7f;
+ int rightVolume = (bar 8) 0x7f;
+
+ if(volumeInc)
+ {
+ l = leftVolume +l;
+ r = rightVolume +r;
+ }
+ else
+ {
+ l = leftVolume -l;
+ r = rightVolume -r;
+ }
+ }
+
if (l 0)
l = 0;
else if (l 100)
***
*** 217,230
else if (r 100)
r = 100;
! if (ioctl(baz, MIXER_READ(dev),bar)== -1) {
! warn(MIXER_READ);
! argc--; argv++;
! continue;
}
!
! printf(Setting the mixer %s from %d:%d to %d:%d.\n,
! names[dev], bar 0x7f, (bar 8) 0x7f, l, r);
l |= r 8;
if (ioctl(baz, MIXER_WRITE(dev), l) == -1)
--- 263,278
else if (r 100)
r = 100;
! if(volumeInc)
! {
! printf(Increasing the mixer %s from %d:%d to %d:%d.\n,
Re: lock order reversal
On 2003/01/05-00:25:17 leafy wrote: lock order reversal Jan 5 00:19:15 leafy kernel: 1st 0xc26b05c0 process lock (process lock) @/usr/src/sys/kern/kern_descrip.c:2099 Jan 5 00:19:15 leafy kernel: 2nd 0xc2667e34 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2106 The kernel is only about 40 mins old. /me too. updated world + kernel sometime yesterday (2003/01/05) and was about updating linux_base when a kernel panic occured. # portupgrade linux_base ... panic: lockmgr: pid 3171, not exclusive lock holder (sorry, i don't have more details :( after rebooting i got this on bootup: Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted lock order reversal 1st 0xc340f068 process lock (process lock) @ /usr/src/sys/kern/kern_descrip.c:2099 2nd 0xc33e9634 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2106 i got another LOR when starting up Quake2 (but only once every boot): acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 msg49774/pgp0.pgp Description: PGP signature
mirrored root fs?
I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
In message [EMAIL PROTECTED], Nate Lawson wri tes: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? The best way to do this is to get a cheap ATA raid controller (I use a promise). That way the bios can load your OS if a mirror side drops. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, 6 Jan 2003, Soeren Schmidt wrote: It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) Interesting. To support booting, I'd probably need to hack /etc/rc to enable the mirror before mounting fs r/w. Also, does it matter which of the /dev/ad* entries are used as the mount device? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getpwnam_r missing
On Mon, 6 Jan 2003 17:22:58 +0200, Andy Fawcett [EMAIL PROTECTED] said: #if defined(QT_THREAD_SUPPORT) defined(_POSIX_THREAD_SAFE_FUNCTIONS) This conditional is erroneous, so you should definitely bug Troll Tech. It should instead read: #if defined(QT_THREAD_SUPPORT) _POSIX_THREAD_SAFE_FUNCTIONS - 0 0 (We really should figure out how to implement the _r functions, because a POSIX.1-2001 system with threads is supposed to have them.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getpwnam_r missing
On Monday 06 January 2003 20:55, Garrett Wollman wrote: On Mon, 6 Jan 2003 17:22:58 +0200, Andy Fawcett [EMAIL PROTECTED] said: #if defined(QT_THREAD_SUPPORT) defined(_POSIX_THREAD_SAFE_FUNCTIONS) This conditional is erroneous, so you should definitely bug Troll Tech. It should instead read: #if defined(QT_THREAD_SUPPORT) _POSIX_THREAD_SAFE_FUNCTIONS - 0 0 (We really should figure out how to implement the _r functions, because a POSIX.1-2001 system with threads is supposed to have them.) Thanks for the response, I'll forward this onto Trolltech. Cheers, Andy -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Added volume stepping to mixer
* De: Daren Desjardins [EMAIL PROTECTED] [ Data: 2003-01-06 ]
[ Subjecte: Added volume stepping to mixer ]
Last week I modified the mixer to support volume stepping. Having a
keyboard with volume control on it, it has come in very handy to be able
to use the mixer to increase/decrease the volume. I submitted the
changes to send-pr and have an open ticket. For those that are
interested, Im including the diff against mixer.c v1.17.
OK, I have some critiques, which if you do them (they were in my TODO
anyway) I'll be glad to commit:
Instead of two bool's use one 'int', if it is 0, then act as
we do now. If it is -1, we're decreasing, if it is +1, we're
increasing. Thus you do something like:
if (direction != 0)
newvol = oldvol + (newvol * amount);
/* Set newval */
Also, don't do what you do with printf. What should be done, just before
setting newval (I've already done this locally, but you should as part
of what you're doing anyway) is more like this:
if (newval oldval)
printf(Decreasing level to blah blah);
else if (newval oldval)
printf(Increasing level to blah blah);
else {
printf(No change in level at blah);
/* Get on with our lives */
}
/* Set newval */
Let me know.
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: On Mon, Jan 06, 2003 at 07:29:51PM +0100, Soeren Schmidt wrote: It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) Using non-raid controllers for building raid-arrays would be a cool feature if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, Jan 06, 2003 at 08:08:09PM +0100, Soeren Schmidt wrote: It seems [EMAIL PROTECTED] wrote: On Mon, Jan 06, 2003 at 07:29:51PM +0100, Soeren Schmidt wrote: It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) Using non-raid controllers for building raid-arrays would be a cool feature if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... Well, and how would one rebuild the array after swaping the drive from the secondary channel to the primary and hooking up a replacement drive to the secondary channel or if one doesn't want to boot from the array at all ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, Jan 06, 2003 at 10:27:21AM -0800, Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? I've moved ccdconfig and ccd.conf to /boot and made /boot its own FS, wiht the intention of doing what you want to do. I never got around to testing this setup. :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Added volume stepping to mixer
Changes made, also added a couple lines of docs here and their and
changed the int variables to more meaningful. Lemme know if their is
anything else you need.
Daren Desjardins
On Mon, 2003-01-06 at 13:59, Juli Mallett wrote:
* De: Daren Desjardins [EMAIL PROTECTED] [ Data: 2003-01-06 ]
[ Subjecte: Added volume stepping to mixer ]
Last week I modified the mixer to support volume stepping. Having a
keyboard with volume control on it, it has come in very handy to be able
to use the mixer to increase/decrease the volume. I submitted the
changes to send-pr and have an open ticket. For those that are
interested, Im including the diff against mixer.c v1.17.
OK, I have some critiques, which if you do them (they were in my TODO
anyway) I'll be glad to commit:
Instead of two bool's use one 'int', if it is 0, then act as
we do now. If it is -1, we're decreasing, if it is +1, we're
increasing. Thus you do something like:
if (direction != 0)
newvol = oldvol + (newvol * amount);
/* Set newval */
Also, don't do what you do with printf. What should be done, just before
setting newval (I've already done this locally, but you should as part
of what you're doing anyway) is more like this:
if (newval oldval)
printf(Decreasing level to blah blah);
else if (newval oldval)
printf(Increasing level to blah blah);
else {
printf(No change in level at blah);
/* Get on with our lives */
}
/* Set newval */
Let me know.
Thanx,
juli.
*** mixer_new.c Thu Jan 2 14:58:34 2003
--- mixer.c Mon Jan 6 14:31:58 2003
***
*** 3,8
--- 3,9
*
* updated 1/1/93 to add stereo, level query, broken
* devmask kludge - [EMAIL PROTECTED]
+ * updated 6/1/03 to add volume stepping - [EMAIL PROTECTED]
*
* (C) Craig Metz and Hannu Savolainen 1993.
*
***
*** 13,19
#ifndef lint
static const char rcsid[] =
! $FreeBSD: src/usr.sbin/mixer/mixer.c,v 1.17 2002/12/30 04:23:08 jmallett Exp $;
#endif /* not lint */
#include err.h
--- 14,20
#ifndef lint
static const char rcsid[] =
! $FreeBSD: src/usr.sbin/mixer/mixer.c,v 1.11.2.6 2001/07/30 10:22:58 dd Exp $;
#endif /* not lint */
#include err.h
***
*** 35,41
{
int i, n;
! printf(usage: mixer [-f device] [-s] [[dev [voll[:volr]] | recsrc | {^|+|-|=}rec recdev] ... ]\n);
printf( devices: );
for (i = 0, n = 0; i SOUND_MIXER_NRDEVICES; i++)
if ((1 i) devmask) {
--- 36,42
{
int i, n;
! printf(usage: mixer [-f device] [-s] [-i|-d] [[dev [voll[:volr]] | recsrc | {^|+|-|=}rec recdev] ... ]\n);
printf( devices: );
for (i = 0, n = 0; i SOUND_MIXER_NRDEVICES; i++)
if ((1 i) devmask) {
***
*** 90,96
int foo, bar, baz, dev;
int devmask = 0, recmask = 0, recsrc = 0, orecsrc;
int dusage = 0, drecsrc = 0, shortflag = 0;
! int l = 0, r = 0, t = 0;
char ch;
char *name;
--- 91,98
int foo, bar, baz, dev;
int devmask = 0, recmask = 0, recsrc = 0, orecsrc;
int dusage = 0, drecsrc = 0, shortflag = 0;
! int left = 0, right = 0, temp = 0;
! int direction = 0; // volume stepping indicator
char ch;
char *name;
***
*** 102,115
else if (!strcmp(argv[0], mixer3))
name = strdup(/dev/mixer2);
! while ((ch = getopt(argc, argv, f:s)) != -1)
switch (ch) {
case 'f':
name = strdup(optarg);
break;
case 's':
shortflag = 1;
break;
default:
dusage = 1;
}
--- 104,126
else if (!strcmp(argv[0], mixer3))
name = strdup(/dev/mixer2);
! while ((ch = getopt(argc, argv, f:sid)) != -1)
switch (ch) {
case 'f':
+ // user specifed device
name = strdup(optarg);
break;
case 's':
+ // display levels in short form
shortflag = 1;
break;
+ case 'i':
+ // increase volume flag present
+ direction = 1;
+ break;
+ case 'd':
+ direction = -1;
+ break;
default:
dusage = 1;
}
***
*** 181,196
continue;
}
! if ((t = sscanf(*argv, %d:%d, l, r)) 0) {
dev = 0;
}
else if((dev = res_name(*argv, devmask)) == -1) {
warnx(unknown device: %s, *argv);
dusage = 1;
break;
}
!
! switch(argc 1 ? sscanf(argv[1], %d:%d, l, r) : t) {
case 0:
if (ioctl(baz, MIXER_READ(dev),bar)== -1) {
warn(MIXER_READ);
--- 192,209
continue;
}
! // Check if device is specified
! if ((temp = sscanf(*argv, %d:%d, left, right)) 0) {
dev = 0;
}
+ // read and verify the device
else if((dev = res_name(*argv, devmask)) == -1) {
warnx(unknown device: %s, *argv);
dusage = 1;
break;
}
! // Read in the volume changes
! switch(argc 1 ? sscanf(argv[1], %d:%d, left, right) : temp) {
case 0:
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... Well, and how would one rebuild the array after swaping the drive from the secondary channel to the primary and hooking up a replacement drive to the secondary channel or if one doesn't want to boot from the array at all ? You can boot off the half-mirror and the rebuild with atacontrol once the system is up (its done in the background so you can continue to run but access speed will be degraded). If you want to not use the array you just delete it with atatcontrol and the disk will be seen as a normal ATA drive again. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, Jan 06, 2003 at 08:36:20PM +0100, Soeren Schmidt wrote: It seems [EMAIL PROTECTED] wrote: if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... Well, and how would one rebuild the array after swaping the drive from the secondary channel to the primary and hooking up a replacement drive to the secondary channel or if one doesn't want to boot from the array at all ? You can boot off the half-mirror and the rebuild with atacontrol once the system is up (its done in the background so you can continue to run but access speed will be degraded). And how is this to be done ? :) `atacontrol rebuild ar0` didn't work here (not configured IIRC) with a raid1-array on a non-raid controller and atacontrol(8) also states: rebuild Rebuild a RAID1 array on a RAID capable ATA controller. If you want to not use the array you just delete it with atatcontrol and the disk will be seen as a normal ATA drive again. I recovered by copying the content of the half-mirror to another location, unmounting ar0, `atacontrol create ar0 ...` after replacing the broken drive, ..., and finally copying the data back to the array. A simpler way would be fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, 6 Jan 2003, David O'Brien wrote: On Mon, Jan 06, 2003 at 10:27:21AM -0800, Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? I've moved ccdconfig and ccd.conf to /boot and made /boot its own FS, wiht the intention of doing what you want to do. I never got around to testing this setup. :-( That is suboptimal for me since I'd still have to manually mirror the /boot partition (dd) every time I updated the kernel. Not a huge problem but not quite what I want to do. The way I tested this was take a second drive, disklabeled it accordingly: disklabel ad2s1 to create an 'a' partition ccdconfig ccd0 128 none /dev/ad2s1a disklabel -w ccd0c auto newfs /dev/ccd0c cp / to ccd0c Thus there's a one-drive ccd partition. I added boot blocks and attempted to boot it but got a not ufs error. The ccd partition format is different from a normal ufs partition. My question was how different? and how much work to have the boot blocks find the right offset to the fs? ccdconfig is on /sbin so post kernel load should have worked fine. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Jan 6 10:22:15 PST 2003 -- Kernel build for GENERIC completed on Mon Jan 6 11:36:00 PST 2003 -- Kernel build for LINT started on Mon Jan 6 11:36:00 PST 2003 -- === vesa Makefile, line 5396: warning: duplicate script for target geom_bsd.o [...] Makefile, line 5399: warning: duplicate script for target geom_mbr.o [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: ` [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_T [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: ` [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_ [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_ [...] /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_ [...] /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_TH [...] /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `Acp [...] /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cas [...] /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: ` [...] /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_ [...] /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_T [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_T [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_ [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: c [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: c [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `A [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: c [...] /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: c [...] /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MO [...] /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_M [...] /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acp [...] /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acp [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment disca [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1254: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1266: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ie_readframe': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1312: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `iestart': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1412: warning: passing arg 2 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1425: warning: cast discards q [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `check_ie_present': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1479: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1488: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1491: warning: passing arg 1 o [...] /local0/scratch/des/src/sys/dev/ie/if_ie.c:1516: warning: passing arg 1 o [...]
Cordless Keyboard + Mouse
Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. Daren Desjardins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
It seems Daren Desjardins wrote: Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. Sure, I use a logitech cordless keyboard and wheel mouse, not sure of the exact model though, works like a charm... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
Hello, I recently attempted to upgrade on of my servers from 4.7 STABLE to 5.0 RC2 using the Upgrade facility of sysinstall. After choosing all the options I needed, the upgrade proceeded through its fsck and started unpacking off the CD. This is where things go sour. About 20% of the way through the first round of Extracting into /, I got a page fault/kernel panic and a reboot. Unfortunately, no other useful information was presented. This problem is limited to 5.0 as I am able to recover a usable machine by installing 4.7 Release using the same method. Has anyone else expperienced anything similar? If you can tell me how to get more information about this crash, I would be happy to try. For now it is just frustrating. Hardware config FYI: Asus CUV4x-D 2X PIII-600 coppermine. 1 ata-100 drive. There is also a windows partition on this disk. LSIlogic MegaRAID 428 ( currently unused ). Should you require further info, please do not hesitate to contact me. -Wade Klaver To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
At 11:54 AM -0800 1/6/03, Nate Lawson wrote: On Mon, 6 Jan 2003, David O'Brien wrote: On Mon, Jan 06, 2003 at 10:27:21AM -0800, Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? I've moved ccdconfig and ccd.conf to /boot and made /boot its own FS, with the intention of doing what you want to do. I never got around to testing this setup. :-( That is suboptimal for me since I'd still have to manually mirror the /boot partition (dd) every time I updated the kernel. Not a huge problem but not quite what I want to do. That is not necessarily a problem. I've meant to setup something where I would create a snapshot of the root partition, and then duplicate data from that snapshot to a different partition. My thinking was that I could set this up as a cron job, and back up the root partition every night. Probably do a 'dd' or an 'rsync', followed by a step to change /etc/fstab on the destination so it would be right for the destination. (create a snapshot in the UFS/softupdates sense of the phrase) This wouldn't be as up-to-date as official mirroring, but then my root partition doesn't change all that much, so a daily snapshot should be fine. Of course, I've never actually gotten around to implementing this, but my guess is that it's very doable and the result would be very flexible. (no special hardware, no special software, no special configs) About all I've done is that I always create a spare partition that's the same size as my root partition, and occasionally I test a backup to it... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Mon, 6 Jan 2003, Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? I gave this the old college try a while ago, here's what I found out about the different methods: 1) CCD -- no info I never really tried CCD as there seem to be much better options with atacontrol, vinum, and RAIDFrame. 2) 3Ware Escalade Cards Advantanges: They work like a charm and look just like a SCSI controller Disadvantages: Extra hardware. Expense. Proprietary. 3) atacontrol Probably your best choice right now if you have a real RAID controller on your motherboard. The BIOS takes care of most of the nasty booting details. If you don't have a real RAID controller on the motherboard, stop now. Rebuilds don't work if you don't have a real RAID controller. You can recover, but it requires some dancing with dd (search the archives). Advantages: BIOS handles bootup issues. Very little required from OS Disadvantages: Hardware required. Proprietary. Will not rebuild a broken array without hardware RAID The next two methods require only FreeBSD. They both share the same problem: you have to boot a kernel from somewhere non-RAID and then the kernel can autodetect RAID configurations as it boots. Autodetection of the RAID systems before mounting root is the key here. If something needs to mount / before it can configure, you can't mirror / since FreeBSD has no method for remounting /. Perhaps this has changed with the new GEOM code, somebody might want to ask Poul about this. 4) vinum ( http://www.vinumvm.org/ ) The older of the two general RAID systems for FreeBSD. vinum *can* be fairly complex as it was meant for doing more than just RAID (it is meant to be something akin to Veritas for full logical volume management). However, standard RAID 1 is a fairly simple configuration. At one point, I somehow managed to get vinum to autodetect /, but that was more than a year ago on -stable, I haven't tried -current. Advantages: No extra hardware required (beyond the disks themseleves). All code contained in FreeBSD (nothing proprietary) Does more than just RAID Disadvantages: Kernel required to be booted from somewhere non-RAID Unknown status with respect to SMP and GEOM 5) RAIDFrame ( http://people.freebsd.org/~scottl/rf/ ) RAIDFrame is the newer kid on the block in FreeBSD RAID. It is a port of the RAIDFrame code from NetBSD (which is itself a port of the RAIDFrame code from CMU, IIRC). Back in -stable within the last year, I managed to get RAIDFrame to autodetect on boot. Unknown in -current. Advantages: No extra hardware required (beyond the disks themseleves). All code contained in FreeBSD (nothing proprietary) Disadvantages: Kernel required to be booted from somewhere non-RAID Unknown status with respect to SMP and GEOM (although this stuff is on the radar screen) The following is not a true RAID solution, but it seems to be popular: 6) root partition pseudo-mirror using dd with RAID on other partitions ( http://ezine.daemonnews.org/200111/vinum.html ) This is what most people who use FreeBSD kernel-based RAID mirroring currently do. CAUTION: This does *not* have the reliability advantages of true RAID 1 mirroring. If the disk containing your root filesystem goes down, so does your system. This may not matter to you, but it is something you should be aware of. Advantages: No extra hardware required (beyond the disks themseleves). All code contained in FreeBSD (nothing proprietary) Kernel booted from pseudo-mirror Disadvantages: Root partition disk crash takes out system Manual copying of root partition required Mirroring with dd may fail on open files As always, these opinions are my own. Your mileage may vary. All disclaimers apply. Yadda, yadda, yadda, etc., etc. ;) Hope this helps, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proper -current if_attach locking?
On Mon, 6 Jan 2003, Kyunghwan Kim wrote: On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: On Fri, 3 Jan 2003, Nate Lawson wrote: NLI was looking into some could sleep messages and found some bogus NLlocking in the attach routine of many drivers. Several init a mtx in NLtheir softc and then lock/unlock it in their attach routine. This, of NLcourse, does nothing to provide exclusive access to a device. I assume NLthere is going to be a global IF_LOCK or something to be used in attach NLroutines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. Only using lock in softc can't assure its exclusive access because there are some cases of changing some values in ifnet struct outside of device driver routines. Most of the NIC drivers don't have its own locks for now, and using both IFNET_*LOCK() and its own softc lock can't make everything in sync. My point. There should be two use of locks IMO: one or more per-device locks in driver softc for manipulating per-device private data protection, and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Looking further into sys/net/if.c, it appears that the list of interfaces is protected by IFNET_WLOCK in if_attach(). I think it's safe to work under the following assumptions: 1. newbus will not call an attach routine twice for the same hw 2. ifnet routines take care of themselves 3. per-device locking is only necessary to provide exclusive access within a given driver instance. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_dc.c locking patch
Attached is a diff that fixes a could sleep problem where
ether_ifattach() does a malloc and dc(4) is holding a lock in its softc.
It uses a cleaner exit strategy with only one call to DC_UNLOCK and no
multiple return statements as well as fixing one place where error
wasn't set. If people are ok with it, I'll sweep other drivers that have
a similar problem.
-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 7 Jan 2003 00:36:30 -
@@ -2162,6 +2162,7 @@
mac = pci_get_ether(dev);
if (!mac) {
device_printf(dev, No station address in CIS!\n);
+ error = ENXIO;
goto fail;
}
bcopy(mac, eaddr, ETHER_ADDR_LEN);
@@ -2266,11 +2267,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 +2300,16 @@
}
#endif
- DC_UNLOCK(sc);
- return(0);
-
fail:
DC_UNLOCK(sc);
fail_nolock:
- mtx_destroy(sc-dc_mtx);
- return(error);
+ /* If no errors, call the MI attach routine. */
+ if (error == 0)
+ ether_ifattach(ifp, eaddr);
+ else
+ mtx_destroy(sc-dc_mtx);
+
+ return (error);
}
static int
Re: Cordless Keyboard + Mouse
Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I've got the older Logitech 'Natural' wireless keyboard + wireless mouse working fine. I've had it for almost 3 years now, and aside from having to change batteries every 4-6 months it's been rock solid. I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. I didn't have to do anything to get it to work for me. I plugged the mouse connector into the mouse slot, the keyboard into the keyboard slot, and all is well. Nate ps. I'm running -stable, though I doubt it matters much. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc.c locking patch
Nate Lawson wrote: Attached is a diff that fixes a could sleep problem where ether_ifattach() does a malloc and dc(4) is holding a lock in its softc. It uses a cleaner exit strategy with only one call to DC_UNLOCK and no multiple return statements as well as fixing one place where error wasn't set. If people are ok with it, I'll sweep other drivers that have a similar problem. Doing this would maybe be a bit premature. A lot of drivers have FOO_LOCK and FOO_UNLOCK macros set to nothing, because of similar problems you're trying to fix. Interface locking probably needs to be rethought. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
On Mon, 2003-01-06 at 19:58, Nate Williams wrote: Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I've got the older Logitech 'Natural' wireless keyboard + wireless mouse working fine. I've had it for almost 3 years now, and aside from having to change batteries every 4-6 months it's been rock solid. I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. I didn't have to do anything to get it to work for me. I plugged the mouse connector into the mouse slot, the keyboard into the keyboard slot, and all is well. My combo uses a single reciever for both devices, sounds like you have two? dmesg shows that both the mouse and kb were detected, mouse as ums0 and kb as ukb0. XFree is set to use /dev/sysmouse, but dies with no core pointer if I dont use the corded mouse. ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 Nate ps. I'm running -stable, though I doubt it matters much. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current/stable remote gdb interoperability
On Sun, 5 Jan 2003, ryan beasley wrote: For what it's worth, I've taken Nate's suggestion and backed down to 9600bps, and this problem hasn't occurred yet, so I'm assuming this is the fix. (The 4.7 machine has an ASUS P2B-D board, and the -CURRENT box is a recent Dell Dimension, so I don't *think* I'm using garbage serial hardware.) Though slow, I guess I can't complain if it works. :). Bruce was right in that sio is polled when in the debugger so interrupt speed shouldn't be a problem. However, this behavior IS a problem with -current but not -stable and it is not your hw's problem. I have not been able to track down what is causing this problem. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I've got the older Logitech 'Natural' wireless keyboard + wireless mouse working fine. I've had it for almost 3 years now, and aside from having to change batteries every 4-6 months it's been rock solid. I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. I didn't have to do anything to get it to work for me. I plugged the mouse connector into the mouse slot, the keyboard into the keyboard slot, and all is well. My combo uses a single reciever for both devices, sounds like you have two? Single receiver, but two cords coming out of it. dmesg shows that both the mouse and kb were detected, mouse as ums0 and kb as ukb0. XFree is set to use /dev/sysmouse, but dies with no core pointer if I dont use the corded mouse. I hard-code the mouse and don't use sysmouse. ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 Mine shows us as a ps/2 mouse. Is this a USB setup? Mine's a normal non-USB setup. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc.c locking patch
On Mon, 6 Jan 2003, Maxime Henrion wrote: Nate Lawson wrote: Attached is a diff that fixes a could sleep problem where ether_ifattach() does a malloc and dc(4) is holding a lock in its softc. It uses a cleaner exit strategy with only one call to DC_UNLOCK and no multiple return statements as well as fixing one place where error wasn't set. If people are ok with it, I'll sweep other drivers that have a similar problem. Doing this would maybe be a bit premature. A lot of drivers have FOO_LOCK and FOO_UNLOCK macros set to nothing, because of similar problems you're trying to fix. Interface locking probably needs to be rethought. I appreciate the insight but this seems pretty straightforward -- if a driver needs to muck with registers, it should use a per-device lock. If it needs to change global state (i.e. ether_ifattach), it's up to the called subsystem to do its own locking. The two are orthogonal. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Monday, 6 January 2003 at 10:27:21 -0800, Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? I've had this working with Vinum, but the method abused the devstat subsystem, and was deeemed inappropriate. I have code in development which would do it. You're welcome to it if you want to implement it. 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
font failure in X
Hello... I recently installed 5.0-RC2 and X from ports and some programs too. Now I have trouble with huge font sizes. Mainly in webbrowsers. But it's only some kind of fonts. I just can't find the options and I can't see any logs telling me what's wrong. Seems like the fonts use the size 100 instead of 10 or 12 that they normally do... suggestions ? I normally use NetBSD so I'm quite familiar with *nix. //roine To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
On Mon, 2003-01-06 at 20:11, Nate Williams wrote: Single receiver, but two cords coming out of it. dmesg shows that both the mouse and kb were detected, mouse as ums0 and kb as ukb0. XFree is set to use /dev/sysmouse, but dies with no core pointer if I dont use the corded mouse. I hard-code the mouse and don't use sysmouse. ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 Mine shows us as a ps/2 mouse. Is this a USB setup? Mine's a normal non-USB setup. Single wire coming out that splits into a PS/2 connector and a USB connector. If I plug just the USB connector in, dmesg shows both devices however the kb doesnt work. Plugging in just the ps/2 plug I get kb support but dmesg doesnt show the mouse. So I plug both in and have both devices listed. I also tried configuring xfree to use /dev/ums0 directly but it still dies with no core pointer. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
On Tue, 2003-01-07 at 12:16, Daren Desjardins wrote: ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1 Mine shows us as a ps/2 mouse. Is this a USB setup? Mine's a normal non-USB setup. Single wire coming out that splits into a PS/2 connector and a USB connector. If I plug just the USB connector in, dmesg shows both devices however the kb doesnt work. Plugging in just the ps/2 plug I get kb support but dmesg doesnt show the mouse. So I plug both in and have both devices listed. I also tried configuring xfree to use /dev/ums0 directly but it still dies with no core pointer. Personally I'd run usbd and let it run moused for you and then do.. vidcontrol -m on And see if the mouse works there. Check that usbd is running and that it started moused. The keyboard won't work unless you tell usbd to change the console keyboard using 'kbdcontrol -k devname' I believe (I have never used a USB keyboard) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
On Tue, Jan 07, 2003 at 12:40:46PM +1030, Daniel O'Connor wrote: keyboard using 'kbdcontrol -k devname' I believe (I have never used a USB keyboard) -- Daniel O'Connor software and network engineer My past experience with the USB keyboard isn't rather pleasant. When typing too fast, it starts to echo extra characters. For ex: typing abc too fast turns out to be ababc. Typing slowly remedies the problem but it's a pain. -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc.c locking patch
Wouldn't it be better if you didn't do the bogus locking in the attach routine? It would be better to not lock at all and not initialize the ISR until last. That's what I did with if_rl. Let's not work around the bogus locking, but insteal eliminate it. There's no way that the driver can interrupt itself until an interrupt happens. If there's no way to interrupt, no locking is needed :-) Also, most of the driver locking that's in the tree is likely bogus anyway, since the network stack still uses giant to a large extent. Warner 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 Tue Jan 7 04:15:50 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
Re: HOWTO: Basic-block profiling on -current.
Hello. This is just cool! I was wondering, did you receive my mail on this issue? It seems that I sent mail to you before too, but never got a reply. Thanks. - Hiten On Mon, Jan 06, 2003 at 02:28:52PM +0100, Poul-Henning Kamp wrote the words in effect of: I have committed the bits needed to use GCC's basicblock profiling on -current. Make sure to recompile the kernbb(8) program first. Here's an simple example how to profile a single file (vfs_bio.c): cd /sys/i386/conf config YOURKERNEL cd ../compile/YOURKERNEL make depend make all rm vfs_bio.o make vfs_bio.o DEBUG=--test-coverage --profile-arcs make all make install reboot # run your test. kernbb cd /sys/i386/compile/YOURKERNEL gcov vfs_bio.c # examine vfs_bio.c.gcov If you want to profile multiple files, you just give them all the same treatment as vfs_bio. It's perfectly possible to profile the entire kernel if you want to. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Andrew P. Lentvorski, Jr. wrote: Probably your best choice right now if you have a real RAID controller on your motherboard. The BIOS takes care of most of the nasty booting details. If you don't have a real RAID controller on the motherboard, stop now. Rebuilds don't work if you don't have a real RAID controller. You can recover, but it requires some dancing with dd (search the archives). Advantages: BIOS handles bootup issues. Very little required from OS Disadvantages: Hardware required. Proprietary. Will not rebuild a broken array without hardware RAID Not true, you can boot off a broken mirror on a non-RAID ATA controller, and then rebuild on the fly with atacontrol once the system is up, you do not need the RAID BIOS for rebuilding a broken mirror. Proprietary, well, in the case of using a stock ATA controller for this its certainly not :) The only caveat is that not all motherboard BIOS's allow you to boot from anything but the disk on the primary ATA channel. If you have such an animal you need to swap drives if it is the primary channel drive that is dead. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
On Tue, 7 Jan 2003, Soeren Schmidt wrote: Not true, you can boot off a broken mirror on a non-RAID ATA controller, and then rebuild on the fly with atacontrol once the system is up Is this new (ie. since August 22, 2002)? I attempted to do this back then and I couldn't actually get a rebuild to work for stock ATA controllers. At that point, I kept getting: atacontrol: ioctl(ATARAIDREBUILD): Operation not supported by device See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=698625+0+archive/2002/freebsd-stable/20020825.freebsd-stable for details on my abortive attempts to get this to work. Will I get different results if I try this procedure again, now? Alternatively, what did I do wrong in the original procedure? Thanks, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : assuming it's something about poor signal handling in libc_r, actually. I've seen signal problems in devd after it forks a child. Before it forks a child ^C works, but after it does a system(3) to run a command, ^C no longer works. There's something really odd going on that I've not had time to figure it out. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proper -current if_attach locking?
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : I was looking into some could sleep messages and found some bogus : locking in the attach routine of many drivers. Several init a mtx in : their softc and then lock/unlock it in their attach routine. This, of : course, does nothing to provide exclusive access to a device. I assume : there is going to be a global IF_LOCK or something to be used in attach : routines. Can someone fill me in on the intended design? The locking in the attach routines is generally bogus. Locking is only needed when you have more than one thread of execution. You don't have more than one thread of execution until after you establish the ISR and turn on interrupts. We should likely not be enabling interrupts until very late in the attach routine so that we don't need any locking in them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic on -CURRENT w/ SMP
I recently rebuilt my kernel to HEAD and configured my kernel to support the Dual 200Mhz PPro's. upon restart, I recieved the kernel panic below. panic: CPU APIC ID out of range (0..15) cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55;xchgl%ebx,in_Debugger.0 db trace Debugger(c03ca5f6,0,c03e2f29,c0537d04,1) at Debugger+0x55 panic(c03e2f29,f,0,c0537d3c,c038990e) at panic+0x11f processor_entry(f1440,1,0,0,1) at processor_entry+0x30 mptable_pass2(c0537d68,c020c301,c04430a0,34,c0420550) at mptable_pass2+0x2ce mp_enable(9f000,c0537d80,c0236131,c04430a0,c03ccfd2) at mp_enable+0x37 cpu_mp_start(c04430a0,c03ccfd2,0,1,c0537d98) at cpu_mp_start+0x3d mp_start(0,534000,534c00,534000,0) at mp_start+0x41 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c Like I said, this is a Dual 200Mhz Pentium Pro machine. Any ideas? Thanks -Frank Laszlo -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT/MU d s: a-- C++ BU P+ L- E--- W+++ N+ o- K- w-- O M+ V-- PS PE- Y+ PGP++ t+ 5- X R tv+ b DI+ D++ G e h-- r++ y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Andrew P. Lentvorski, Jr. wrote: On Tue, 7 Jan 2003, Soeren Schmidt wrote: Not true, you can boot off a broken mirror on a non-RAID ATA controller, and then rebuild on the fly with atacontrol once the system is up Is this new (ie. since August 22, 2002)? I attempted to do this back then and I couldn't actually get a rebuild to work for stock ATA controllers. At that point, I kept getting: atacontrol: ioctl(ATARAIDREBUILD): Operation not supported by device See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=698625+0+archive/2002/freebsd-stable/20020825.freebsd-stable for details on my abortive attempts to get this to work. Will I get different results if I try this procedure again, now? Alternatively, what did I do wrong in the original procedure? It should work on 4.7 forward, but its been a while since I played with it. Another thing is that its a pain to make a mirror on an already running system (which is often wanted), so I plan to add an option to atacontrol to tell where to get the master from, and then do an automatic rebuild during the create phase ie: atacontrol create RAID1 ad0 ad2 source ad0 This will create a mirror using ad0 and ad2, and start a rebuild to build the master with data from ad0. This way you can do a normal install, add a second (identical or bigger) disk, and make a mirror out of those. You just have to change your fstab before rebooting (ad0 - ar0) in order to boot... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic on -CURRENT w/ SMP
I believe this panic was cause by the BIOS not recognizing the second CPU.. i rebooted a couple times and did a couple BIOS config settings. now it will load the kernel, but right before fsck (and right after SMP: AP CPU #1 Launched!) I get this: lock order reveral 1st 0xc165x950 process lock (process lock) @ /usr/src/sys/kern/jern_descrip.c:2100 2nd 0xc1659434 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2107 Any ideas? -Frank Laszlo On Tuesday 07 January 2003 02:39 am, Frank Laszlo wrote: I recently rebuilt my kernel to HEAD and configured my kernel to support the Dual 200Mhz PPro's. upon restart, I recieved the kernel panic below. panic: CPU APIC ID out of range (0..15) cpuid = 0; lapic.id = Debugger(panic) Stopped atDebugger+0x55;xchgl%ebx,in_Debugger.0 db trace Debugger(c03ca5f6,0,c03e2f29,c0537d04,1) at Debugger+0x55 panic(c03e2f29,f,0,c0537d3c,c038990e) at panic+0x11f processor_entry(f1440,1,0,0,1) at processor_entry+0x30 mptable_pass2(c0537d68,c020c301,c04430a0,34,c0420550) at mptable_pass2+0x2ce mp_enable(9f000,c0537d80,c0236131,c04430a0,c03ccfd2) at mp_enable+0x37 cpu_mp_start(c04430a0,c03ccfd2,0,1,c0537d98) at cpu_mp_start+0x3d mp_start(0,534000,534c00,534000,0) at mp_start+0x41 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c Like I said, this is a Dual 200Mhz Pentium Pro machine. Any ideas? Thanks -Frank Laszlo -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT/MU d s: a-- C++ BU P+ L- E--- W+++ N+ o- K- w-- O M+ V-- PS PE- Y+ PGP++ t+ 5- X R tv+ b DI+ D++ G e h-- r++ y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
