Re: libc in CURRENT fails as of 1200 GMT today
On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote the words in effect of: [ ... ] I have not seen a commit since that time --4+ hours. everything else compiled; obviously a lot of incompletes without libc Hey there. Could you please do a `make includes', before building libc only. This error indicates that uuid.h is not in /usr/include. Cheers. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. This could be because of GEOM or something, but I am not sure, as I cannot try a non-GEOM sysinstall anyway. Also, is there a way I can get that 15G worth of data back, somehow, or do I just have to say bye-bye to it? All help will be appreciated. Cheers. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
On Fri, Nov 01, 2002 at 08:56:44PM +, Hiten Pandya wrote the words in effect of: Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. This could be because of GEOM or something, but I am not sure, as I cannot try a non-GEOM sysinstall anyway. Also, is there a way I can get that 15G worth of data back, somehow, or do I just have to say bye-bye to it? All help will be appreciated. Cheers. Please let me know what type of information is needed for debugging this problem. Cheers. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hmm, OK. Let me rephrase it all. I have a 120G IDE disk, which is under LBA mode. It is the second disk on my system. I have been using it with my old (julyish) -current for a while now as a backup disk thingy. My disk layout: ad1s1: 8997MB FreeBSD slice ad1s3: 50995MB FreeBSD slice ad1s2: 54478MB FAT32 slice (Note the order) This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028. The sizes are displayed correctly here, but when I try labeling the disk through sysinstall's Configure-Label, It shows: Disk: ad3 Partition name: ad3s1 Free: 0 blocks (0MB) Disk: ad3 Partition name: ad3s3 Free: 102110549 blocks (49858MB) Part Mount Size Newfs Part Mount Size Newfs - - - - ad3s1anone128MB * ad3s2 none 54478MB DOS ad3s1bnone 1008MB * ad3s1enone256MB * ad3s1fnone256MB * ad3s1gnone 7348MB * ad3s3anone128MB * -- Notice the sizes ad3s3bnone 1008MB * -- Note, ad3 should only show up as one partition, which, is 50995MB in size. The size 1000MB and 128MB DOES NOT MAKE SENSE AT ALL. Also NOTE, that the DOS partition shows has the right size, without any problems. This problem does not occur on my older -current, which, was before GEOM or even KSE III was integrated. On IRC, I have been told that it could be that geom_mbr is somehow messed up, but I cant say anything on that. FWIW, I have used up around 12G on the FreeBSD (ad1s3) slice, and around 20G on my DOS slice. The data got there, because I sliced the disk on my older -current, but I dont think that has got anything to do with it. FDISK Data: Script started on Fri Nov 1 05:04:33 2002 vmnet-current:1m/usr/src/sys/geomm# fdisk ad3 *** Working on device /dev/ad3 *** parameters extracted from in-core disklabel are: cylinders=232581 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=232581 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 18426492 (8997 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 122865120, size 111571425 (54478 Meg), flag 0 beg: cyl 1023/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 18426555, size 104438565 (50995 Meg), flag 80 (active) beg: cyl 1023/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: UNUSED Script done on Fri Nov 1 05:04:37 2002 When I go to Configure-Fdisk in sysinstall, it shows this WARNING message, which, I dont get in my old NON-GEOM system. If there is anymore data you would like, then please do not hesitate to contact me. Cheers. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] On Fri, Nov 01, 2002 at 05:35:21PM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. Sorry, I'm not understanding that sentence. Is there a typographical error in there somewhere, perhaps? 1000MB + 128MB 50GB The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. Sorry, I'm still confused. You have two different FBSD partitions on the same disk (s3 and s1)? I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? No reason. It should work. Is the install failing at some point with error messages? Did the install finish but now you can't boot the new system? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, I'm confused again. Data on the FreeBSD partition? Which FBSD partition? How did the data get there and in what way is it lost now, exactly? i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. You mean when you try to boot the 8GB partition, or the 50GB partition? Is fsck complaining about something? What is it saying? Please
Re: GEOM gets whole disk geometry for slice (instead of slice geometry)
On Sat, Nov 02, 2002 at 04:37:16PM +0300, Andrey A. Chernov wrote the words in effect of: On Sun, Oct 27, 2002 at 03:37:47 +0300, Andrey A. Chernov wrote: I have disk shared between FreeBSD and M$ Win, two slices, and got incorrect disklabel with GEOM kernel. Namely cylinders and sectors/unit fields are from _whole_ disk, not from just requested slice. Just found more brokeness: 'disklabel -r ad0s1' and 'disklabel ad0s1' shows different results, for -r case 63 added to offset field of all a, b and c partitions. BTW, is there is a way to turn GEOM off, something like NOGEOM kernel option? I want my old good disklabel back. I think it is NO_GEOM, but I am not sure, grep'ing for NO_GEOM does not come up with anything though, but give it a try. Cheers. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
On Sat, Nov 02, 2002 at 10:38:33AM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hmm, OK. Let me rephrase it all. I have a 120G IDE disk, which is under LBA mode. It is the second disk on my system. I have been using it with my old (julyish) -current for a while now as a backup disk thingy. My disk layout: ad1s1: 8997MB FreeBSD slice ad1s3: 50995MB FreeBSD slice ad1s2: 54478MB FAT32 slice Here you are discussing ad1, which should (I think) be the slave drive on the first IDE controller. This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028. The sizes are displayed correctly here, but when I try labeling the disk through sysinstall's Configure-Label, It shows: Disk: ad3 Partition name: ad3s1 Free: 0 blocks (0MB) Disk: ad3 Partition name: ad3s3 Free: 102110549 blocks (49858MB) Here you are discussing ad3, which should be the slave drive on the *second* IDE controller. Are you intending to discuss two different physical disks here? I'm still Oops, change that ad3 into ad1. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
On Sat, Nov 02, 2002 at 02:42:41PM -0800, walt wrote the words in effect of: Okay. Well, I see that just today sysinstall/label.c was updated to correct an error. I have no idea if that may be your problem, but errors do creep in regularly into -CURRENT, so it's possible. My gut feeling is that your files are still there ready to be used but probably not with the system you are using now. I would download a -STABLE installation floppy from the FBSD ftp site and see if you can use that disklable editor to examine the disk. If the disklabel looks correct then you can proceed to install a -STABLE system on that disk using the *existing* label, and your data should be intact. If the disklabel still looks bad then you have a bigger problem. You really need to save every label somewhere and restore it later if it gets trashed. I just use a pencil and paper and write it all down and tape the paper to the computer--very primitive but it's saved my backside more than once ;-) When fooling with -CURRENT you need to be ready for such disasters, and often all it takes is a pencil and paper and five minutes of preparation. Yup. Anyway, no one to blame, because I was aware it -current was gonna punish me one day anyway, so. no regrets. I will try your method out anyway. Lets see how it goes. :) Thanks again. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WIne freezes -current for half a year
On Sun, Nov 03, 2002 at 07:12:36PM +0100, Jan Stocker wrote the words in effect of: Hi wine freezes my system (always -current) for months (half a year i think). Does anyone have the same prob and/or a solution? Hi there, can you please elaborate on your situation, and provide more information about you system, like dmesg, sysctl -a etc. This will aid the developers in diagnosing your situation. Also, providing what type of errors you get etc, would help too. Cheers. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpid implementation?
On Wed, Nov 06, 2002 at 10:27:47PM +0100, Frode Nordahl wrote the words in effect of: Hello, I have been searching mailing lists and my friend Google for information about a acpid (like apmd) implementation for FreeBSD, but I have found nothing. Does one exist anywhere, or has anyone started out on something without telling anyone? :) Why do you need an acpid? -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 05:45:00PM -0500, Matthew N. Dodd wrote the words in effect of:
On Fri, 8 Nov 2002, Terry Lambert wrote:
Matthew N. Dodd wrote:
Recompile your kernel with
options PCI_ALLOW_UNSUPPORTED_IO_RANGE
Given the number of times that this comes up, can we change that to
PCI_ALLOW_ACTUALLY_SUPPORTED_IO_RANGE_WHICH_IS_NON_DEFAULT_TO_BE_ANNOYING
?
I think the plan is to make this option a loader tunable and make the
conditional in the pci code bitchy and then fix the larger problem with
IO ranges.
Hi there.
I have made a basic patch, which took me about 10 minutes to do so.
Basically, it removes the option PCI_ALLOW_UNSUPPORTED_IO_RANGE, and
replaces it with a loader tunable. This is no different from imp's
change to make PCI_ENABLE_IO_MODES a l-tunable. But this time, I do not
have a sysctl to show the _readonly_ value, this is because the hw.pci
node leaves in pci.c and I am unsure of how to tackle that. I have not
tested this patch, so consider it experimental.
Also. If this patch works, then we will have to remove the
PCI_ALLOW_UNSUPPORTED_I0_RANGE from ``options'' files and add entries
for hw.pci.enable_io_modes and this loader tunable to the loader(8)
manual page or some such.
Patch also available at:
http://www.unixdaemons.com/~hiten/work/diffs/pci_pci.patch
Cheers.
P.S. hw.pci should moved somewhere global, but donno how this can be
done or even if it is possible to do.
--
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
--- /home/hiten/pci_pci.c Fri Nov 8 17:25:52 2002
+++ /sys/dev/pci/pci_pci.c Fri Nov 8 19:11:03 2002
@@ -38,6 +38,9 @@
#include sys/systm.h
#include sys/kernel.h
#include sys/bus.h
+#if 0
+#include sys/sysctl.h
+#endif
#include machine/resource.h
@@ -90,6 +93,18 @@
DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, 0, 0);
/*
+ * sysctl and tunable vars
+ */
+int pci_allow_unsupported_io_range = 1;
+TUNABLE_INT(hw.pci.allow_unsupported_io_range,
+ (int *)pci_allow_unsupported_io_range);
+#if 0
+SYSCTL_INT(_hw_pci, OID_AUTO, allow_unsupported_io_range, CTLFLAG_RD,
+ pci_allow_unsupported_io_range, 1,
+ Allows the PCI Bridge to pass through an unsupported memory range
+ assigned by the BIOS.);
+#endif
+/*
* Generic device interface
*/
static int
@@ -288,21 +303,23 @@
switch (type) {
case SYS_RES_IOPORT:
if (!pcib_is_isa_io(start)) {
-#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
- if (start sc-iobase)
- start = sc-iobase;
- if (end sc-iolimit)
- end = sc-iolimit;
- if (end start)
- start = 0;
-#else
- if (start sc-iobase)
- printf(start (%lx) sc-iobase (%x)\n, start, sc-iobase);
- if (end sc-iolimit)
- printf(end (%lx) sc-iolimit (%x)\n, end, sc-iolimit);
- if (end start)
- printf(end (%lx) start (%lx)\n, end, start);
-#endif
+ if (!pci_allow_unsupported_io_range) {
+ if (start sc-iobase)
+ start = sc-iobase;
+ if (end sc-iolimit)
+ end = sc-iolimit;
+ if (end start)
+ start = 0;
+ } else {
+ if (start sc-iobase)
+ printf(start (%lx) sc-iobase (%x)\n, start,
+ sc-iobase);
+ if (end sc-iolimit)
+ printf(end (%lx) sc-iolimit (%x)\n,
+ end, sc-iolimit);
+ if (end start)
+ printf(end (%lx) start (%lx)\n, end, start);
+ }
}
if (!pcib_is_isa_io(start)
((start sc-iobase) || (end sc-iolimit))) {
@@ -325,21 +342,23 @@
*/
case SYS_RES_MEMORY:
if (!pcib_is_isa_mem(start)) {
-#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
- if (start sc-membase end = sc-membase)
- start = sc-membase;
- if (end sc-memlimit)
- end = sc-memlimit;
- if (end start)
- start = 0;
-#else
- if (start sc-membase end sc-membase)
- printf(start (%lx) sc-membase (%x)\n, start, sc-membase);
- if (end sc-memlimit)
- printf(end (%lx) sc-memlimit (%x)\n, end, sc-memlimit);
- if (end start)
- printf(end (%lx) start (%lx)\n, end, start);
-#endif
+ if (!pci_allow_unsupported_io_range) {
+ if (start sc-membase end = sc-membase)
+ start = sc-membase;
+ if (end sc-memlimit)
+ end = sc-memlimit;
+ if (end start)
+ start = 0;
+ } else
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Sat, Nov 09, 2002 at 08:40:21AM -0500, Hiten Pandya wrote the words in effect of: On Fri, Nov 08, 2002 at 07:21:32PM -0800, Brooks Davis wrote the words in effect of: On Fri, Nov 08, 2002 at 10:09:10PM -0500, Hiten Pandya wrote: P.S. hw.pci should moved somewhere global, but donno how this can be done or even if it is possible to do. I think you just need a SYSCTL_DECL(_hw_pci) in scope. Thanks! I added SYSCTL_DECL(_hw_pci), and then uncommented out the sysctl bits. Now it works fine. But I have a question, should I put SYSCTL_DECL(_hw_pci) in some sort of header file? Anyway, patch at: http://www.unixdaemons.com/~hiten/work/diffs/pci_pci.patch I have not attached it, because I just asked a question, and if I do have to put it in a header file, then it would just be worthless having a patch in this mail. Cheers. Hi there. As requested some people, the patch has been committed, and no behaviours have changed, except that PCI_ALLOW_UNSUPPORTED_IO_RANGE kernel configuration option has been nuked. A loader tunable, hw.pci.allow_unsupported_io_range is available. It is set to 0 by default, and a sysctl is provided to show the readonly value. The above patch was committed, with a few other changes, by Matthew (mdodd). Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
blimitd fixes (was: ports broken by KSE changes)
Hi there.
I have tried and fix some of the ports which were reported by Kris, as
_not working on -current_. I also checked the bento logs, and here it
is. More mails will follow up as I write more fixes.
I donno why, but no one bumped __FreeBSD_version, when Dr. Kirk made the
change to sys/user.h: removal of struct kp_eproc from struct user. So,
I have just used the version 50 and 500023 in my patches.
Note: This only applies to -current.
blimitd users:
http://www.unixdaemons.com/~hiten/work/ports/blimitd-patches
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
--- config.hSat Aug 4 15:11:31 2001
+++ config.h.newWed Oct 23 16:46:47 2002
@@ -13,7 +13,7 @@
#define SYSLOG_IDENT blimitd
/* location of pid file */
-#define PID_FILE _PATH_VARRUN ## blimitd.pid
+#define PID_FILE _PATH_VARRUN blimitd.pid
/* how often to check for infringements (in seconds). NB warnings can't be
* sent more frequently than this figure either */
--- kill.c Sat Aug 4 15:11:31 2001
+++ kill.c.new Fri Oct 25 04:53:40 2002
@@ -143,6 +143,7 @@
*/
/* copy the session structure to our address space */
+#if __FreeBSD_version = 500023
if (kvm_read(kd, (unsigned long)processes[0].kp_eproc.e_tsess, tty_session,
sizeof(tty_session)) != sizeof(tty_session)) {
syslog(LOG_ERR, kvm_read failed (%s:%d): %s, __FILE__, __LINE__,
kvm_geterr(kd));
goto failure;
@@ -162,7 +163,36 @@
/* success? well possibly..we don't actually check the process went */
return_value = 1;
}
+#else /* if __FreeBSD_version = 500023 */
+ if (kvm_read(kd, (unsigned long) processes[0].ki_paddr-p_session,
+tty_session,
+ sizeof(tty_session)) != sizeof(tty_session)) {
+ syslog(LOG_ERR, kvm_read failed (%s:%d): %s,
+ __FILE__, __LINE__, kvm_geterr(kd));
+ goto failure;
+ }
+
+ /* copy the session leader's structp proc to our address space */
+ if (processes[0].ki_kiflag KI_SLEADER) {
+ if (kvm_read(kd, (unsigned long)tty_session.s_leader,
+ session_leader, sizeof(session_leader)) !=
+ sizeof(session_leader)) {
+ syslog(LOG_ERR, kvm_read failed (%s:%d): %s,
+ __FILE__, __LINE__, kvm_geterr(kd));
+ goto failure;
+ }
+ /* send a hangup signal to the shell */
+ if (kill(session_leader.p_pid, SIGHUP) != 0) {
+ syslog(LOG_ERR, kill failed (%s:%d): %m, __FILE__,
+ __LINE__);
+ goto failure;
+ } else {
+ /* success? well possibly.. we don't know actually
+* check where the process went */
+ return_value = 1;
+ }
+ }
+#endif
/* we skip to here if things fail so we always close the kvm interface.
* we could have used massive if staements or do/while(0) and break but
* we didn't */
Re: mdconfig /tmp problem
On Thu, Nov 14, 2002 at 02:40:32AM -0800, Doug Barton wrote the words in effect of: Folks, I have been using an mdconfig /tmp for quite a while. Today, running -current from 11/14 I got the following errors while doing an installworld after testing my bind 8.3.3-patched import stuff: kernel: swap_pager_strategy: bp 0xc2f34480 blk 0 size 0, not page bounded (plus lots more) During the installworld whatever binary was being read from the /tmp/install.foo directory would segfault, and I'd get one or more of those in my log. Here is my little script for creating the mem disk. It hasn't changed in a long time. # Usually a noop, but just in case mdconfig -d -u 10 2/dev/null mdconfig -a -t swap -s 8M -u 10 disklabel -r -w md10 auto /dev/null newfs -U /dev/md10c /dev/null mount /dev/md10c /tmp /bin/chmod 1777 /tmp There is also another problem. mdconfig/md driver messes up when a 0 byte file is passed: # touch /tmp/tmp.fake; mdconfig -a -t vnode -f /tmp/tmp.fake I have not been able to collect debugging data, but when I have some, I will pass it on. FYI. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lost disklabel
On Wed, Nov 13, 2002 at 09:19:11AM -0600, Patrick Hartling wrote the words in effect of: I have a machine that is running -current from October 10, 2002. It had been running fine for about two weeks--up until I had to reboot it. When it came back up, one of my disks apparently lost its disklabel. Is there any way to recover a disklabel? If not, I'm willing to grovel the disk and try to reconstruct its disklabel (there is really only one partition on it that I need to get back, and its at the beginning of the disk), but disklabel(8) won't even let me try to make a new one. If I run 'disklabel -e da3s1', I get an error saying ioctl DIOCGDINFO: Inappropriate ioctl for device. Running 'disklabel -r da3s1' gives a bad magic pack number error, which does not surprise me. This is a dangerously dedicated disk with a single BIOS partition containing four FreeBSD partitions. I have a second identical disk in the machine. fdisk(8) gives the same information for each, so I don't think the BIOS partition is messed up. Is there something obvious that I'm missing about how to fix this problem? Hi there. I am not sure if this is a 100% solution, but can you try using the find-sb utility. You can run this utility as root, once you have compiled it: # cd /usr/src/tools/tools/find-sb # make # ./find-sb device-name: e.g. /dev/ad0 Hope that helps. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm impressed, but ...
On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote the words in effect of: | [...] | vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 | unknown: PNP0303 can't assign resources (port) | unknown: PNP0f13 can't assign resources (irq) | unknown: PNP0c02 can't assign resources (port) | unknown: PNP0501 can't assign resources (port) | unknown: PNP0700 can't assign resources (port) | unknown: PNP0401 can't assign resources (port) | unknown: PNP0501 can't assign resources (port) | Timecounters tick every 10.000 msec | ahc0: Someone reset channel A | [...] All my hardware (the stuff I've tested anyway) appears to work. Any idea which device is being unknown, or how I could find out? Hi there. Can you try changing the hardware tunable, hw.pci.allow_unsupported_io_range, to the value of 1 in your loader.conf. I think this should do it. You can then check this value after you booted by `sysctl hw.pci`. 2. This one's the most irritating. I use Mutt as my mailclient using Maildirs for storage. It occasionally happens that Mutt just 'hangs' reading a directory, and there's no way for me to kill it. Ps axl shows it as being in state Ds or Ds+ and blocked by ufs. Hmm, this also happens in the case of dd(1). If you invoke dd(1) as: # dd if=/dev/zero of=/tmp/somefile As you can see, it gets stuck when not provided with a count variable. It hangs in the `ufs' state. I am currently looking into this. I am thinking, this is because a 0 byte file is found disturbing. 3. I can't seem to restart my machine properly. This might be related to the above, as the only reason for me to restart the machine is the fact that I can't kill Mutt however much I try, and really would like to read my mail. It will sync disks and say 'done', but then it just sits there doing nothing until I flip the power-switch. Exactly the same thing happens when any process hangs in the `ufs' state. It syncs the disks, when you `shutdown` or `fastboot`. This indicates a bug in the kernel. As I said, I'm happy to help analyse and debug these issues, but I don't know where to look :-) Can you try using `ktrace`, like this: root# ktrace mutt (or the command which makes it hang) root# kdump -f ktrace.out (this is the output needed) Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MD broken in current
On Tue, Nov 26, 2002 at 09:00:37PM +1100, Bruce Evans wrote the words in effect of:
On 26 Nov 2002, Vladimir B. Grebenschikov wrote:
# mdconfig -a -t vnode ./bootimg.bin
mdconfig: ioctl(/dev/mdctl): Bad address
This should be ... -t vnode -f ./bootimg.bin.
The bug is just low quality option parsing. ./bootimg.bin is garbage
when it is not preceded by -f, and garbage args are silently ignored.
A -f file is required to specify the vnode for -t vnode but neither
the man page synopsis nor the usage message are detailed enough to
say this. When no file arg is specified, the file arg is NULL and
this causes the Bad address error.
There is also a problem, when the md(4) driver is passed a 0 byte file,
i.e. mdconfig -a -t -vnode -f /tmp/mdimage.zero. It simply hangs the
process in the `mddestroy' state, making it unkillable.
David Wolfskill tested a patch, which I made. It could be a _possible_
fix to the problem. When a 0 byte file is found, by mdcreate_vnode()
it passes up an EINVAL.
I used the stat structure, and the vn_stat() routine to get the information,
although I am not sure if that is the best/sane way of doing it. The URL for
the patch is: http://www.unixdaemons.com/~hiten/work/diffs/md.c.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: md.c
===
RCS file: /home/ncvs/src/sys/dev/md/md.c,v
retrieving revision 1.74
diff -u -r1.74 md.c
--- md.c2002/10/21 20:08:28 1.74
+++ md.c2002/11/24 23:43:40
@@ -79,6 +79,7 @@
#include sys/stdint.h
#include sys/sysctl.h
#include sys/vnode.h
+#include sys/stat.h
#include vm/vm.h
#include vm/vm_object.h
@@ -807,6 +808,7 @@
struct md_s *sc;
struct vattr vattr;
struct nameidata nd;
+ struct stat sb;
int error, flags;
flags = FREAD|FWRITE;
@@ -828,6 +830,13 @@
(void) vn_close(nd.ni_vp, flags, td-td_ucred, td);
return (error ? error : EINVAL);
}
+
+ error = vn_stat(nd.ni_vp, sb, td-td_ucred, NOCRED, td);
+ if (error)
+ return (error);
+ if (sb.st_size == 0)
+ return (EINVAL);
+
VOP_UNLOCK(nd.ni_vp, 0, td);
if (mdio-md_options MD_AUTOUNIT) {
Re: ACLs on the boot partition?
On Tue, Nov 26, 2002 at 11:21:28AM -0700, [EMAIL PROTECTED] wrote the words in effect of: On Tue, 26 Nov 2002, Bruno Miguel wrote: On 25 Nov 2002 at 23:34, [EMAIL PROTECTED] wrote... How do I enable ACLs on the boot partition? tunefs -a enable /dev/ad0s1a indicates it got set (in single user mode with / mounted readonly). But I still can't set anything with setfacl(1). I tried booting to the fixit floppy, hoping to set acls flag from there to my partition, but it doesn't have tunefs. Is my only choice now to take the drive out and put it in another FreeBSD machine and set it from there? If you are using UFS1, did you follow the procedures in /sys/ufs/ufs/README.acls ? No, not using USF1. / was formatted UFS2. tunefs -a /your/filesystem I think thats the one. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: Martijn Pronk wrote: Robert Watson wrote: The build of netncp is currently broken on 5.0-CURRENT, and I'd like to see this fixed before 5.0-RELEASE. Unfortunately, we're having a lot of trouble finding a test environment, which is the natural and immediate follow-on to the compile fixes :-). Was wondering if anyone with FreeBSD kernel debugging experience and some time on their hands was interested in helping resolve this issue over the next week or two. I can test this next week at work, however, I don't normally use netncp nwfs, so it may take me a while. I'll get back on this next week. In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Searching for users of netncp and nwfs to help debug 5.0 problems
On Tue, Nov 26, 2002 at 01:10:45PM -0800, Julian Elischer wrote the words in effect of: On Tue, 26 Nov 2002, Nate Lawson wrote: On Tue, 26 Nov 2002, Hiten Pandya wrote: On Tue, Nov 26, 2002 at 08:10:50PM +0100, Martijn Pronk wrote the words in effect of: In file included from /home/src/sys/netncp/ncp_conn.c:46: /home/src/sys/netncp/ncp_conn.h:174: field `nc_lock' has incomplete type /home/src/sys/netncp/ncp_conn.h:193: confused by earlier errors, bailing out *** Error code 1 I guess struct lock can't be found. I hope someone can do something with this. Once you change the sys/lock.h line in ncp_conn.h to sys/lockmgr.h, you will see a lot of struct proc related errors springing up. The motto of this message is, that fixing that line will not make it compile. We need to make sys/netncp use struct thread instead of struct proc. This is easy in some parts of the code, and on some its just a little tricky, but not hard. Somebody did update the prototypes to netncp, but forgot to change the logic, for lockmgr calls, example, its last argument is a struct thread etc. I was going to work on this task at one point in time, but now that my school exam timetable has changed, I will not be able to do it; for the next 2/3 months anyway. If someone wants to give a go at this task, then they are most welcome to take my place. I thought Julian volunteered to do this a while back. If he is not, I can pick this up and make it compile but I have no equipment to test it on. It's not so much that I volunteered as I said that I'd help with thread/proc issues.. The trouble was that there are places where it used a proc in the old code, but in some cases it needs to be a proc, and in other cases it now needs to be a thread. But all they stored was the proc. Also, from my memories of the code you needed to understand the protocol to know which needed to be which, and I don't know that protocol. In addition whoever does it needs to remember that any structure that stores a thread poitner is probably in error, as threads are transient items and any stored thread pointer is probably a wild pointer within a few milliseconds of being stored. :-) Changes in ncp_conn.[ch] do not require a lot of netncp-foo. But other modules like ncp_ncp.[ch] might do. Julian's KSE Milestone 2 commit _did_ touch ncp_conn.h and ncp_rq.h. FWIW, some of the code in netncp does not even need a struct proc, but its just there, for some reason. If no one picks this task up, I will eventually get back to it, but not in the next 3/4 weeks or so. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MD broken in current
On Wed, Nov 27, 2002 at 11:37:17AM +, Ian Dowse wrote the words in effect of: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 27 Nov 2002, Ian Dowse wrote: I think moving the line tsleep(sc, PRIBIO, mdwait, 0); to just after the following `if' statement may do the trick. If the Wouldn't Giant locking prevent races here? There is no locking in sight for the ioctl, but ioctl() holds Giant. Yes, but mddestroy() assumes that the kthread is waiting in the mdwait tsleep() when it calls wakeup(). That won't be true if the kthread has not yet had a chance to run, or if it is waiting to acquire Giant before entering the main loop (or if anything it calls drops Giant). Moving the check of the MD_SHUTDOWN to before the tsleep should catch all of these cases, and Giant ensures that the wakeup() does not occur after the flag is tested but before the tsleep(). Is anyone planning to take this task, because, I think its important that it is fixed. Or should it be put on the 5.0-todo list? If not, we should put it in the BUGS section of mdconfig/ or the md(4) manual page. IMO. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Harry Potter and the Disappearing Disklabel
On Fri, Nov 29, 2002 at 08:47:10AM -0800, Sam Leffler wrote the words in effect of: Yesterday morning I was having some trouble with XFree consuming much more cpu time than necessary... A truss showed that some kind of shared memory issue going on, but also froze my system hard. After rebooting (kernel was from Nov 26 or 27) fsck could not check my one dirty UFS2 partition. Had to newfs and mtree to recreate /var. No big deal, and I saved an image of it beforehand. After rebooting, there was... NOTHING. GRUB errored out and wouldn't boot. Nothing could see my partitions. After a minimal 4.7-R install (DP2 disklabel whined about offsets and some other STRANGE error messages, so I went with 4.7) on a small fat32 partition, I discovered that the disklabel was empty. Had to edit it by hand... Booted up fine, made a backup, rebooted, and nothing. Not only was there NOTHING, but the disklabel on the new 4.7 install had vanished as well. This time the disklabel had to be recreated with -w -r AND the boot blocks had to be reinstalled. I've seen one post similar to this, but not much else. I think maybe the UFS2 problem had to do with Kirk's recent changes, but the disklabel issue... I'm wary to reboot my machine! What in the hell could be causing this? I'm tempted to point the finger at GEOM, but hate to say anything like that. Same problem hit me yesterday. Haven't figured out the cause yet. Sam FWIW, find-sb in /usr/src/tools/tools, does a good job of finding UFS1 and UFS2 slices. It is somewhat similar to scan_ffs but way more advanced. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unkillable process - 'mdconfig -t vnode' on small file
On Sat, Nov 30, 2002 at 06:24:06PM +0100, Michal Mertl wrote the words in effect of:
Subject says it all.
I wanted to make vnode-backed md(4) and forgot to specify size, thas it
after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
be killed. It's wchan ('ps axO wchan|grep mdconf') is mddest.
Hello.
I recently reported this issue, and Ian Dowse had a fix to correct this
situation in the mddestroy() routine in src/sys/dev/md/md.c. Please
update your tree, and rebuild.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Where is APM0 ???
On Sun, Dec 01, 2002 at 03:50:59PM +0300, Sergey V Golitzyn wrote the words in effect of: On Sunday 01 December 2002 07:19, Marcin Dalecki wrote: Sergey V Golitzyn wrote: Hello, i have a little problem with APM (Adv. Power Managment) I migrate from 4.7-STABLE to 5.0-CURRENT version. But in process i have lost apm0 device in dmesg. Device /dev/apm is in, but apmd daemon does not start cozz /dev/apmctl device not exist. kozaczek# kldload apm kozaczek# ls -l /dev/apm crw-rw-r-- 1 root operator 39, 0 Dec 1 02:49 /dev/apm kozaczek# Try it as a module. But generally ACPI should be suprerior. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Hello Again, Problem can't be solved by your way. my ls -l /dev/apm contains same information, but i /dev/apmctl device does not exist, and APM already builded in the KERNCONF FILE, the question is HOW TO ENABLE IT IN device.hints file??? apm saver also talks what It need #APM enable# (see dmesg file in prev message). Or, may be exist any another way to shutdown -p now machine. (Means only power down by using ACPI functions) Try disabling ACPI, it _might_ work this way. But if your system supports ACPI, then don't bother with APM imho. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sysctl_sysctl_next_ls() panic in case of empty node
Hi.
A bug in sysctl_sysctl_next_ls() makes the kernel panic, if an empty
node is passed to it, because the value of 'namelen' is statically
assigned 1 at the end of the routine.
I finally got my head around this issue, and I thought I would submit a
fix. Yesterday, I found out that there is PR for this issue, since
4.4-RELEASE, which means, that the bug is old, so the fix will need to
be MFC'ed.
Test code: http://www.unixdaemons.com/~hiten/work/misc/sysctlbug1.c
Patch: http://www.unixdaemons.com/~hiten/work/diffs/kern_sysctl.c.patch
I also have a screenshot of my VMware FreeBSD-CURRENT installation, in
which I wrote the test code. Compile the test code as a KLD, and then
load it, after that, execute:
# sysctl -a bugfoo
Screenshot, http://www.unixdaemons.com/~hiten/work/misc/sysctl-bug.gif,
and PR kern/31490. If you have any questions or comments regarding this
bug, please do not hesitate to contact me for more information.
Cheers.
P.S. Patch and test code attached with this mail.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
/*
* Code for reproducing Sysctl (empty node) bug.
*/
#include sys/param.h
#include sys/systm.h
#include sys/sysctl.h
#include sys/kernel.h
#include sys/module.h
static int bug_load(module_t, int, void *);
SYSCTL_DECL(_bugfoo);
SYSCTL_NODE(, 0, bugfoo, CTLFLAG_RW, 0, Bugfoo and Family);
SYSCTL_NODE(_bugfoo, OID_AUTO, mac, CTLFLAG_RW, 0, Bugfoo and Family);
SYSCTL_NODE(_bugfoo_mac, OID_AUTO, debug, CTLFLAG_RW, 0, BF [1]);
SYSCTL_NODE(_bugfoo_mac_debug, OID_AUTO, counters, CTLFLAG_RW, 0, BF [2]);
static int mac_debug_label_fallback = 0;
SYSCTL_INT(_bugfoo_mac_debug, OID_AUTO, label_fallback, CTLFLAG_RW,
mac_debug_label_fallback, 0, Filesystems should fall back to fs label
when label is corrupted.);
TUNABLE_INT(bugfoo.mac.debug_label_fallback, mac_debug_label_fallback);
/* Module initialisation stuff */
static moduledata_t bugctl_mod = {
bugctl,
bug_load,
0
};
static int
bug_load(module_t mod, int cmd, void *arg)
{
int err = 0;
switch (cmd) {
case MOD_LOAD:
printf(Sysctl Bug Manipulation\n);
break; /* Success*/
case MOD_UNLOAD:
break; /* Success */
default:
err = EINVAL;
break;
}
return(err);
}
/* Now declare the module to the system */
DECLARE_MODULE(bugctl, bugctl_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
Index: kern_sysctl.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.135
diff -u -r1.135 kern_sysctl.c
--- kern_sysctl.c 2002/10/27 07:12:34 1.135
+++ kern_sysctl.c 2002/12/03 14:51:07
@@ -538,7 +538,10 @@
int *next, int *len, int level, struct sysctl_oid **oidpp)
{
struct sysctl_oid *oidp;
+ int i_namelen;
+ i_namelen = namelen ? 1 : 0;
+
*len = level;
SLIST_FOREACH(oidp, lsp, oid_link) {
*next = oidp-oid_number;
@@ -585,7 +588,7 @@
len, level+1, oidpp))
return (0);
next:
- namelen = 1;
+ namelen = i_namelen;
*len = level;
}
return 1;
Re: NFS-related panic on reboot
On Mon, Dec 09, 2002 at 03:11:35PM -0800, Lars Eggert wrote the words in effect of:
With today's -current, after typing reboot into tcsh:
NFS append race @0:13
NFS append race @0:23
NFS append race @0:13
NFS append race @0:3
NFS append race @0:60
NFS append race @0:168
NFS append race @0:518
Stopping cron.
Stopping inetd.
Shutting down daemon processes:.
Shutting down local daemons:.
Writing entropy file:.
[1] Terminated
.
[... snipped ...]
Stopped at nfs_removerpc+0x19: movl0x168(%eax),%eax
db trace
nfs_removerpc(c74675dc,c6b5ce6c,c,c6b0fc00,0) at nfs_removerpc+0x19
nfs_removeit(c6b5ce60,0,c6b0fc00,c21b19a0,1) at nfs_removeit+0x30
nfs_inactive(df0c0aa4,12,c21b19a0,c21b19a0,0) at nfs_inactive+0x8d
[... snipped ...]
Hi.
This problem, is happening (possibly) because nfs_removerpc() is passed a
NULL struct thread (a No No iirc) by nfs_removeit(). nfs_removerpc()
is only called from two places: nfs_removeit() and nfs_remove():
In the case of nfs_remove(), it passes the thread from the
struct compnonentname (cnp-cn_thread), while nfs_removeit() passes
NULL. The problem with this is, that nfs_removeit() passes the thread arg
to nfsm_request(), and it dies.
Could you try the following patch, if you are still getting this
problem:
%%%
Index: nfs_vnops.c
===
RCS file: /home/hiten/ncvs/src/sys/nfsclient/nfs_vnops.c,v
retrieving revision 1.189
diff -u -r1.189 nfs_vnops.c
--- nfs_vnops.c 11 Oct 2002 14:58:32 - 1.189
+++ nfs_vnops.c 14 Dec 2002 16:25:14 -
@@ -1468,7 +1468,7 @@
{
return (nfs_removerpc(sp-s_dvp, sp-s_name, sp-s_namlen, sp-s_cred,
- NULL));
+ curthread));
}
/*
%%%
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
On Mon, Dec 16, 2002 at 01:12:33PM +0100, Harti Brandt wrote the words in effect of: Hi all, is there any documentation on the FreeBSD-busdma stuff? FreeBSD seems differ substantially from NetBSD in this regard. As far as I understand FreeBSD uses an older version. Hello Harti, I recentley started writing a bus_dma manual page, and also adding bits from the NetBSD manual page. You can view a copy which gets updated about every day or two: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch Yes, FreeBSD does use an old version of bus_dma, but things are being ported as needed AFAIK. For example, it would be good to have the BUS_SPACE_DEBUG functionality ported to our bus_space/dma implementation -- I am working on this at the moment; and also the naming o some flags, like BUS_DMAMEM_NOSYNC, which is BUS_DMA_COHERENT on NetBSD. I was gonna compose a mail to Warner about this, but now its being asked on a list, I am letting it out. :) There is also stuff about bounce thresholds, and the nature of DMA transfers (i.e. BUS_DMA_READ/WRITE) which needs to be ported. Once step at a time, and hopefully I will have all this done. If I get enough time after this, I will be doing an article on bus_dma, but not sure yet. NOTE: The above copy is work in progress -- the man page conversion should be finished hopefully by end of this week. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 12:27:59PM +1100, Darren Reed wrote the words in effect of:
Well someone has blown my cover from developers and has asked here
what I was trying to be more surrepticious about!
In some email I received from Sam Leffler, sie wrote:
A teeny-weeny issue I would like to discuss, is that we make the pfil(9)
hooks code default in 5.0, and remove the kernel option; this is because
it creates problems when PFIL_HOOKS is not in the (e.g. GENERIC) kernel,
and someone tries to load the ipfilter kernel module (ipl.ko). [1]
I have discussed this with Darren, but would just like to make it
public, so it can be discussed by the release engineers etc. I
apologize but I do not have patches for this.
Enabling PFIL_HOOKS changes various code paths. Doing this so late in the
release cycle is a bad idea. I also recall that there is a performance
penalty (at least in the bridge code) for having this enabled.
There are callouts in both the IPv{4,6} paths for input and output with
PFIL_HOOKS and also bridging.
PFIL_HOOKS is 1 .c file and 1 .h file and a very small amount of code.
Also, given its generic nature, I'd hope that ipfw* could eventually
move to use it for intercepting packets along the above code paths.
The bloat factor from including it in the base kernel should be very
small and perhaps the impact of the code being active in those packet
paths close to immeasurable (I hope.)
Both issues make it seem like it should stay an option for 5.0.
I agree with this.
Maybe we should put in the release notes, that:
PFIL_HOOKS is required for IPFILTER
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
On Sat, Dec 21, 2002 at 02:42:30AM +0100, Dan Lukes wrote the words in effect of: IFAIK no. I tried it also during debug of my problem. But it doesn't support 1000BaseTX, so it isn't decision for my purpose. The only cards with HW vlan support on STABLE are nge, bge, txp, gx, em, ti (ti aren't affected by reported bug as it strips the priority bits at driver level). Dan, I believe you submitted a PR about this [1], what does patch try to solve, regarding VLAN hardware support? [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46405 Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SIS 962 chipset, problems ...
On Mon, Dec 23, 2002 at 04:22:22PM +0100, Martin Blapp wrote the words in effect of: Hi all, I'm trying to get my laptop running, with some success, but the network card is not very friendly to me. none3@pci0:4:0: class=0x02 card=0x105517c0 chip=0x09001039 rev=0x91 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff Dec 23 15:17:03 kernel: sis0: MII without any PHY! Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach returned 6 Dec 23 15:17:03 kernel: sis0: SiS 900 10/100BaseTX port 0x2000-0x20ff mem 0xec005000-0xec005fff irq 11 at device 4.0 on pci0 Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff Dec 23 15:17:03 kernel: sis0: MII without any PHY! I thought first that this is a similar problem to the one where the physical is at id 1, not 0. But it still doesn't work. IIRC, this is the same problem, that was posted on -hackers -- something to do with the Card not reading the MAC address from the EEPROM. I may be wrong. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Does anyone have an lge(4) supported NIC?
Hi all. Sorry for cross posting, but if someone on the channel has an lge(4) supported NIC and you are willing to test some patches, can you please contact me privately? Cheers. -- Hiten Pandya http://www.unixdaemons.com/~hiten/ [EMAIL PROTECTED], [EMAIL PROTECTED] 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: Bluetooth stack for FreeBSD
On Wed, Jun 04, 2003 at 09:32:32AM -0700, Maksim Yevmenkin wrote: Dear Hackers, Another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030604.tar.gz I am regret to announce that this is probably the last release. My company has announced that they will pull out of USA and i will most likely loose my job. Unless i find another position, i will be forced to return back home. If anyone knows/wants to hire a H1B slave please drop me a e-mail. I will consider any position within USA or even Europe. I am *really* sorry :( I will try to do my best and support the code, but i can not make any promises at this point. Awww :-( Someone should probably make you a committer so you can just update the Bluetooth code in FreeBSD as you feel like. ;-) Hey, thanks for all the good bluetooth work! -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
VFS: C99 sparse format for struct vfsops
Gang, My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. Just like phk@ said in his mail for cdevsw; likewise, we wil be able to add new vfsops without having to hunt down each driver to match. Except this patch was not generated automatically. While there, I have also nuked all the prototypes for the vfsops, and replaced them with the typedefs, available in sys/mount.h, i.e. vfs_op_t. If this patch gets approved by some senior mac-daddies of FreeBSD, I can kindly ask my mentor, DES, to commit this for me. 8-) The patch: http://people.FreeBSD.ORG/~hmp/patches/vfs-voodoo.patch My mentor, and some other developers on secret IRC channel have given this a cursory glance. I am composing my email from a kernel running with this patch -- no rabbits, or hard disks were harmed in the making of this patch. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote: Hiten Pandya wrote: My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. I really dislike the changes to vfs_init(). Specifically, it's not the overhead, so much as it's the implied side effects. And how many times is vfc_register() called? Its not in the patch of an I/O operation or anything. Its just a mount time overhead which will go through -- a one time thing. Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. Considered. Now consider this, would you argue this about the sparse cdevsw initialisation in make_dev()? I hardly think so. It does a good job of centralising things, and making it easier for all of us. This could happen with a new VFS implementation that gets loaded as a module. While the current code can't really handle this well, the changes move us further away from ever being able to handle something like this. 8-(. But, up to now, this has not been a problem, unless you make it so. I don't think I even needed to add conditional checks for the mount and nmount ops in vfs_init. These are things which would be fault of developer if he doesn't update the `centralised' code, not yours or mine, or FreeBSD's. I also don't see the point of having a gazillion default ops being inited in every fs specific vector when we can just do this centrally. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote: This is a different thing entirely... you are not adding elements in the cdevsw case. Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse init? The VFSOP case is less of a problem than the VOP case, but it's still a problem. Poul broke the VOP case a long time ago, when he added the default stuff, since there is no way to add a new default to an already existing array, and the entries with a default can't be proxied (e.g. over the network or to user space via a descriptor, per John Heidemann's original design for VFS stacking in UCLS's FICUS). OK, we are moving away from UCLS' FICUS. Could you kindly provide me with some examples, and practicle use of this ``adding'' a new default in an already existing array? By making this change, you are basically changing it from a data structure to something that has to be coded, and there's no way to add code for a new entry that needs to be defaulted to a non-NULL value -- which they all have to be. Huh? Come again please? Could you ellaborate on this point as it is sending me in circles. I don't see how it is not possible to do that, please provide a practical case, so I can understand. As I said above: Poul broke this for VOPs. It doesn't make sense to say It's broken for VOPs now, so it's OK to break it for VFSOPs, too. ... It's not been a problem, as you say, so far, because the VFS stacking in FreeBSD has been broken for a long time. Breaking it more just moves us farther away from ever fixing the code, which I think is a bad thing. That is such of a broad statement..= If, at some point, we get rid of the default crap, then it would be possible to add VOPs to a running kernel by just reallocating the VOP array for each mounted FS to add the entry to the end of the array. And here is the question again, why would you want to add VOPs to a running kernel? Please provide some examples, or practical cases. Your change makes this impossible for VFSOPS. Awaiting your reply... Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Tue, Jun 03, 2003 at 05:32:35PM +0900, SUZUKI Shinsuke wrote: I discussed this issued within KAME. Here's our rough plan about this synchronization. If you have some opinion, please let me know. When I've finished each merge, I'll ask you how to proceed. - sync per feature; don't do a complete sync with the KAME-snap: Since some of the KAME-specific features are still under standardization or immature, it's dangerous to sync without much consideration. For what its worth, I have some of this stuff already merged in my local cvs tree. Drop me note if I can be of any help. I have the IGMPv3 code in my repo merged. Cheers. -- Hiten [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s4bios
On Tue, Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote: Is there anyone that has succesfully used acpiconf -s 4? I'm very interested in your reports. If you haven't tried yet, but are willing to help me, please report me your findings. Hello Mark, I may not be totally correct, but it has always helped me to check if a particular ACPI state was supported by my system: # sysctl hw.acpi.supported_sleep_state hw.acpi.supported_sleep_state: S1 S4 S5 Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
On Fri, Jun 13, 2003 at 03:04:52AM +0200, Erik Paulsen Skaalerud wrote: Is anyone working on ALTQ intergration for FreeBSD 5.1? Looks like the FreeBSD-ALTQ went drop dead, as they havent made anything new since the release of FreeBSD 5.0.(http://www.rofug.ro/projects/freebsd-altq/) I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. The version that is available at the website is about a year old (august 2002 ish), and there have been substantial changes to the kernel since then. Other than that, I have got it working... Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
On Fri, Jun 13, 2003 at 09:39:37AM +, Holger Kipp wrote: Erik Paulsen Skaalerud ([EMAIL PROTECTED]) wrote: Is anyone working on ALTQ intergration for FreeBSD 5.1? [...] I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. If you're looking for a fxp hacker, mux is the one you want ([EMAIL PROTECTED]). He's also on irc.freenode.net with the same nickname. Isn't someone working on integrating ALTQ and pf - similar to what has been done for OpenBSD? Yes, but even if the PF is ported, you still need to download the ALTQ package fromt he ROFUG.org site, because the KAME implementation is used. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : In the last episode (Jun 17), Scott Lambert said: : Is there some list of actions to preform and data to collect that : would assist with getting the ACPI stuff lined out? : : I've read the acpiconf man page but don't know that it gives me any : way to test for any specific functionality. I've been gradually : piecing together the meaning of S1, S2, S3, S4, and S5 and figuring : out that the *_(button|switch)_state sysctl oids specify which state : to go to on activation of that button rather than being a descriptor : of the current state of the buttons. : : I haven't figured out if the hw.acpi.thermal oids. I think maybe : ACPI doesn't recognize the hardware. Is a thermal oid value of 3692 : actually 36.92 celcius or some scale from 0x to 0x? : : ACPI records temperature in tenths of a Kelvin, if you can believe it :) I don't believe that. 369.2K is 96.2C, which is over 200F. That seems to hot to me. My laptop says 2982, which is either about 30C or 15.2C. Given how warm it is on my leg at the moment, I'd guess it is centi-Celcius. Maybe converted internally? Why not the use http://people.freebsd.org/~hmp/acpi_temp.c -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locking problems in IPv6 code
On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote: I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings about mallocing data w/ a lock aquired. dmesg output: malloc() of 64 with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 For what it's worth, these warnings also appear if netisr direct dispatch is enabled with the fxp(4) driver. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Software watchdog patch
On Fri, Jun 20, 2003 at 09:47:07PM -0500, Sean Kelly wrote: Greetings. I look forward to any feedback, whether positive or negative. Hello Sean, this stuff looks really promising. Anyways, I can't comment about the code as I have had no time to read it, but here are a few mdoc nitpicks I did: Index: share/man/man4/watchdog.4 === +is implemented via a trio of sysctl OIDs. When +.Va debug.watchdog.enabled Hmm, the .Va should be replaced with .Li. Also, it is necessary to remove all hard sentence breaks, ie. instead of: via a trio of sysctl OIDs. When... It should be: via a trio of sysctl OIDs. When... Sysctls should be documented using .Li. +.Sh SEE ALSO +.Xr watchdogd 8 , +.Xr sysctl 8 +.Sh HISTORY Manual pages are first ordered by their section numbers, and then alphabetically, thus watchdogd(8)'s .Xr should be after sysctl(8). +.Sh AUTHORS +.An -nosplit +The +.Nm +code and man page were written by +.An Sean Kelly Aq [EMAIL PROTECTED] . Use `manual page' instead of `man page'. Same sort of comments apply to the watchdogd(8) manual page. Hope that helps. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bus DMA for USB - compilation problems.
On Wed, Jan 15, 2003 at 10:58:04PM +0100, Thomas Moestl wrote the words in effect of:
On Wed, 2003/01/15 at 20:20:33 +, Josef Karthauser wrote:
On Wed, Jan 15, 2003 at 12:05:20PM -0800, Maxime Henrion wrote:
Josef Karthauser wrote:
I've partially ported the NetBSD busdma code for USB to FreeBSD, but
it doesn't compile, probably for a trivial reason.
Anyone fancy helping me out?
I didn't look at the patches yet, but could you give me the compilation
error you are getting ?
cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I.
-I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
-I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h
-fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
-ffreestanding -Werror /usr/src/sys/dev/usb/uhci.c
/usr/src/sys/dev/usb/uhci.c: In function `uhci_init':
/usr/src/sys/dev/usb/uhci.c:425: dereferencing pointer to incomplete type
/usr/src/sys/dev/usb/uhci.c: In function `uhci_power':
/usr/src/sys/dev/usb/uhci.c:714: dereferencing pointer to incomplete type
/usr/src/sys/dev/usb/uhci.c: In function `uhci_alloc_std':
It's failing at lines like:
UWRITE4(sc, UHCI_FLBASEADDR, DMAADDR(sc-sc_dma, 0)); /* set frame list */
The problematic is DMAADDR, and it's because the sc-sc_dma, which is
defined as usb_dma_t. This is defined in usb_port.h, and it uses
usb_dma_block which is defined in usb_mem.h. I think that it's the
usb_dma_block that is coming up as incomplete, but I'm not sure.
DMAADDR is:
#define DMAADDR(dma, o) ((dma)-block-map-dm_segs[0].ds_addr + (dma)-offs + (o))
struct usb_dma_block starts like:
typedef struct usb_dma_block {
bus_dma_tag_t tag;
bus_dmamap_t map;
However, bus_dmamap_t (like bus_dma_tag_t) is supposed to be opaque to
users of the busdma interface on FreeBSD. Our implementations enforce
this by defining it as:
typedef struct bus_dmamap *bus_dmamap_t;
, and by not exporting struct bus_dmamap in public headers.
The DMA addresses are obtained by writing an appropriate callback
routine to process them and passing it to bus_dmamap_load().
The usb_mem.c will need some other changes to work on FreeBSD, since
our busdma code has diverged from NetBSD's quite a bit.
Hiya Joe!
The caller has to specify a routine to receive the DMA segment list, and
for processing any errors occured during this period. If the operation
is delayed, than EINPROGRESS is returned. If you specify
BUS_DMA_NOWAIT, then the bus dma interface allows you to fail the
request rather the delay (no sleep) it. Neccessary prep. must be done
if you don't want bus_dmamap_load_*() to block, by setting the
BUS_DMA_ALLOCNOW flag at dma tag and map creation time.
You must also note, that the lifetime of the callback routine, should be
about the same as that of the bus_dma_segment_t array passed.
As defered from the NetBSD bus_dma interface, you can provide a filter
routine, at dma tag creation time (bus_dma_tag_create) to DMA to an
address range not accesilbe to the interface -- i.e. if such thing
happens, the routine is asked to take over the task.
The BusLogic driver is a very good driver to read for bus_dma related
things. I personally found it good, as it covers many cases. JFYI.
HTH.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: unexpected machine check on 5.0 alpha
On Thu, Jan 16, 2003 at 09:39:36AM -0800, Nate Lawson wrote the words in effect of: On Thu, 16 Jan 2003, Trevor Johnson wrote: Before adding the ccd line to my kernel configuration file, I had attempted to run ccdconfig while using just the GENERIC kernel (also 5.0-RC3). I suppos e I shouldn't have been surprised that it didn't work: -- begin log -- # ccdconfig ccd0 128 CCDF_UNIFORM /dev/da2 /dev/da3 /dev/da4 /dev/da5 fatal kernel trap: trap entry = 0x4 (unaligned access fault) cpuid = 1 faulting va= 0xe4a00ed opcode = 0x29 register = 0x1b pc = 0xfe0002bd1f1c ra = 0xfe0002bd1eec sp = 0xfe00140898a0 usp= 0x11fff9f8 curthread = 0xfc0017efe1f0 pid = 3658, comm = ccdconfig panic: trap cpuid = 1; Something in the automatic kldload then? Unaligned access is usually a programming error. I don't know how much this info can help, but I recently ported NetBSD's BUS_SPACE_DEBUG functionality, which helped them a lot in fixing unaligned access faults. The patch needs a lil' cleaning up for other architectures. Most of the drivers in FreeBSD are heavily used on i386, so it is beneficial to use BUS space debug, so that we can easily find out errors, and fix 'em. It reports someting like this: (taken from NetBSD sample) buffer address not aligned to 2 bytes ../../../../dev/ic/aic6360.c:1426 Let me know if anyone is interested in those patches. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM_METER no longer defined?
On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words in effect of:
Craig Rodrigues wrote:
On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
Of course, these things can be fixed. But I consider this change
gratuitous and it breaks standard compatability rules: deprecate
for one major version and remove in the second. I haven't seen
any reason why this couldn't be added to vm/vm_param.h:
#define VM_METER VM_TOTAL
for compatability purposes. This change is way too sudden in an
external API (if it's supposed to be internal, then protect it
with an #ifdef _KERNEL already!).
How about this then:
Index: vm_param.h
===
RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
retrieving revision 1.16
diff -u -r1.16 vm_param.h
--- vm_param.h 2003/01/11 07:29:46 1.16
+++ vm_param.h 2003/01/17 23:25:52
@@ -89,6 +89,8 @@
#define VM_SWAPPING_ENABLED 11 /* swapping enabled */
#define VM_MAXID12 /* number of valid vm ids */
+#define VM_METERVM_TOTAL /* backwards compatibility, struct vmmeter
*/
+
#define CTL_VM_NAMES { \
{ 0, 0 }, \
{ vmtotal, CTLTYPE_STRUCT }, \
The only place where VM_METER is used in this directory was in vm_meter.c:
240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, S,vmtotal,
242 System virtual memory statistics);
This changed to:
240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, S,vmtotal,
242 System virtual memory statistics);
This is ugly and only further perpetuates what appears to be a
gratuitous API
change. Let's wait to hear from the submitter (Hiten) and committer
(Matt) to
see why this was needed in the first place.
Hiten? Matt?
The change was made, because VM_METER was a bogus name for what it did.
It returned struct vmtotal, but we named it VM_METER. Infact, I tried
to push this change some long time ago, but there were complications
(people busy etc...).
I think applicatins to should be changed to use VM_TOTAL, instead of
VM_METER, because that's the correct name. This is the same issue with
the KMEM_METER define, which will be resolved once I get around to it.
I sent this change to Matt first, to check if it was right, since he is
the VM guru and whatnot. Also, the change was made quite a while ago.
Before we entered the freeze, IIRC. IMHO, backing it out will just make
more and more apps use it, and it will be totally sad -- but hey, I am
not Release Engineer, so final decision is up to you.
Cheers.
P.S. Apologies for taking long to reply, I was out party-ing. :^)
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Nuke MIN/MAX duplications
Hello.
Can someone review and commit the attached patches for me, please.
There are duplicate MIN/MAX macros all around the kernel, I think we
should simply remove the #ifndef _KERNEL from param.h, and let people
use those macros instead.
I could not LINT test this patch, because of various complications on my
machine -- it is a slow poke 166Mhz processor! Patch can also be found
at: http://www.unixdaemons.com/~hiten/work/diffs/minmax_fix.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: alpha/alpha/busdma_machdep.c
===
RCS file: /home/hiten/ncvs/src/sys/alpha/alpha/busdma_machdep.c,v
retrieving revision 1.24
diff -u -r1.24 busdma_machdep.c
--- alpha/alpha/busdma_machdep.c4 Oct 2002 20:40:39 - 1.24
+++ alpha/alpha/busdma_machdep.c18 Jan 2003 18:39:27 -
@@ -45,8 +45,6 @@
#include machine/sgmap.h
#include machine/md_var.h
-#define MAX(a,b) (((a) (b)) ? (a) : (b))
-#define MIN(a,b) (((a) (b)) ? (a) : (b))
#define MAX_BPAGES 128
struct bus_dma_tag {
Index: cam/scsi/scsi_cd.c
===
RCS file: /home/hiten/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.68
diff -u -r1.68 scsi_cd.c
--- cam/scsi/scsi_cd.c 23 Nov 2002 22:51:50 - 1.68
+++ cam/scsi/scsi_cd.c 18 Jan 2003 18:39:55 -
@@ -172,10 +172,6 @@
}
};
-#ifndef MIN
-#define MIN(x,y) ((xy) ? x : y)
-#endif
-
#define CD_CDEV_MAJOR 15
static d_open_tcdopen;
Index: cam/scsi/scsi_pass.c
===
RCS file: /home/hiten/ncvs/src/sys/cam/scsi/scsi_pass.c,v
retrieving revision 1.34
diff -u -r1.34 scsi_pass.c
--- cam/scsi/scsi_pass.c15 Aug 2002 20:54:03 - 1.34
+++ cam/scsi/scsi_pass.c18 Jan 2003 18:40:09 -
@@ -76,10 +76,6 @@
dev_t dev;
};
-#ifndef MIN
-#define MIN(x,y) ((xy) ? x : y)
-#endif
-
#define PASS_CDEV_MAJOR 31
static d_open_tpassopen;
Index: cam/scsi/scsi_targ_bh.c
===
RCS file: /home/hiten/ncvs/src/sys/cam/scsi/scsi_targ_bh.c,v
retrieving revision 1.14
diff -u -r1.14 scsi_targ_bh.c
--- cam/scsi/scsi_targ_bh.c 15 Aug 2002 20:54:03 - 1.14
+++ cam/scsi/scsi_targ_bh.c 18 Jan 2003 18:40:23 -
@@ -69,8 +69,6 @@
#define MAX_IMMEDIATE 16
#define MAX_BUF_SIZE 256 /* Max inquiry/sense/mode page transfer */
-#define MIN(a, b) ((a b) ? b : a)
-
/* Offsets into our private CCB area for storing accept information */
#define ccb_type ppriv_field0
#define ccb_descr ppriv_ptr1
Index: compat/svr4/svr4_stream.c
===
RCS file: /home/hiten/ncvs/src/sys/compat/svr4/svr4_stream.c,v
retrieving revision 1.41
diff -u -r1.41 svr4_stream.c
--- compat/svr4/svr4_stream.c 13 Jan 2003 00:28:57 - 1.41
+++ compat/svr4/svr4_stream.c 18 Jan 2003 18:41:41 -
@@ -329,9 +329,6 @@
if (len = 0 || fromsa == 0)
len = 0;
else {
-#ifndef MIN
-#define MIN(a,b) ((a)(b)?(b):(a))
-#endif
/* save sa_len before it is destroyed by MSG_COMPAT */
len = MIN(len, fromsa-sa_len);
error = copyout(fromsa,
Index: contrib/dev/oltr/if_oltr.c
===
RCS file: /home/hiten/ncvs/src/sys/contrib/dev/oltr/if_oltr.c,v
retrieving revision 1.21
diff -u -r1.21 if_oltr.c
--- contrib/dev/oltr/if_oltr.c 15 Nov 2002 00:00:14 - 1.21
+++ contrib/dev/oltr/if_oltr.c 18 Jan 2003 18:42:53 -
@@ -92,7 +92,6 @@
#define PCI_VENDOR_OLICOM 0x108D
-#define MIN(A,B) (((A) (B)) ? (A) : (B))
#define MIN3(A,B,C) (MIN(A, (MIN(B, C
char *AdapterName[] = {
Index: contrib/ipfilter/netinet/ip_proxy.c
===
RCS file: /home/hiten/ncvs/src/sys/contrib/ipfilter/netinet/ip_proxy.c,v
retrieving revision 1.20
diff -u -r1.20 ip_proxy.c
--- contrib/ipfilter/netinet/ip_proxy.c 28 Aug 2002 13:41:36 - 1.20
+++ contrib/ipfilter/netinet/ip_proxy.c 18 Jan 2003 18:43:09 -
@@ -84,10 +84,6 @@
extern KRWLOCK_T ipf_nat, ipf_state;
#endif
-#ifndef MIN
-#define MIN(a,b)(((a)(b))?(a):(b))
-#endif
-
static int appr_fixseqack __P((fr_info_t *, ip_t *, ap_session_t *, int ));
Index: dev/advansys/advlib.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/advansys/advlib.c,v
retrieving revision 1.17
diff -u -r1.17 advlib.c
--- dev/advansys/advlib.c 15 Oct 2000 14:17:58 - 1.17
+++ dev/advansys/advlib.c 18 Jan 2003 18:43:24 -
@@ -1170,8 +1170,6 @@
period = dummy_period;
}
-#define MIN
Re: vnode locking question.
On Thu, Feb 06, 2003 at 10:53:08AM -0800, Julian Elischer wrote the words in effect of: On Thu, 6 Feb 2003, John Baldwin wrote: On 05-Feb-2003 Julian Elischer wrote: Is there ever a case when a vnode is locked for longer than the duration of the syscall that locked it? Shouldn't be. That would be a bug I believe. Userland threads should never hold any kernel locks. That's what I think too but I just thought I'd ask.. (NFS worries me a bit) If It did, wouldn't that give a panic() with something like: panic: mutex held on exit to userland... ... or something like that? -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM and Extended Slices
Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel. This is sorta bad, but I can bare for now. Also, I tried searching the sys/geom/ tree if there was anything relating to this, but could not find anything for `grep -i extend`. So, is it just me, or is this is a problem? -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and Extended Slices
On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel... I've been using extended slices on both -stable and -current for quite a while without any problems, both with and without GEOM. How were the extended slices created? The extended slices were created before FreeBSD 4.3 was installed on my machine. After that, I just kept building world and kernel and upgraded to 5.0. It used to work before GEOM, but then it suddenly stopped. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and Extended Slices
On Sat, Feb 08, 2003 at 06:03:53AM -0800, walt wrote the words in effect of: Hiten Pandya wrote: On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel... I've been using extended slices on both -stable and -current for quite a while without any problems, both with and without GEOM. How were the extended slices created? The extended slices were created before FreeBSD 4.3 was installed on my machine. After that, I just kept building world and kernel and upgraded to 5.0. It used to work before GEOM, but then it suddenly stopped. I just noticed that there are a bunch of GEOM options in /usr/src/sys/conf/GENERIC that I was not using in my custom kernel. I just added several of them that seem at least vaguely appropriate to my machine (I don't know what any of them actually are for, however). Extended slices are still working okay with the new options added. Are you using any of them in your kernel? Nop, no additional GEOM related options. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kld problem ? (was: Re: MSDOSFS wastes 256k when nothing is mounted!)
On Sun, Feb 09, 2003 at 10:16:21PM +0200, Alexey Zelkin wrote the words in effect of:
hi,
On Sun, Feb 09, 2003 at 08:39:59PM +0100, Poul-Henning Kamp wrote:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
BTW, it reminds me a problem I found last month. If you've MSDOSFS
compiled in kernel and try to load msdosfs.ko with loader -- then
you're 100% will hit into 'mutex already initialized' (or something
like that) panic later in boot process. (i.e. msdosfs_init() is called
twice for some reason)
I not sure if it's applicable to KLDs at all or to msdosfs only.
This also happens when the Linux kernel module is loaded twice.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Best method to produce patches?
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote the words in effect of: I am about to try to make some changes to FreeBSD current... Should I begin to use read-only CVS instead of CVSup for this work or is it possible to generate diffs based on CVSup'd sources? What is the recommend method to use for playing with the source? I already found a small change in libc that should probably get committed but I want to generate the patch properly for everyone's approval. Checkout the development(7) manual page, written by Matt Dillon. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig problems
On Thu, Feb 13, 2003 at 02:08:30PM -0700, [EMAIL PROTECTED] wrote the words in effect of: -su-2.05b# mdconfig -a -t vnode -f filesys mdconfig: ioctl(/dev/mdctl): No such file or directory -su-2.05b# ls /dev/md* /dev/mdctl -su-2.05b# why does that happen? I'm doing everything the handbook says to... Do you actually have the file, 'filesys'? The argument to -f is meant to be the name of a file used as a backing store. Something like thse might help you: # dd if=/dev/zero of=/tmp/mdstore bs=1m count=50 (50M zero'd file created) # mdconfig -a -t vnode -f /tmp/mdstore (used file for backing...) # ls /dev/md* /dev/mdctl /dev/md0 ... Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KASSERT's for vfs_{get,copy}opt()
Hello everyone. This not something major, but I recently experienced
panics in some of my old QNX4 filesystem porting code, and an old 5.0
kernel with UNIONFS problems.
The kernel will panic if vfs_get/copyopt() was passed 'opts' as NULL.
It would be good to add KASSERT's to these calls. I have passed this
patch around on IRC, and have not seen any objections.
Can the right maintainer of sys/kern/vfs_mount.c commit/review the
patch attached with this mail. Also available from:
http://www.unixdaemons.com/~hiten/work/diffs/vfs_mount.c.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: sys/kern/vfs_mount.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_mount.c,v
retrieving revision 1.97
diff -u -r1.97 vfs_mount.c
--- sys/kern/vfs_mount.c21 Jan 2003 08:55:55 - 1.97
+++ sys/kern/vfs_mount.c14 Feb 2003 09:40:18 -
@@ -1714,6 +1714,9 @@
{
struct vfsopt *opt;
+ KASSERT(opts != NULL,
+ (vfs_getopt: caller passed 'opts' as NULL\n));
+
TAILQ_FOREACH(opt, opts, link) {
if (strcmp(name, opt-name) == 0) {
if (len != NULL)
@@ -1742,6 +1745,9 @@
int len;
{
struct vfsopt *opt;
+
+ KASSERT(opts != NULL,
+ (vfs_copyopt: caller passed 'opts' as NULL\n));
TAILQ_FOREACH(opt, opts, link) {
if (strcmp(name, opt-name) == 0) {
Re: FreeBSD 5, Samba and ACL support
On Fri, Feb 14, 2003 at 03:37:50PM -0800, Terry Lambert wrote the words in effect of: local.freebsd.current wrote: I've been hanging on for a production-ready FreeBSD which supports ACLs so I can replace an NFS server and an NT fileserver with one box which can do both. Changing company circumstances mean that I am forced to look to doing that now, rather than waiting for 5.1 or 5.2. So I'd appreciate feedback from anyone who is using 5.0 as a Samba server with ACL support - is it indistinguishable from an NT fileserver from the client POV? ACLs in UFS are not the same thing as ACLs in NT, they are POSIX ACLs, implement as part of MAC (Mandatory Access Controls) requirements. Do not expect them to interoperate with Samba as if Samba were an NT server that supported NT ACLs. Same thing for ACLs in Linux and other UNIX OS's, BTW: they tend to comply with the POSIX standard, not with the NT stuff, for which I don't think there is a published standard (only documentation). Erm, Terry, I think jedgar@ got ACL's working with Windows NT and so did I (think) in one of my Samba+ACL's test. Please check the following URL(s) regarding Samba+ACLs: - http://people.freebsd.org/~jedgar/ACL/ - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html - http://samba.mirror.ac.uk/samba/whatsnew/samba-2.2.6.html Samba 2.2.6 should work with ACLs with an 'external patch'. See it's release notes for more information. Hope that helps. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: working ACPI vs broken ACPI
On Sat, Feb 15, 2003 at 08:27:45PM -0600, Mike Silbersack wrote the words in effect of: On Sat, 15 Feb 2003, Martin Blapp wrote: Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block1 defined as GPE32 to GPE63 I see similar errors on my Presario 2100US... Wild guess: Seem to result from this. If I'm looking at NetBSD's http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c they have a lot done since they took acpi from us. I'm sure it works for netbsd. Is anybody working on this ? Martin I've been trying to load that URL since yesterday, but it's not working from here. Can you elaborate on what it does? Try the following URL: - http://cvsweb.no.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
On Thu, Feb 13, 2003 at 04:36:20PM -0800, Scott Long wrote the words in effect of: - Benchmarks and performance testing - Having a source of reliable and useful benchmarks is essential to identifying performance problems and guarding against performance regressions. A 'performance team' that is made up of people and resources for formulating, developing, and executing benchmark tests should be put into place soon. Comparisons should be made against both FreeBSD 4.x and Linux 2.4.x. Tests to consider are: - the classic 'worldstone' - webstone - /usr/ports/www/webstone - Fstress - http://www.cs.duke.edu/ari/fstress - ApacheBench - /usr/ports/www/p5-ApacheBench - netperf - /usr/ports/benchmarks/netperf There is a possibilty that we can use the MMap benchmark tool from the Linux 'vmregress' suite of benchmarks. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reproducable ACPI hang on 5.0-RELEASE + Asus A7V mobo
The Anarcat (Mon, Feb 17, 2003 at 08:09:05PM -0500) wrote: On Tue Feb 18, 2003 at 12:19:35AM +, Bruce Cran wrote: ACPI power management on Asus motherboards with the VIA chipset seems to be quite broken. On my A7V333 I can use mode 1 (CPU off), 2 and 3 report AE_NOT_FOUND and 4 dumps the cpu registers, while power-off on shutdown reports an ACPI timeout error. I can power-off on shutdown (halt -p acpiconf -s 5, if I understand this correctly). mode 1 doesn't seem to do anything, but that might just be because I can't notice the CPU stopped. 3 actually halts the drives and the fans, but powering evrything back up gives me a nice freeze. 4 just hangs. I don't think the S4 (-s4) state is supported, but I may be wrong. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
machdep.guessed_bootdev sysctl on i386
Hello gang. Nothing big, but important...
Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at
all? I think it's a waste, and it's pretty limited and only available
on the i386.
It currently guesses 'wd' instead of 'ad' for the dev. nodes, .e.g:
hiten:~/ sysctl machdep.gussed_bootdev
machdep.guessed_bootdev: /dev/wd0s1a
SCSI drives are shown right (da) but ATA drives mess up, i.e. it is
still thinking we have the 'wd' system. It's either that we nuke this
sysctl or apply the attached patch to sysctl, which has been reviewed
and tested by people on IRC with positive results.
Comments / objections appreciated.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: src/sbin/sysctl/sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.51
diff -u -r1.51 sysctl.c
--- src/sbin/sysctl/sysctl.c22 Jan 2003 00:34:22 - 1.51
+++ src/sbin/sysctl/sysctl.c22 Feb 2003 14:21:13 -
@@ -460,9 +460,7 @@
int majdev;
char *name;
} maj2name[] = {
- 30, ad,
- 0, wd,
- 1, wfd,
+ 0, ad,
2, fd,
4, da,
-1, NULL/* terminator */
Re: machdep.guessed_bootdev sysctl on i386
[EMAIL PROTECTED] (Mon, Feb 24, 2003 at 07:10:59AM +0100) wrote:
In message [EMAIL PROTECTED], Hiten Pandya writes:
--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello gang. Nothing big, but important...
Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at
all? I think it's a waste, and it's pretty limited and only available
on the i386.
It isn't and it should be deleted I think.
Okay. I have attached a patch which will nuke the sysctl, and replace
it's use in picobsd's mfs_tree rc scripts with something better, but
which still needs review. I have not tested the patch, but this patch
should not fail, hopefully.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: src/release/picobsd/mfs_tree/etc/rc
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/etc/rc,v
retrieving revision 1.9
diff -u -r1.9 rc
--- src/release/picobsd/mfs_tree/etc/rc 17 Nov 2002 20:19:34 - 1.9
+++ src/release/picobsd/mfs_tree/etc/rc 24 Feb 2003 06:21:31 -
@@ -7,7 +7,7 @@
HOME=/; export HOME
PATH=/bin; export PATH
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
trap echo 'Reboot interrupted'; exit 1 3
Index: src/release/picobsd/mfs_tree/stand/update
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/stand/update,v
retrieving revision 1.5
diff -u -r1.5 update
--- src/release/picobsd/mfs_tree/stand/update 11 Mar 2002 05:15:44 - 1.5
+++ src/release/picobsd/mfs_tree/stand/update 24 Feb 2003 06:20:08 -
@@ -5,7 +5,7 @@
thefiles=$*
[ -z $thefiles ] \
thefiles=/etc/rc.conf /etc/rc.firewall /etc/master.passwd
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
mount ${dev} /mnt
if [ $? != 0 ] ; then
Index: src/sbin/sysctl/sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.51
diff -u -r1.51 sysctl.c
--- src/sbin/sysctl/sysctl.c22 Jan 2003 00:34:22 - 1.51
+++ src/sbin/sysctl/sysctl.c24 Feb 2003 06:05:01 -
@@ -451,55 +451,6 @@
return 0;
}
-#ifdef __i386__
-/*
- * Code to map a bootdev major number into a suitable device name.
- * Major numbers are mapped into names as in boot2.c
- */
-struct _foo {
- int majdev;
- char *name;
-} maj2name[] = {
- 30, ad,
- 0, wd,
- 1, wfd,
- 2, fd,
- 4, da,
- -1, NULL/* terminator */
-};
-
-static int
-machdep_bootdev(u_long value)
-{
- int majdev, unit, slice, part;
- struct _foo *p;
-
- if (value B_MAGICMASK != B_DEVMAGIC) {
- printf(invalid (0x%08x), value);
- return 0;
- }
- majdev = B_TYPE(value);
- unit = B_UNIT(value);
- slice = B_SLICE(value);
- part = B_PARTITION(value);
- if (majdev == 2) { /* floppy, as known to the boot block... */
- printf(/dev/fd%d, unit);
- return 0;
- }
- for (p = maj2name; p-name != NULL p-majdev != majdev ; p++) ;
- if (p-name != NULL) { /* found */
- if (slice == WHOLE_DISK_SLICE)
- printf(/dev/%s%d%c, p-name, unit, part);
- else
- printf(/dev/%s%ds%d%c,
- p-name, unit, slice - BASE_SLICE + 1, part + 'a');
- } else
- printf(unknown (major %d unit %d slice %d part %d),
- majdev, unit, slice, part);
- return 0;
-}
-#endif
-
/*
* This formats and outputs the value of one variable
*
@@ -593,10 +544,6 @@
if (!nflag)
printf(%s%s, name, sep);
fmt++;
-#ifdef __i386__
- if (!strcmp(name, machdep.guessed_bootdev))
- return machdep_bootdev(*(unsigned long *)p);
-#endif
val = ;
while (len = sizeof(long)) {
if(*fmt == 'U')
Index: src/sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.554
diff -u -r1.554 machdep.c
--- src/sys/i386/i386/machdep.c 20 Feb 2003 05:35:52 - 1.554
+++ src/sys/i386/i386/machdep.c 24 Feb 2003 06:03:34 -
@@ -1175,10 +1175,6 @@
SYSCTL_INT(_machdep, CPU_WALLCLOCK, wall_cmos_clock,
CTLFLAG_RW, wall_cmos_clock, 0, );
-u_long bootdev;/* not a dev_t - encoding is different */
-SYSCTL_ULONG(_machdep, OID_AUTO, guessed_bootdev,
- CTLFLAG_RD, bootdev, 0, Maybe the Boot device (not in dev_t format));
-
/*
* Initialize 386
Re: machdep.guessed_bootdev sysctl on i386
Bruce Evans (Mon, Feb 24, 2003 at 06:27:26PM +1100) wrote: On Mon, 24 Feb 2003, I wrote: I tested with plain -current and old boot blocks. The sysctl still reports ad disks correctly. I don't care about the sysctl but want to keep the boot blocks as backwards compatible as possible. That means passing the boot device in the old encoding, which only takes a couple of lines of code. Current kernels ignore this and use a device name passed in the environment. This is presumably returned by the kenv syscall although not by a sysctl, so the sysctl is certainly not needed. I didn't test this since my boot blocks are too old and simple to pass an environment. They pass the device name more directly. Ok, I don't want to change the encoding or anything, but I think the sysctl should be nuked. Please see my later post to this thread, I have provided a patch. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
Craig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
The code in question looks like:
=
struct mbuf *
copy_mbuf(struct mbuf *m)
{
struct mbuf *new;
MGET(new, M_DONTWAIT, MT_DATA);
if(new == NULL)
return NULL;
if(m-m_flags M_PKTHDR)
M_COPY_PKTHDR(new, m);
What you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
deprecated for several reasons, that are outlined in the
commit log of rev. 1.109 of sys/sys/mbuf.h.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
Harti Brandt (Mon, Feb 24, 2003 at 08:46:13PM +0100) wrote:
On Mon, 24 Feb 2003, Hiten Pandya wrote:
HPCraig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
HP The code in question looks like:
HP =
HP struct mbuf *
HP copy_mbuf(struct mbuf *m)
HP {
HP struct mbuf *new;
HP
HP MGET(new, M_DONTWAIT, MT_DATA);
HP if(new == NULL)
HP return NULL;
HP if(m-m_flags M_PKTHDR)
HP M_COPY_PKTHDR(new, m);
HP
HPWhat you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
HPdeprecated for several reasons, that are outlined in the
HPcommit log of rev. 1.109 of sys/sys/mbuf.h.
I wrote that code. It must be a M_MOVE_PKTHDR, because m is just disposed
afterwards.
OK. This was mentioned in the comment in sys/mbuf.h and the commit log
too. :-)
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Possible patch for limiting APs at startup
Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. Before: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 ... Launch AP CPUs etc ... After: boot-prompt set machdep.smp_cpus=0 boot-prompt boot -sv FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 Patch attached with mail. Cheers. P.S. One more question, there are some extern variables in the i386/include/smp.h header file, and I don't think they are used anywhere in an extern way... can comment on patch available at the following location: http://www.unixdaemons.com/~hiten/work/diffs/eremove.patch -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ Index: sys/i386/i386/mp_machdep.c === RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.203 diff -u -r1.203 mp_machdep.c --- sys/i386/i386/mp_machdep.c 24 Feb 2003 14:36:03 - 1.203 +++ sys/i386/i386/mp_machdep.c 2 Mar 2003 01:25:10 - @@ -278,6 +278,9 @@ int io_num_to_apic_id[NAPICID]; int apic_id_to_logical[NAPICID]; +TUNABLE_INT(machdep.smp_cpus, (int *)mp_naps); +SYSCTL_INT(_machdep, OID_AUTO, smp_cpus, CTLFLAG_RD, +mp_naps, 1, Number of Application processors in use.); /* AP uses this during bootstrap. Do not staticize. */ char *bootSTK;
Re: busdma documentation
Harti Brandt (Mon, Feb 24, 2003 at 11:41:57AM +0100) wrote: On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: DSis there any? if so, where? Hiten Pandya was/is working on this. Last time I had a look it had not much moved from NetBSD towards FreeBSD. Don't know about the current state: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch I am still working on it, and the URLs provided above are old. The new URL to busdma documentation stuff, is: http://www.unixdaemons.com/~hiten/work/busdma/ There are some issues I am sorting out, and you can check my progress with the TODO list in the directory. It will be finished sometime this week as I was busy last week with other things, like school etc. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NTP server change
Hi gang.
Can anyone who is into timekeeping, and lives in or near Finland let me
know if they approve of a change to sysinstall, which will allow us to
use an alternate time keeping NTP server -- the reason for doing this is
outlined in PR conf/46235.
Patch URL:
http://www.unixdaemons.com/~hiten/work/diffs/sysinstall-46235.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.368
diff -u -r1.368 menus.c
--- menus.c 2003/02/03 16:14:33 1.368
+++ menus.c 2003/02/03 17:54:31
@@ -1754,12 +1754,12 @@
{ Spain, slug.ctv.es,
dmenuVarsCheck, dmenuSetVariables, NULL,
ntpdate_enable=YES,ntpdate_flags=slug.ctv.es },
- { Finland, tick.keso.fi,
+ { Finland, time1.mikes.fi,
dmenuVarsCheck, dmenuSetVariables, NULL,
- ntpdate_enable=YES,ntpdate_flags=tick.keso.fi },
- { Finland #2, tock.keso.fi,
+ ntpdate_enable=YES,ntpdate_flags=time1.mikes.fi },
+ { Finland #2, time2.mikes.fi,
dmenuVarsCheck, dmenuSetVariables, NULL,
- ntpdate_enable=YES,ntpdate_flags=tock.keso.fi },
+ ntpdate_enable=YES,ntpdate_flags=time2.mikes.fi },
{ France, ntp.obspm.fr,
dmenuVarsCheck, dmenuSetVariables, NULL,
ntpdate_enable=YES,ntpdate_flags=ntp.obspm.fr },
Re: Possible patch for limiting APs at startup
John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: On 02-Mar-2003 Juli Mallett wrote: * De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Possible patch for limiting APs at startup ] Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. I think your use of cpus to refer to APs only is silly, and also that overriding mp_naps instead of using a real cpus value and using it as a bounds check akin to MAXCPU, is a bit of the wrong direction. As you know, the following is my patch, and it does not work, but I think, personally, the behaviour is saner, in theory at least :) You should set mp_maxcpus prior to the mp_naps test so it isn't left invalid in the common case. Also, this patch doesn't limit HT cpu's at all. I could have a 4 cpu system with HTT and maxcpus=2, and I will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps this is intentional? Yes. It was intentional, in the sense that we only want to limit the number of Application Processors, and not the HTT cores inside it, because that does not make much sense, IMHO. Do you think that patch will be committed, or does it need improving? (http://www.unixdaemons.com/~hiten/work/diffs/mp_machdep.c.patch) Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Petri Helenius (Wed, Mar 05, 2003 at 01:42:05AM +0200) wrote:
This does look odd... maybe there's a leak somewhere... does in use
go back down to a much lower number eventually? What kind of test are
you running? in pool means that that's the number in the cache
while in use means that that's the number out of the cache
currently being used by the system; but if you're telling me that
there's no way usage could be that high while you ran the netstat,
either there's a serious leak somewhere or I got the stats wrong
(anyone else notice irregular stats?)
I think I figured this, the em driver is allocating mbuf for each receive
descriptor regardless if it?s needed or not. Does this cause a performance
issue if there is 8000 mbufs in use and we get 100k-150k frees and
allocates a second (for every packet?)
(I have the em driver configured for 4096 receive descriptors)
While you are there debugging mbuf issues, you might also want to try
this patch:
%%%
Index: sys/dev/em/if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.19
diff -u -r1.19 if_em.c
--- sys/dev/em/if_em.c 19 Feb 2003 05:47:03 - 1.19
+++ sys/dev/em/if_em.c 4 Mar 2003 23:49:02 -
@@ -1802,15 +1802,10 @@
ifp = adapter-interface_data.ac_if;
if (mp == NULL) {
- MGETHDR(mp, M_DONTWAIT, MT_DATA);
+ mp = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
if (mp == NULL) {
adapter-mbuf_alloc_failed++;
- return(ENOBUFS);
- }
- MCLGET(mp, M_DONTWAIT);
- if ((mp-m_flags M_EXT) == 0) {
m_freem(mp);
- adapter-mbuf_cluster_failed++;
return(ENOBUFS);
}
mp-m_len = mp-m_pkthdr.len = MCLBYTES;
%%%
This is sort of an optimization. It reduces locking operations, and
will be making calling less routnes overall. It would be beneficial to
know the profiling and performance results of this patch.
I?m running a snort-like application with the interface getting receive only
packets. It can either connect to a netgraph node or use bpf, both seem to have
similar performance (most CPU is used elsewhere) as the email I sent previously
had listed.
This code from 'em' driver worries me a bit:
if (em_get_buf(i, adapter, NULL) == ENOBUFS) {
adapter-dropped_pkts++;
em_get_buf(i, adapter, mp);
if (adapter-fmp != NULL)
m_freem(adapter-fmp);
adapter-fmp = NULL;
adapter-fmp = NULL;
}
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Hiten Pandya (Tue, Mar 04, 2003 at 07:01:15PM -0500) wrote:
Petri Helenius (Wed, Mar 05, 2003 at 01:42:05AM +0200) wrote:
This does look odd... maybe there's a leak somewhere... does in use
go back down to a much lower number eventually? What kind of test are
you running? in pool means that that's the number in the cache
while in use means that that's the number out of the cache
currently being used by the system; but if you're telling me that
there's no way usage could be that high while you ran the netstat,
either there's a serious leak somewhere or I got the stats wrong
(anyone else notice irregular stats?)
I think I figured this, the em driver is allocating mbuf for each receive
descriptor regardless if it?s needed or not. Does this cause a performance
issue if there is 8000 mbufs in use and we get 100k-150k frees and
allocates a second (for every packet?)
(I have the em driver configured for 4096 receive descriptors)
While you are there debugging mbuf issues, you might also want to try
this patch:
Oops, my first patch had some bugs because of quick editing. Please try
the newer patch:
http://www.unixdaemons.com/~hiten/work/mbuf/if_em.c.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: sys/dev/em/if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.19
diff -u -r1.19 if_em.c
--- sys/dev/em/if_em.c 19 Feb 2003 05:47:03 - 1.19
+++ sys/dev/em/if_em.c 5 Mar 2003 00:17:05 -
@@ -1802,17 +1802,11 @@
ifp = adapter-interface_data.ac_if;
if (mp == NULL) {
- MGETHDR(mp, M_DONTWAIT, MT_DATA);
+ mp = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
if (mp == NULL) {
adapter-mbuf_alloc_failed++;
return(ENOBUFS);
}
- MCLGET(mp, M_DONTWAIT);
- if ((mp-m_flags M_EXT) == 0) {
- m_freem(mp);
- adapter-mbuf_cluster_failed++;
- return(ENOBUFS);
- }
mp-m_len = mp-m_pkthdr.len = MCLBYTES;
} else {
mp-m_len = mp-m_pkthdr.len = MCLBYTES;
@@ -2410,8 +2404,6 @@
adapter-no_tx_desc_avail2);
printf(em%d: Std Mbuf Failed = %ld\n,unit,
adapter-mbuf_alloc_failed);
- printf(em%d: Std Cluster Failed = %ld\n,unit,
- adapter-mbuf_cluster_failed);
printf(em%d: Symbol errors = %lld\n, unit,
(long long)adapter-stats.symerrs);
Index: sys/dev/em/if_em.h
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.12
diff -u -r1.12 if_em.h
--- sys/dev/em/if_em.h 23 Dec 2002 19:11:23 - 1.12
+++ sys/dev/em/if_em.h 5 Mar 2003 00:20:57 -
@@ -366,7 +366,6 @@
/* Misc stats maintained by the driver */
unsigned long dropped_pkts;
unsigned long mbuf_alloc_failed;
- unsigned long mbuf_cluster_failed;
unsigned long no_tx_desc_avail1;
unsigned long no_tx_desc_avail2;
#ifdef DBG_STATS
Re: Removal of netns - politically correct version
Terry Lambert (Wed, Mar 05, 2003 at 04:15:11AM -0800) wrote: Tony Finch wrote: The details might be different but not enough to confuse a competent programmer. Same argument, in favor of the netns code. It's a moot point anyway, I just fixed netns. Sorry to but in, but I don't see why this so called bikesheed keeps getting bigger and bigger. The outcome is simple. If your patches function properly, then there is no need to remove netns provided you don't mind maintaining it. If it doesn't have a maintainer, then just apply your fixes and shuv it in the Attic so it's less horid when someone wants to restart the effort of maintaining it. Not that I can do anything about it, but I can't see why this discussion is getting bigger and bigger for no reason. Cheers. PS. Just my 2 cents. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns
Julian Elischer (Tue, Mar 04, 2003 at 02:53:56PM -0800) wrote: I thought nwfs used it? On Wed, 5 Mar 2003, Tim Robbins wrote: Is there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? That's netncp if I am not mistaken and thanks to Tim and Max Khon, it's now fixed, IIRC. Kudos to them. :-) -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Loopback device dillema
Hi gang. As I was playing around with the mbuf code, and came across the loopback device code (if_loop.c). Despite it's ugliness and shoddy code which came with the KAME stuff. Well, the problem is that it's not possible to compile the kernel when you remove the loop device from your config, because of the if_simloop changes that julian made some time ago (revision 1.33 of if_loop.c). So, shall we make if_loop.c the default, and not have a 'device loop' option, or does someone want to take the time of cleaning up the mess in the case when 'device loop' is not in the config? I have cleaned up the if_simloop case in my local tree by moving it into if.c as it's a pretty generic routine used in various files, but now the problem comes in how 'loif' is used in netinet/if_ether.c and netinet/igmp.c. To conclude, I would like to see the loopback device made default, and if this is not agreed upon, then someone needs to fix case when loopback device is not in the kernel config, and is going to be loaded as a module. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Loopback device dillema
Brooks Davis (Thu, Mar 06, 2003 at 11:00:11AM -0800) wrote: On Thu, Mar 06, 2003 at 01:38:54PM -0500, Hiten Pandya wrote: To conclude, I would like to see the loopback device made default, and if this is not agreed upon, then someone needs to fix case when loopback device is not in the kernel config, and is going to be loaded as a module. What is gained by making loopback default? It's true that you need a loopback device, but that's a bug not a feature. Right, I do not have a problem with that, but that just means someone needs to fix that in netinet/if_ether.c, and netinet/igmp.c. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Loopback device dillema
Brooks Davis (Thu, Mar 06, 2003 at 11:15:16AM -0800) wrote:
Not to mention:
netinet6/{in6_pcb.c,in6_src.c,ip6_input.c,ip6_output.c,nd6.c}
What is gained by making loopback default?
Nothing is gained. But it's neccessary fix this, IMHO. Not to mention
that our loopback device code looks terribly ugly anyway. :-)
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: xl: discard frame without packet header
Juli Mallett (Fri, Mar 07, 2003 at 12:18:38AM -0600) wrote: This fixed yet? xl0: discard frame w/o packet header Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01fbcf8 stack pointer = 0x10:0xc5d6fc34 frame pointer = 0x10:0xc5d6fc58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 20 (irq10: xl0) trap number = 12 panic: page fault If not I'll be able to take a quick stab at it tomorrow. Right. This has been fixed in revision 1.31 of if_xl.c. Update your sources, and you should be fine. Cheers. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV lost in 5.0-CURRENT?
Hartmann, O. (Wed, Mar 12, 2003 at 04:59:52PM +0100) wrote: On Wed, 12 Mar 2003, Sergey A. Osokin wrote: :On Wed, Mar 12, 2003 at 04:44:25PM +0100, Hartmann, O. wrote: : Where are the MAKEDEV and MAKEDEV.local scripts in 5.0-CURRENT? : I cvsupdate today last time and did a find through /usr/src, : but I can not find both script ... : :MAKEDEV is dead, baby. MAKEDEV is dead (c) paraphrase from Pulp Fiction :Long live devfs(8) :-) :Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/48038 : :Committers still have no time for commit this :-) : :-- : :Rgdz,/\ ASCII RIBBON CAMPAIGN :Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL :http://ozz.pp.ru/ X AND NEWS : / \ : Ouch ;-)) All right, a new 'think another way when going to FreeBSD 5.0 ...'. It also helps when you read src/UPDATING :-) NODEVFS option has been removed and DEVFS thereby made standard. This makes all references to MAKEDEV obsolete, and they should be removed when convenient. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ENOMEM error diagnosis?
Lucky Green (Fri, Mar 14, 2003 at 06:40:58PM -0800) wrote:
I am seeing a lot of crashes of GBDE, causing ENOMEM errors to scroll
rapidly on the console. Whenever this happens, the server becomes
unresponsive to keyboard or any other input and has to be power cycled.
Is there some debug setting that I can set which would help diagnose the
problem further? This is on a minimally-loaded test machine with no
other users and no significant load from any services.
I stumbled upon this problem when I was messing around with the
swapoff() system call and /dev/md. If you do the following:
# swapoff all-swap-devices (one after another...
# mdconfig -a -t swap -s 30M -u 3
# newfs /dev/md0
(nice unkillable loop)
So, doing some research indicates that one way of fixing this
problem was to detect if swap was available at all, in the
md{start,done}_swap() routines, but not sure if that is the best
fix.
The ENOMEM error occurs in geom_io.c:g_io_deliver(). I have not
familiarized myself with the GEOM code yet, but I could get a
stack trace by just shoving panic() into g_io_deliver(). If you
are running X or some sort of window system, you will not be
able to use it, as Lucky Green said, it will be just hang.
Going into DDB will not help because it hasn't crashed, and even
doing so, will just give you a trace of the fork_trampoline(),
ithd_loop() stuff... i.e. nothing which helps with the problem.
The error looks like:
ENOMEM (0xsome-addr) on (0xsome-addr)... in my case.
Cheers.
-- Hiten
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
SI_SUB_RAID and SI_SUB_VINUM
Hi Gang! I was wondering, what's the point of making Vinum use a totally different SYSINIT type? Isn't there a possibility it can just use SI_SUB_RAID? Cheers. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
checking in...
hello all, please tell me if i have done something wrong but... i have installed 5.0-CURRENT as of the latest CVS copy of 7.00pm GMT British Time.. it all works fine... but.. i think there is a problem witht the linux compatibility.. although i am not a very much of a programmer (yet).. but... it seems that linux-netscape* dont seem to be working properly.. thanks... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[SUGGESTION] - disallowing shutdown after su(1)
hi all, correct me if i am wrong.. but.. do you think, if we denied a shutdown after an su(1) to root from a non-privileged user would be good... i tried this same thing at home.. i builded it and installed it.. works fine for me... the patch below will allow a shutdown only be logging into root itself and not by issuing an su(1) command to root. this would be very good, i think if someone broke into a normal user and was able to gain access into root using su... (without a password..) i am submitting a tar.gz file, which has the patch for the shutdown.8 manpage, and shutdown.c located at.. src/sbin/shutdown.c... thanks... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 shutdown.tar.gz Description: shutdown.tar.gz
Re: [SUGGESTION] - disallowing shutdown after su(1)
its ok... but is there a list of problems that are awaiting to be resolved in the CURRENT branch... thanks... --- Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Hiten Pandya writes: hi all, correct me if i am wrong.. but.. do you think, if we denied a shutdown after an su(1) to root from a non-privileged user would be good... i tried this same thing at home.. i builded it and installed it.. works fine for me... the patch below will allow a shutdown only be logging into root itself and not by issuing an su(1) command to root. this would be very good, i think if someone broke into a normal user and was able to gain access into root using su... (without a password..) i am submitting a tar.gz file, which has the patch for the shutdown.8 manpage, and shutdown.c located at.. src/sbin/shutdown.c... I think this idea have no any sence because beeing root you CAN shutdown machine not depending on how you became root. few examples: # kill -USR2 (see init(8) - halt) build fresh shutdown halt -q so ... thanks... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with 'make buildworld' on current
hi, how bout removing your old source tree, and replacing it with the CURRENT one... thats how i resolved issues with my buildoworld process.. although this does sound daft... so... try that... or.. what you can do is... update your src tree to 4.4, and then update it to CURRENT... that might work... thanks... --- Landon Stewart [EMAIL PROTECTED] wrote: When I do a make buildworld I get an error about an incomplete type for field 'inc4_route'. I've read the /usr/src/UPDATING and found no real references to this type of problem. Am I jumping too far between 4.3-REL and current? Do I need some compile options? Do I need the compat4.x.i386 installed? Any other ideas? # uname -a FreeBSD pirahna.awe-full.com 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 === usr.bin/systat cc -nostdinc -O -pipe -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/systat/cmds.c ... snip ... cc -nostdinc -O -pipe -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/systat/tcp.c In file included from /usr/obj/usr/src/i386/usr/include/netinet/tcp_var.h:40, from /usr/src/usr.bin/systat/tcp.c:56: /usr/obj/usr/src/i386/usr/include/netinet/in_pcb.h:106: field `inc4_route' has incomplete type *** Error code 1 4 error codes follow this one, all the same, and then a stop in /usr/src. = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: some info (new)
hi maxime... thanks very very much.. now i get it..., its like.. a mutex is a lock, which is used when things are done in parralel and to avoid corruption of the data which is being processed... i took an example of the way i used to lock files in PERL, in order to avoid multiple writes at the same time... one more question... if there is a lock order reversal.. is there a way that can be solved.. for e.g. by using on of the MTX_XX things... thanks... regards... Hiten Pandya [EMAIL PROTECTED] --- Maxime Henrion [EMAIL PROTECTED] wrote: Hiten Pandya wrote: hi all, sorry for running -current.. but i am an enthusiastic and challenging man...(boy)... anyways.. whats a mutex and a lock order reversal... if you could point to some good manual on these subjects... thanks... help is appreciated... thanks again... A mutex is an algorithmic object used to serialize operations. It stands for ``mutual exclusion''. It's useful when the same code is ran several times in parallel. For example, if two threads wanted to modify a linked list in the same time, there is a chance that the linked list would get corrupted since an insert or remove operation is not atomic (one of the thread could get preempted when it has not finished to remove or insert an element, and thus the linked list is not in a normal state). In such cases, every part of the code that modify the linked list has to obtain the mutex before doing it and release after. If another thread tries to acquire the mutex, it will block until the first thread has released it. When some code has to obtain two locks or more, deadlocks might happen. If thread 1 has lock A and tries to acquire lock B while thread 2 has lock B and wants lock A, then both threads will block indefinitely. To solve this, one way is to always obtain the lock in the same order. The warning messages you got show that some code is violating this lock order somewhere. I found ``Unix Internals'' from Uresh Vahalia to be a very good book on this topic. Hope this helps, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: some info (new)
MH The lock order verification is not part of the mtx MH API. It's debugging MH stuff activated by default in -CURRENT. If you do MH not want to see these MH warnings, remove ``options WITNESS'' from your MH kernel conf or patch the MH code to solve the problem :-) hi, i know that bit.. the WITNESS option is commented which says about the mutexes, but what i mean.. if i wanted to patch a lock order reversal... how would i do that... (i am newbie [not so newbie..]).. thanks... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
some info
hi all, sorry for running -current.. but i am an enthusiastic and challenging man...(boy)... anyways.. whats a mutex and a lock order reversal... if you could point to some good manual on these subjects... thanks... help is appreciated... thanks again... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. PATCH is below... (start) *** NOTES.old Sun Nov 25 12:54:58 2001 --- NOTES Sun Nov 25 13:11:35 2001 *** *** 292,298 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation. # options COMPAT_43 --- 292,299 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation.# XXX - this doesn't belong here. ! # options COMPAT_43 *** *** 420,435 # options COMPILING_LINT - - # XXX - this doesn't belong here. - # Allow ordinary users to take the console - this is useful for X. - options UCONSOLE - - # XXX - this doesn't belong here either - #options USERCONFIG #boot -c editor - #options INTRO_USERCONFIG#imply -c and show intro screen - #options VISUAL_USERCONFIG #visual boot -c editor - # # NETWORKING OPTIONS --- 421,426 *** *** 1150,1158 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! # # Mandatory devices: ! # # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 --- 1141,1149 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! #-- # Mandatory devices: ! #-- # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 *** *** 1189,1194 --- 1180,1189 #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event + #-- + # Video/Display Related Configuration Options + #-- + # The video card driver. devicevga hint.vga.0.at=isa *** *** 1231,1236 --- 1226,1238 devicestar_saver devicewarp_saver + #-- + # Console Related Configuration Options + #-- + + # Allow ordinary users to take the console - this is useful for X. + options UCONSOLE + # The pcvt console driver (vt220 compatible). devicevt hint.vt.0.at=isa *** *** 1347,1355 deviceacpica options ACPI_DEBUG ! # # Optional devices: ! # # # SCSI host adapters: --- 1349,1357 deviceacpica options ACPI_DEBUG ! #-- # Optional devices: ! #-- # # SCSI host adapters: *** *** 2891,2897 --- 2893,2905 options PANIC_REBOOT_WAIT_TIME=16 # + # MISCELLENEOUS OPTIONS + #options USERCONFIG #boot -c editor + #options INTRO_USERCONFIG#imply -c and show intro screen + #options VISUAL_USERCONFIG #visual boot -c editor + + # # More undocumented options for linting. # Note that documenting these are not considered an affront. *** *** 2955,2958 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE --- 2963,2966 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE ---(end) = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. thanks.. regards... Hiten Pandya [EMAIL PROTECTED] [EMAIL PROTECTED] PATCH is below... *** NOTES.old Sun Nov 25 12:54:58 2001 --- NOTES Sun Nov 25 13:11:35 2001 *** *** 292,298 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation. # options COMPAT_43 --- 292,299 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation.# XXX - this doesn't belong here. ! # options COMPAT_43 *** *** 420,435 # options COMPILING_LINT - - # XXX - this doesn't belong here. - # Allow ordinary users to take the console - this is useful for X. - options UCONSOLE - - # XXX - this doesn't belong here either - #options USERCONFIG #boot -c editor - #options INTRO_USERCONFIG#imply -c and show intro screen - #options VISUAL_USERCONFIG #visual boot -c editor - # # NETWORKING OPTIONS --- 421,426 *** *** 1150,1158 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! # # Mandatory devices: ! # # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 --- 1141,1149 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! #-- # Mandatory devices: ! #-- # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 *** *** 1189,1194 --- 1180,1189 #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event + #-- + # Video/Display Related Configuration Options + #-- + # The video card driver. devicevga hint.vga.0.at=isa *** *** 1231,1236 --- 1226,1238 devicestar_saver devicewarp_saver + #-- + # Console Related Configuration Options + #-- + + # Allow ordinary users to take the console - this is useful for X. + options UCONSOLE + # The pcvt console driver (vt220 compatible). devicevt hint.vt.0.at=isa *** *** 1347,1355 deviceacpica options ACPI_DEBUG ! # # Optional devices: ! # # # SCSI host adapters: --- 1349,1357 deviceacpica options ACPI_DEBUG ! #-- # Optional devices: ! #-- # # SCSI host adapters: *** *** 2891,2897 --- 2893,2905 options PANIC_REBOOT_WAIT_TIME=16 # + # MISCELLENEOUS OPTIONS + #options USERCONFIG #boot -c editor + #options INTRO_USERCONFIG#imply -c and show intro screen + #options VISUAL_USERCONFIG #visual boot -c editor + + # # More undocumented options for linting. # Note that documenting these are not considered an affront. *** *** 2955,2958 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE --- 2963,2966 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. thanks.. regards... Hiten Pandya [EMAIL PROTECTED] [EMAIL PROTECTED] PATCH is below... *** NOTES.old Sun Nov 25 12:54:58 2001 --- NOTES Sun Nov 25 13:11:35 2001 *** *** 292,298 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation. # options COMPAT_43 --- 292,299 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation.# XXX - this doesn't belong here. ! # options COMPAT_43 *** *** 420,435 # options COMPILING_LINT - - # XXX - this doesn't belong here. - # Allow ordinary users to take the console - this is useful for X. - options UCONSOLE - - # XXX - this doesn't belong here either - #options USERCONFIG #boot -c editor - #options INTRO_USERCONFIG#imply -c and show intro screen - #options VISUAL_USERCONFIG #visual boot -c editor - # # NETWORKING OPTIONS --- 421,426 *** *** 1150,1158 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! # # Mandatory devices: ! # # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 --- 1141,1149 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! #-- # Mandatory devices: ! #-- # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 *** *** 1189,1194 --- 1180,1189 #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event + #-- + # Video/Display Related Configuration Options + #-- + # The video card driver. devicevga hint.vga.0.at=isa *** *** 1231,1236 --- 1226,1238 devicestar_saver devicewarp_saver + #-- + # Console Related Configuration Options + #-- + + # Allow ordinary users to take the console - this is useful for X. + options UCONSOLE + # The pcvt console driver (vt220 compatible). devicevt hint.vt.0.at=isa *** *** 1347,1355 deviceacpica options ACPI_DEBUG ! # # Optional devices: ! # # # SCSI host adapters: --- 1349,1357 deviceacpica options ACPI_DEBUG ! #-- # Optional devices: ! #-- # # SCSI host adapters: *** *** 2891,2897 --- 2893,2905 options PANIC_REBOOT_WAIT_TIME=16 # + # MISCELLENEOUS OPTIONS + #options USERCONFIG #boot -c editor + #options INTRO_USERCONFIG#imply -c and show intro screen + #options VISUAL_USERCONFIG #visual boot -c editor + + # # More undocumented options for linting. # Note that documenting these are not considered an affront. *** *** 2955,2958 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE --- 2963,2966 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386/32269: [PATCH] - categorizing (XXX Lines) in NOTES
hi all, i am attaching the pointer to the PR of this... thanks.. and i am very sorry for any misbehavment i have caused and i will see to it so that it does not happen again, regards... Hiten Pandya [EMAIL PROTECTED] Note: forwarded message attached. __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ---BeginMessage--- Thank you very much for your problem report. It has the internal identification `i386/32269'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=32269 Category: i386 Responsible:freebsd-bugs Synopsis: [PATCH] - categorizing (XXX Lines) in NOTES Arrival-Date: Sun Nov 25 06:50:00 PST 2001 ---End Message---
sysinstall - no extended partitions
hi.. i wanted to know... that why doesn't the sysinstall utility support the viewing of extended partitions... i mean.. why doesn't it support the viewing of exisitng FAT32/FAT16 extended/logical partitons is not supported... thanks.. regards Yours Sincerely, [EMAIL PROTECTED] http://www.geocites.com/hitmaster2k __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
snd_pcm bringing its problems (sound.c)
hello... greetings, everytime i used to play CDs, MP3 or any audio, it gives a lock order reversal notice... the following is my dmesg -a output... lock order reversal 1st 0xc65b6e80 pcm0 @ /data/dev/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:132 2nd 0xc65b6d40 pcm0:play:0 @ /data/dev/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:189 as i can play all the audio correctly without any problems... but its just that the lock order reversal should not be there.. i beleive i have a SoundBlast Live! card, which is supported by FreeBSD under the Emu10k1 driver... and two processors enabled as well as all the kernel debugging options... i am attaching my 'dmesg -a' output with this message.. help is appreciated... thanks.. Yours Sincerely, Hiten Pandya [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #8: Thu Nov 29 10:24:42 GMT 2001 [EMAIL PROTECTED]:/usr/obj/data/dev/src/sys/CURRENT5 Preloaded elf kernel /boot/kernel/kernel at 0xc041f000. Preloaded elf module /boot/kernel/acpi.ko at 0xc041f0a8. Preloaded elf module /boot/kernel/linux.ko at 0xc041f154. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc041f200. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc041f2ac. module linux already present! Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (730.81-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536870912 (524288K bytes) avail memory = 516411392 (504308K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc0332182 (122) VESA: NVidia Using $PIR table, 8 entries at 0xc00f7100 ACPI-0161: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: serial bus, USB at device 7.3 (no driver attached) pci0: serial bus, SMBus at device 7.4 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xd000-0xd03f mem 0xdfe0-0xdfef,0xdffef000-0xdffe irq 9 at device 9.0 on pci0 fxp0: Ethernet address 00:06:29:af:90:cf inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xd400-0xd41f irq 10 at device 11.0 on pci0 pci0: simple comms at device 12.0 (no driver attached) ata-: ata0 already exists, skipping it ata-: ata1 already exists, skipping it sc-: sc0 already exists, skipping it vga-: vga0 already exists, skipping it atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Profiling kernel, textsize=1475936 [c0123590..c028baf0] cputime 6172, empty_loop 9, nullfunc_loop_profiled 6230, mcount
what is PSEUDOFS?
hi all... i would like to know if possible what is PSEUDOFS... cause i forgot to update my kernel configuration file, regarding the message in the UPDATING section... i know what DEVFS is... after the lecture at the BSDCon 2001 Europe by phk = thanks... regards... Hiten Pandya [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[SUGGESTION] - JFS for FreeBSD
hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... = -Hiten, Thank You, Yours Sincerely, Hiten Pandya, [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD
hi, why would RMS sue, lets say me, for porting IBM's piece of GPL'ed code to FreeBSD src/gnu. What i will be doing (if the votes come out positive), will be exactly as how his law says... --- Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andrew Kenneth Milt on writes: +---[ Terry Lambert ]-- | | RMS has indicated a willingness to sue people distributing bipartite | distributions, where the linking is delayed until installation to | work around the letter of the GPL. Given his religious convictions, | I can't see him *not*. Factor that into your decision. Just to balance this point out; Only the copyright holder can do this, what code of any significance has RMS contributed recently to this or any other project where this would be a consideration? Uh, people have been signing their copyright over to FSF for a long time... -- 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 = -Hiten, Thank You, Yours Sincerely, Hiten Pandya, [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
JFS4BSD Project @ SourceForge.net
Hello, Greetings, Regarding the 'JFS for FreeBSD' discussion, I have started a project at SourceForge.net, which is for the porting of JFS. If you would like to join the JFS4BSD team in porting the JFS to the FreeBSD Operating System, please do not hesitate to either send a mail through SourceForge.net or send me an email at: [EMAIL PROTECTED], and write the following in the subject: [subscribe] jfs4bsd, which will help me sort the mail out for the subscription. Everyone is welcome! Note: You will need an account at SourceForge in order to join any project including 'jfs4bsd'. The following are the details for the project: Project Full Name: JFS for FreeBSD (JFS4BSD) Project Unix Name: jfs4bsd CVS Server: cvs.jfs4bsd.sourceforge.net Web Site: jfs4bsd.sourceforge.net If you are not intending to join the project, please ignore this mail. Thank You for your co-operation, Regards, Hiten Pandya [EMAIL PROTECTED] __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smp hang on -current?
--- Alfred Perlstein [EMAIL PROTECTED] wrote: I have a box, I've enabled SMP, and APIC, disabled WITNESS and INVARIANTS. It hangs after probing scsi right before mountroot. It looks like something may be botched with interrupts: hi, happy new year 2002!, APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 I think the problem is either here.. APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 Waiting 15 seconds for scsi devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. (probe0:sym0:0:0:1): Autosense Failed (probe0:sym0:0:0:2): Autosense Failed (probe0:sym0:0:0:3): Autosense Failed (probe0:sym0:0:0:4): Autosense Failed (probe0:sym0:0:0:5): Autosense Failed (probe0:sym0:0:0:6): Autosense Failed (probe0:sym0:0:0:7): Autosense Failed ..or here. Because of the SCSI AutoSense failure I have an -CURRENT SMP system with INVARIANTS, WITNESS enabled, plus two Cheetah XL 15K RPM Seagate drive but it hasn't failed on my system like this.. so I am not quite sure.. regards, - Hiten - [EMAIL PROTECTED] = SSH Fingerprint: 1024 45:a5:9c:f2:fb:07:da:70:18:02:0b:f3:63:f1:7a:a6 [EMAIL PROTECTED] __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: undefined reference to `pfs_statfs'
hi, there is a note for this in the UPDATING file, that u have to add the following to your kernel config: options PSEUDOFS the latest kernels have to have pseudofs inorder for PROCFS to work.. a dependancy... regards, - Hiten - [EMAIL PROTECTED] --- ADRIAN.BROWNE [EMAIL PROTECTED] wrote: Anyone got any ideas kern.version: FreeBSD 5.0-20020102-CURRENT #0: Wed Jan 2 12:00:48 GMT 2002 make failed on /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x6c): undefined reference to `pfs_root' /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x74): undefined reference to `pfs_statfs' *** Error code 1 source updated by cvs on 8-1-2002 still failed :( [EMAIL PROTECTED] __ _ / /___ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_//_/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message = SSH Fingerprint: 1024 45:a5:9c:f2:fb:07:da:70:18:02:0b:f3:63:f1:7a:a6 [EMAIL PROTECTED] __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reboot and sync behaviour.
I have had lots of these :) --- Julian Elischer [EMAIL PROTECTED] wrote: This succeeded, but looks suspicious to me. syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 regards, -- Hiten __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reboot and sync behaviour.
I have had lots of these :) --- Julian Elischer [EMAIL PROTECTED] wrote: This succeeded, but looks suspicious to me. syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 regards, -- Hiten __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com 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
Why isn't PAM_smb available for FreeBSD?
hi all, I was wondering, after seeing that Linux has pam_smb, why can't FreeBSD have it too. I can get the pam_smb compiling under FreeBSD, from http://www.samba.org, so I was wondering why it isn't in our CVS tree. Thanks, Regards, -- Hiten Pandya -- [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
