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: 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: 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: 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: 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: 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]"
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: 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: 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: 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]"
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__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]"
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
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 (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 (0x) on (0x)..." in my case.
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: 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: 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: 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
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: 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: 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: 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: 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
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
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" },
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: 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:
>
> HP>Craig 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>
> HP>What you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
> HP>deprecated for several reasons, that are outlined in the
> HP>commit 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
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: 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: busdma documentation
Harti Brandt (Mon, Feb 24, 2003 at 11:41:57AM +0100) wrote: > On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: > > DS>is 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
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
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: 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
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: 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: 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
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: 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
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: 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: 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: 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
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: 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
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
#include
-#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) ((x 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(a,b) (((a) < (b)) ? (a) : (b))
-
*offset = MIN(ADV_SYN_MAX_OFFSET, *offset);
if (*period != 0 && *offset != 0) {
for (i = 0; i < adv->sdtr_period_tbl_size; i++) {
Index: dev/advansys/adwcam.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/advansys/adwcam.c,v
retrieving revision 1.11
diff -u -r1.11 adwcam.c
--- dev/advansys/adwcam.c 1 Mar 2001 17:08:55 - 1.11
+++ dev/advansys/adwcam.c 18 Jan 2003 18:43:42 -
@@ -72,8 +72,6 @@
#define ccb_acb_ptr spriv_ptr0
#define ccb_adw_ptr spriv_ptr1
-#define MIN(a, b) (((a) < (b)) ? (a) : (b))
-
u_long adw_unit;
static __inline cam_status adwccbstatus(union ccb*);
Index: dev/aha/aha.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/aha/aha.c,v
retrieving revision 1.43
diff -u -r1.43 aha.c
--- dev/aha/aha.c 1 Jan 2003 18:48:49 - 1.43
+++ dev/aha/aha.c 18 Jan 2003 18:44:02 -
@@ -84,10 +84,6 @@
*/
#defi
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
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 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: 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: 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
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: 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: 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
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: 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
PFIL_HOOKS should be made default in 5.0
Hi all. 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. 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. > > harti Harti, I got yourmail I tried replying but my domain is being rejected because of a localhost issue. Anyway, try the URLs again, and they should hopefully work. I am attaching a gzip file, which has the docs that are available at the URL. P.S. The docs are nowhere near finished, but they have enough information to guide you through. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ bus_dma-docs.tgz Description: application/tar-gz
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: 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
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
#include
#include
#include
#include
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: 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
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: 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: 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: 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 line in ncp_conn.h to , 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: 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 line in ncp_conn.h to , 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: 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: 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
#include
#include
+#include
#include
#include
@@ -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: I'm impressed, but ...
On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote the words in effect of: > | [...] > | vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > | unknown: can't assign resources (port) > | unknown: can't assign resources (irq) > | unknown: can't assign resources (port) > | unknown: can't assign resources (port) > | unknown: can't assign resources (port) > | unknown: can't assign resources (port) > | unknown: 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: 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 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: 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
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: 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
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
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. -- 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
#include
#include
+#if 0
+#include
+#endif
#include
@@ -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)
-
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: 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: 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: 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: 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
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 - - - - ad3s1a128MB * ad3s2 54478MB DOS ad3s1b 1008MB * ad3s1e256MB * ad3s1f256MB * ad3s1g 7348MB * ad3s3a128MB * <-- Notice the sizes ad3s3b 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: 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
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
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: 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
Re: The official "GEOM is in the tree" speech.
PHK, I salute you! -- Hiten --- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > > Ok, we've reached a milestone which have been on the radar for 8½ > years, at least for some of us: > > GEOM is far from done yet, but unless I have overlooked something, > it now meets and in may areas exceeds the capabilities of the previous > code, and therefore the time is ripe for the change. > > Throughout history, there has always been a tradition for rallying > the forces with a bit of pep-talk on the eve of a battle, so bear > with me if this email gets to be a bit philosphical, but I have > some things I want to say to you guys. > > Times are changing, and the world around us as well. We are no > longer a tiny volunteer hobby project, we are now a player in one > of the most cut-throat businesses on the planet, next only to > narcotics (legal and medical) and weapons. > > Remember that. > > > Just as well as the rest of the old-timers, I remember how UNIX > used to run on 16 bit computers, the simplicity, the elegance > and all that which we fell in love with. And I still admire > the people who made that possible. > > Our job, and our challenge, is to continue the tradition they > started, standing on their shoulders, reaching forever higher. > > Freezing time, sticking to traditions, or sticking to standards > which try reduce diversity and thereby inovation, is not what the > way to do that, neither is sailing out across the wide blue ocean > without map and compas. > > Operating systems, just as people, are a product of their time, > and if they stop innovating, fail to develop with the world > around then, they will stagnate, and die. > > Our task is to stay alive and kicking, our challenge is to > be ahead of our time and the rest of the pack. > > And that is the first point I would like to make: If it wasn't > for the bikeshed it would produce, I would like to propose > that starting right after then 5.0 branch, we rename our > HEAD revision from "-current" to "-future". > > What goes in in current is by nature, and our release cycle, one > to two years ahead of our main userbase. We should have in -current > what they will be asking for 12 months down the road. > > Remember that. > > > GEOM is not ahead of the curve like that, infact is is way behind. > > GEOM should have been put in the tree before ccd(4), before > PC98, alpha and in particular before vinum(4). > > Just like the VFS/Vnode concept or the protocol stack, GEOM is a > frame-work, or if you prefer: infrastructure component, meant to > make FreeBSD much more able and flexible than it ever were before. > > Now that GEOM is in the tree, we can clean up the various hacks > which were made due to the lack of infrastructure between VNODEs > and diskdevices: ccd, vinum, disklabel, diskslice and all that. > > And we can start to add new functionality using the flexibility > and clean architecture it offers us. > > And that brings me to the next point I want to make: > > The reason it has taken me 8 years to do it, is mostly that I wanted > it done right, not just another "quick hack to get it working", and > that meant taking the long way rather than a short cut, and it > meant paving a couple of new roads because the old ones would not > be able to carry the load. > > Road-construction is never a nice thing, at least not until it > is done and over with, but it is a necessary part of the lifecycle. > > GEOM has been a long journey for me, its been a long journey for > you and for all the users as well. There have been fights, there > have been disagreement and there have been a lot of hard work. > > Most of this could probably have been avoided, one way or another, > but likely as not, we will never entirely avoid it in a volounteer > project spanning the globe. > > It worries me however, to realize how tough an ass-hole I have > had to be, in order to get to stick to the principle of doing > things right, rather than "just hack it in". > > The best way to destroy FreeBSD in the long term, is to let our > infrastructure rot. > > Nailing a thing on it here, sticking a cute feature there, making > an assumption in this place, it all slowly but surely erodes > the strength of the infrastructure. > > We have a number of features in the kernel which have their merits > but which carries a heavy cost on our infrastructure. I have > probably better give you a random example here to make sure I don't > get misunderstood: > > UFS snapshots are a cool thing, and I love background fsck as much > as the next guy. But in order to be able to implement it, Kirk > either had to redo the entire buffer cache/VM system to support the > primitives he needed, or he could reach down and stick a wedge in > between SPECFS and the disk drivers. If modernizing buf/VM wasn't > easy before, this certainly wont make it any easier now. > > But I don't blame Kirk, he was not out to fix our infrastructure, > he was out to add snapshots to UF
Re: ../../../vm/uma_core.c:1327: could sleep with "pcm0:play:0" locked from
--- Juan Francisco Rodriguez Hervella <[EMAIL PROTECTED]> wrote: > ../vm/uma_core.c:1160 > ../../../vm/uma_core.c:1327: could sleep with "process lock" locked from > ../../../kern/kern_prot.c:511 > ../../../vm/uma_core.c:1327: could sleep with "process lock" locked from > Hope this help. Do you think these errors are alarming ? > I mean, do you recommend me to recopile my kernel again ? > (please noo, it takes me a lot of time to recompile whatever thing :) Hi. I am not sure if they are alarming or not, but recently (infact yesterday) I made a post to this mailing list with all the lock problems which I found when using a SoundBlaster 1024 Live! card which uses the pcm driver. Afaik. This problems are well known, and the developers are working on resolving the issues, though I maybe wrong. Thanks. Regards -- Hiten __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock information from SMP Kernel of June 7
Hello. As I am building an SMP kernel after a long time in -CURRENT. I thought people will find it useful if I posted the output from my dmesg which is showing a big amount of lock order related warnings. Hope this helps. Also, there is one problem I found (?), which when we pass the loader "boot -d", it goes into the debugger, which is what it should do, but from the DDB debugger, if we type "show locks"; then the kernel/debugger panics with some witness related message. I cant get more info on this one because I dont have a serial console. Is this some sort of a mistake which I am making? Also, when I load the sound driver, I get a whole lot of lock order problems. My soundcard is SoundBlaster Live! 1024, which uses the pcm driver in conjuction with snd_emu10k1 (both loader as kernel modules). If the given information hasn't helped at all, then I apologise for the inconvenience. Thanks. Regards. P.S. MPTable Output, dmesg(1) output attached. -- Hiten Pandya http://storm.uk.FreeBSD.org/~hiten Finger [EMAIL PROTECTED] for PGP public key -- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 Copyright (c) 1992-2002 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 #0: Fri Jun 7 09:48:11 BST 2002 [EMAIL PROTECTED]:/c1/obj/data/dev/src/sys/SMP5 /data/dev/src/sys/vm/uma_core.c:1327: could sleep with "eventhandler" locked from /data/dev/src/sys/kern/subr_eventhandler.c:162 /data/dev/src/sys/vm/uma_core.c:1327: could sleep with "eventhandler" locked from /data/dev/src/sys/kern/subr_eventhandler.c:162 Preloaded elf kernel "/boot/kernel/kernel" at 0xc03fa000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03fa0a8. Calibrating clock(s) ... TSC clock: 733403736 Hz, i8254 clock: 1193254 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (733.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 536805376 (524224K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00424000 - 0x1ffe7fff, 532430848 bytes (129988 pages) avail memory = 517844992 (505708K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff 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 bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb01 pnpbios: Found PnP BIOS data at 0xc00f6a10 pnpbios: Entry = f:58e4 Rev = 1.0 Other BIOS signatures found: /data/dev/src/sys/vm/uma_core.c:1327: could sleep with "sf_bufs list lock" locked from /data/dev/src/sys/kern/uipc_syscalls.c:1556 null: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 00 02 11 03 07 01 00 01 1a 01 00 01 2f 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 VESA: 33 mode(s) found VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc0359642 (122) VESA: NVidia VESA: NVidia Corporation NV10 Reference Board Chip Rev A1 random: SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06911106) Using $PIR table, 8 entries at 0xc00f7100 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: physical bus=0 map[10]: typ
Re: Buildworld errors caused by libfetch.so
--- Doug Barton <[EMAIL PROTECTED]> wrote: > On Thu, 6 Jun 2002, Hiten Pandya wrote: > > > [CC'ed to des@] > > > > Hi all. > > > > I am experiencing buildworld errors caused by the latest libfetch.so. > > The CVSUP source is just a couple of minutes old. > > Make sure that your next cvsup catches the update to the Makefile: > > $ ident /usr/src/usr.bin/fetch/Makefile > /usr/src/usr.bin/fetch/Makefile: > $FreeBSD: src/usr.bin/fetch/Makefile,v 1.9 2002/06/06 13:45:46 ru Exp Done. GCC3 environment ready!. Thanks everyone. The buildworld succeeded. -- Hiten __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buildworld errors caused by libfetch.so
[CC'ed to des@] Hi all. I am experiencing buildworld errors caused by the latest libfetch.so. The CVSUP source is just a couple of minutes old. Thanks. -- Hiten Pandya http://storm.uk.FreeBSD.org/~hiten Finger [EMAIL PROTECTED] for PGP public key -- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 cc -O -save-temps -march=pentiumpro -I/data/dev/src/usr.sbin/pkg_install/add/../lib -Werror -Wall -Wno-uninitialized -o pkg_add main.o perform.o futil.o extract.o /c1/obj/data/dev/src/usr.sbin/pkg_install/add/../lib/libinstall.a -lfetch -lmd /usr/lib/libfetch.so: undefined reference to `SSL_set_fd' /usr/lib/libfetch.so: undefined reference to `X509_NAME_oneline' /usr/lib/libfetch.so: undefined reference to `SSL_read' /usr/lib/libfetch.so: undefined reference to `SSL_new' /usr/lib/libfetch.so: undefined reference to `SSL_CTX_new' /usr/lib/libfetch.so: undefined reference to `SSL_library_init' /usr/lib/libfetch.so: undefined reference to `ERR_print_errors_fp' /usr/lib/libfetch.so: undefined reference to `SSL_load_error_strings' /usr/lib/libfetch.so: undefined reference to `SSL_CIPHER_get_name' /usr/lib/libfetch.so: undefined reference to `SSLv23_client_method' /usr/lib/libfetch.so: undefined reference to `X509_get_subject_name' /usr/lib/libfetch.so: undefined reference to `SSL_get_current_cipher' /usr/lib/libfetch.so: undefined reference to `SSL_connect' /usr/lib/libfetch.so: undefined reference to `X509_get_issuer_name' /usr/lib/libfetch.so: undefined reference to `SSL_get_peer_certificate' /usr/lib/libfetch.so: undefined reference to `SSL_write' *** Error code 1 Stop in /data/dev/src/usr.sbin/pkg_install/add. msg39262/pgp0.pgp Description: PGP signature
Build Errors in Latest -CURRENT
Build errors encountered in the latest buildworld of -current. Error output attached with mail. Hope it helps. Uname(1) of the system is: FreeBSD 5.0-CURRENT #0: Sat May 4 19:07:01 BST 2002 Thanks. -- Hiten Pandya http://storm.uk.FreeBSD.org/~hiten Finger [EMAIL PROTECTED] for PGP public key -- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 /data/dev/src/bin/ls/lomac.c: In function `get_lattr': /data/dev/src/bin/ls/lomac.c:144: warning: null format string /data/dev/src/bin/ls/lomac.c:153: warning: null format string cc -O -save-temps -march=pentiumpro -DCOLORLS -Wall -Wno-format-y2k -Wno-uninitialized -c /data/dev/src/bin/ls/ls.c /data/dev/src/bin/ls/ls.c: In function `traverse': /data/dev/src/bin/ls/ls.c:443: warning: null format string /data/dev/src/bin/ls/ls.c: In function `display': /data/dev/src/bin/ls/ls.c:544: warning: null format string /data/dev/src/bin/ls/ls.c:680: warning: null format string /data/dev/src/bin/ls/ls.c:697: warning: null format string cc -O -save-temps -march=pentiumpro -DCOLORLS -Wall -Wno-format-y2k -Wno-uninitialized -c /data/dev/src/bin/ls/print.c /data/dev/src/bin/ls/print.c: In function `printcol': /data/dev/src/bin/ls/print.c:282: warning: null format string cc -O -save-temps -march=pentiumpro -DCOLORLS -Wall -Wno-format-y2k -Wno-uninitialized -c /data/dev/src/bin/ls/util.c cc -O -save-temps -march=pentiumpro -DCOLORLS -Wall -Wno-format-y2k -Wno-uninitialized -static -o ls cmp.o lomac.o ls.o print.o util.o -lm -ltermcap /usr/obj/data/dev/src/i386/usr/lib/libtermcap.a(parse_entry.o): In function `_nc_parse_entry': parse_entry.o(.text+0x4db): undefined reference to `_nc_find_entry' parse_entry.o(.text+0x539): undefined reference to `_nc_find_entry' parse_entry.o(.text+0x5c3): undefined reference to `_nc_find_entry' parse_entry.o(.text+0x745): undefined reference to `_nc_find_type_entry' /usr/obj/data/dev/src/i386/usr/lib/libtermcap.a(parse_entry.o): In function `_nc_capcmp': parse_entry.o(.text+0x11de): undefined reference to `_nc_find_entry' parse_entry.o(.text+0x11f3): undefined reference to `_nc_find_entry' msg39127/pgp0.pgp Description: PGP signature
Re: Deadlock using snapshots
--- Peter Jeremy <[EMAIL PROTECTED]> wrote: > I decided to do some experimenting with snapshots and managed to > deadlock my system. (Basically, I had a cron job that was trying > to snapshot all my filesystems every 5 minutes - with a view to > being able to undo any "accidents" I might make). I'd reached > about 5 snapshots per filesystem when it hung. > > I've found a few other anomolies with snapshots, but deadlocks are > undesirable :-(. > > The system was still running normally, but nothing could access the > filesystem. Breaking into 'ps' showed that the deadlocked processes > were all waiting on "inode". I've got a crash dump but would like > some suggestions on where to start looking. > > The system is -CURRENT from 7th May. Is it possible to produce a crash dump? It might provide us with additional information on where it actually deadlocks. Hiten. [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV in current
--- Rob <[EMAIL PROTECTED]> wrote: > I've tried to copy MAKEDEV to /dev in current. But get the error- > "operation not supported". I must be missing some very basic concept. > Rob. Rob, FreeBSD-CURRENT makes use of DEVFS by default, so you dont need to create entries unless you have NODEVFS in your kernel configuration file. Also, read the src/UPDATING file more information. Regards. -- Hiten Pandya -- <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to dump a 4gig system on panic ?
--- "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > Well, downloaded the files (a .tar.gz would be nice? *grin*) and the > client built perfectly, and kldload worked fine ... is there some way > someone can suggest of 'simulating a crash'? Some way to test to make > sure that it is working as expected? I have a 4.6-PRE machine on my desk > that I'd like to test with before I try it on "the real thing", if at all > possible? If you have DDB in your kernel, then you can press Ctrl+Alt+Esc; by doing that, you will enter into the kernel debugger (DDB). At the prompt displayed, type 'panic' without the quotes and then should hopefully generate a dump. Regards. -- Hiten __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make includes
--- Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > People might want to use it like that: > > make world > mv /usr/include /usr/include.old Sorry to butt in; but wouldn't it be more good if this step was done by the build scripts itself? (refering to: mv /usr/include /usr/include.old) > make incsinstall Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP Public Key See complete mail headers for address information WWW: http://storm.uk.FreeBSD.org/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Review requested for newly added manual page devinfo(8)
Hello, As per the request of rwatson; and a courtesy which I would like to fulfil. I would be very greatful if you could take a look at the newly added manual page, available at: src/usr.sbin/devinfo/devinfo.8 It was added on Sunday May/12 by Robert Watson. Thank you, Regards. -- Hiten Pandya -- <[EMAIL PROTECTED]> P.S. CC'ed to rwatson@ __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > yeah > > I just tracked it doen to if_tap not working as a module any more... > > don't know what broke it but it's not showing up in /dev/ (devfs) any more > and not creating interfaces.. Exactly the same problem, but when kldload is called, it doesn't let go off the controling terminal. and doesn't let a reboot kill it; and sometimes the machine doesnt agree to reboot i.e. leading to a manual reboot. Regards, -- Hiten __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > seems something broke in the networking side of things using host-only > networking.. vmnet1 doesn;t show up any more.. Does vmware2 crash when it is started? I was recently trying vmware2 on FreeBSD-CURRENT, but gaveup because it tried to load the if_tap driver if I am right, and kldload was just stuck. Regards. -- Hiten __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: alpha tinderbox failure
> ===> libtelnet
> cc1: warnings being treated as errors
> /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:
>In function
> `kerberos4_cksum':
>
>/.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496:
> warning:
> unreachable code at beginning of switch statement
> *** Error code 1
%%%
int
kerberos4_cksum(unsigned char *d, int n)
{
int ck = 0;
/*
* A comment is probably needed here for those not
* well versed in the "C" language. Yes, this is
* supposed to be a "switch" with the body of the
* "switch" being a "while" statement. The whole
* purpose of the switch is to allow us to jump into
* the middle of the while() loop, and then not have
* to do any more switch()s.
*
* Some compilers will spit out a warning message
* about the loop not being entered at the top.
*/
switch (n&03)
while (n > 0) {
case 0:
ck ^= (int)*d++ << 24;
--n;
case 3:
ck ^= (int)*d++ << 16;
--n;
case 2:
ck ^= (int)*d++ << 8;
--n;
case 1:
ck ^= (int)*d++;
--n;
}
return(ck);
}
%%%
Thanks.
Regards.
P.S. JFYI. :-)
--
Hiten Pandya
http://storm.uk.FreeBSD.org/~hiten
Finger [EMAIL PROTECTED] for PGP public key
-- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3
msg38186/pgp0.pgp
Description: PGP signature
Re: UMA lock order reversal
> On Sun, 5 May 2002, Doug Barton wrote: > > With yesterday's -current: > > > > lock order reversal > > 1st 0xcc5987a4 DIRHASH (UMA zone) @ > > /usr/Local/src-current/sys/vm/uma_core.c:297 > > 2nd 0xc76c2224 PCPU 256 (UMA cpu) @ > > /usr/Local/src-current/sys/vm/uma_core.c:1630 I see the same one when I run "shutdown -r now". -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mutex Giant problems in latest -current
Hi all,
I just compiled the kernel now, the date is:
Sat May 4 14:18:08 BST 2002
I couldn't get a trace as I don't have a serial console or kernel dumps
because of some S_Clockinfo problem. Anyway, the panic message was like
this; just after trying to mount root:
%%
panic: mutex Giant not owned at /data/dev/src/sys/vm/vm_map.c:2151
Debugger:("panic")
...
%%
As far as I am aware, this happens after rev. 1.229 of vm_map.c:
%%
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
Working file: vm_map.c
head: 1.229
description:
revision 1.229
date: 2002/05/04 02:07:36; author: alc; state: Exp; lines: +0 -3
o Remove GIANT_REQUIRED from vm_map_lookup_entry() and
vm_map_check_protection().
o Call vm_map_check_protection() without Giant held in munmap().
----
%%
Thanks.
--
Hiten Pandya
http://storm.uk.FreeBSD.org/~hiten
Finger [EMAIL PROTECTED] for PGP public key
-- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3
msg38010/pgp0.pgp
Description: PGP signature
Re: 3Com 3c905C-TX
--- Guido Kollerie <[EMAIL PROTECTED]> wrote: > I have exchanged the 3Com NIC for an Intel one. I'm using an > Intel NIC at work and haven't had any problems with it under > FreeBSD. What remains strange though is that the 3Com NIC used to > work just fine. As said before the strange behaviour > (full-duplex -> half-duplex) occurred about a month ago. Around > the same time I performed a 'make world'. Was the xl driver > changed somehow in the period before that? It doesnt look like, accept for the following two deltas: o rev. 1.103 by [EMAIL PROTECTED] CVS Log: Remove __P. Branch: MAIN CVS Tags: HEAD o rev. 1.104 by [EMAIL PROTECTED] CVS Log: Change callers of mtx_init() to pass in an appropriate lock type name. In most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used. Branch: MAIN CVS Tags: HEAD Those are the only two revisions made to the if_xl.c driver in the timeframe you have provided; and I don't think they can cause the issue you have described, IMHO. -- Hiten Pandya __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
--- Lamont Granquist <[EMAIL PROTECTED]> wrote: > > I'm seeing this too, but I expect it's probably caused by out of sync > > kernel and world. I haven't yet been able to test this hypothesis. > > I don't think so, I did: > > [...] Just cvsup again and rebuild your kernel, and that will fix the problem. -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault in swp_pager_meta_build()
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > No idea, but the last time someone had a weird swap issue it > turned out that they had swapon'd the same swap partition twice. > The system's checks are not sufficient if you swapon the same device > from different mounts. So check that first. Talking about doing something twice, it reminds me, that there is the same type of issue with the md devices, which when they are destroyed twice or thrice, they panic the kernel. I talked about this issue before but it didn't get discussed further, and the other thing is, I am not able to produce a kernel crash dump. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
