RE: audigy 2
> On Tue, Jun 24, 2003 at 10:39:09AM +0400, Yuriy Tsibizov wrote: > > My PCM-only driver is commitable. Diff to emu10k1.c in > -current is small > > and clear (at least to me). It's stable enought to be > commited. But it > > will not be commited because sound@ decided to use another > driver that > > is better than mine. > > Where is the "sound@" list? sound @ freebsd.org. It's not a public mailing list. > I looked at the 2003 > freebsd-multimedia list > archives and couldn't find any real discussion on this. > Where can I get > your your PCM-only driver patch? It's not available as a diff to -current, but I can make a diff on weekend (I don't have any FreeBSD machine at work). You can also try to do it yourself, driver package is available from http://chibis.persons.gfk.ru/audigy/stable/emu10k1k.tar.gz. This driver does not include Audigy2 support, but adding it is very easy (about 10 lines of additional code). It also have very strange mixer (I have to emulate some of AC97 mixer registers to get volume control on Audigy). Yuriy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questions about VM_KMEM_SIZE_SCALE
On Tue, Jun 24, 2003, Jay Kuri wrote:
>
> Hi there,
>
> Can anyone shed some light on the implications of adjusting
> VM_KMEM_SIZE_SCALE? In particular I'm wondering if I increase this to,
> say, 2, what happens? I must admit I don't know how KVA is different from
> KVM or total RAM... so the note in kern_malloc ("on an x86 with 256M KVA,
> try to keep VM_KMEM_SIZE_MAX at 80M or below") doesn't shed enough light
> on the matter. What are the implications of VM_KMEM_SIZE getting large?
>
> Does changing this affect memory available to user programs if it's unused
> by the kernel?
No, KVA_PAGES affects the memory available to user programs. (You
have a 4 GB address space on i386 to split between user programs
and the kernel.) Within the kernel's share of this address space,
memory is split into submaps, such as the mb_map (for the
network), buffer_map for the filesystem buffer cache, and the
kmem_map for just about everything else. These submaps are
size-limited to prevent any one of them from getting out of hand.
The vm_kmem_map is sized automatically based on the amount of
memory you have. Specifically,
kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE),
VM_KMEM_SIZE_MAX)
The default value for VM_KMEM_SIZE_SCALE is 3, and the default
VM_KMEM_SIZE_MAX is 200MB.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE crash
Jeff Roberson wrote: > On Wed, 25 Jun 2003, Ian Freislich wrote: > > > Hi > > > > About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give > > ULE a go every few months), top started looking really wierd (the > > CPU % just kept on accumulating for each process). Before dnetc > > started, httpd showed 17% CPU, but the system was supposedly 100% > > idle at the time according to top. Then dnetc started and things > > got wierd. > > There is some bug that is preventing sleeping processes from loosing old > cpu usage. I'm looking into that. Can you tell me what version of the > sched_ule.c file you have? This looks like an old panic. $FreeBSD: src/sys/kern/sched_ule.c,v 1.46 2003/06/21 02:31:49 jeff Exp $ Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, Jun 25, 2003 at 10:15:19PM -0700, Terry Lambert wrote: > There *are* other ways to install than booting a CDROM; they are > just more labor intensive, and require FreeBSD running on a more > poswerful machine to set up the install for the other machine. True. Anyone who wants to install on a small machine should consider using a network boot first. Build on a faster machine, then user etherboot on the target machine to check it out. Sure it'll be slow, but all you have to do once the machine is netbooted is fdisk, label the disk, newfs it and copy over the stuff you need. Then reboot. If it doesn't work, netboot again and have another go. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best way to get max KVA setting?
Mike Silbersack wrote: > I found the thread in question, but I didn't see a patch. ARGH. There was a simultaneous off-list discussion; here is the scrubbed part of what I sent; it's a patch, but it's not a diff; sorry for the confusion. -- Terry - The correct place to hack the is /usr/src/sys/kern/subr_param.c. Specifically, every place it references "physpages", the number is way, way too big. At the very top of the routine init_param2(), put something like: long ephyspages;/* effective physical pages */ long clamp = 3 * 1024 * 256;/* 3G, in pages */ ephyspages = physpages; /* clamp effective memory to real KVA limits */ if (ephyspages > clamp) ephyspages = clamp; And then everywhere it references "physpages" below that, change it to "ephyspages" instead. In the version of the file I have, it looks like you could override everything at boot time; I didn't check to see how much (or if) this had changed in -current, so it may be that you could tweak everything you needed to then, instead. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
John-Mark Gurney wrote: > Tim Kientzle wrote this message on Wed, Jun 25, 2003 at 09:51 -0700: > > Why do exec-ed processes inherit the children of the former > > process, anyway? That doesn't entirely sound right to me. > > Is that behavior mandated by some standard? If not, this > > could arguably be considered a kernel bug. Hmmm... > > Could someone look into this for me? I don't have any of the standards > document. Hmmm. does APUE even talk about this? It's more of a question > if exec'd processes inherit children. The original "Go Solo 2" book says: Parent process ID An attribute of a new process identifying the parent of the process. The parent process ID of a process is the process ID of its creator, for the lifetime of the creator. After the creator's lifetime has ended, the parent process ID is the process ID of an implementation- dependent system process. Pretty clear to me they mean "init". Now the question is whether or not the creator's lifetime has ended; looking at: http://www.opengroup.org/onlinepubs/007904975/functions/exec.html the answer is not clear; specifically: The new process shall inherit at least the following attributes from the calling process image: [...] Process ID [...] Session membership [...] Time left until an alarm clock signal (see alarm() ) [...] Interval timers [...] So it seems to me that the answer is a qualified "yes"; the SIGALRM signals pending expiration of the alarm/itimer interval argue very strongly that the other pending signals (e.g. SIGCHLD) may also be inherited. Probably it's wrong for the program to fork for itself and exec its child, instead of fork+exec for the child, and remaining itself. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
"M. Warner Losh" wrote: > In message: <[EMAIL PROTECTED]> > M-Trade <[EMAIL PROTECTED]> writes: > : Has anyone had any success installing 5.1 release on a 486 > : w/ 8MB RAM? I can't install. > : > : avail memory = (245760) 0 MB > : > : Is this expected behavior? > > Yes. The generic kernel is a big fat pigdog. you might be able to > cope with a stripped down kernel, but sysinstall will dump core unless > you sneak in early in the process and add more swap. you really need > at least 16MB if not 24MB of RAM to install 5 If you use the project supplied installation tools (e.g. sysinstall from a monster RAM disk from a compressed disk image whose memory is pretty much not recovered, etc.). There *are* other ways to install than booting a CDROM; they are just more labor intensive, and require FreeBSD running on a more poswerful machine to set up the install for the other machine. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best way to get max KVA setting?
"Cagle, John (ISS-Houston)" wrote: > Terry Lambert [mailto:[EMAIL PROTECTED] > > Mike Silbersack wrote: > > > I could probably grep for this, but what's the best way to get a hold > > > of the # of pages (or MB of ram) that max KVA is set to? I'm adding > > > another autosize option, and I want to base it on min (KVA, ram) so > > > that it doesn't balloon on boxes where ram >> KVA. > > > > I posted a patch about a month ago that did exactly this. > > > > It was for a guy who was was running with PAE enabled on an > > 8G machine, and the autotuning was shooting him in the foot when it > > tried to grab enough memory to create kmem_map entries for the 8G of RAM > > in his 2G KVA space, and its head exploded. > > I'm that guy who was running PAE on an 8GB machine... > > BTW, it turns out the problem was _not_ the autotuning, it was simply an > overflow of a 32-bit variable in the kernel. It's been fixed in > -current, checked in 2 weeks ago. I still expect that there are issues with the autotuning not taking KVA << RAM into account, without something like my patch, even if it's not biting you specifically at 8G. I'd like to see what happens at 64G RAM, for example... In any case, the patch I posted is still probably what Mike wanted. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
"Simon L. Nielsen" wrote: > On 2003.06.25 12:10:42 +0200, Michael Nottebrock wrote: > > FWIW, the last FreeBSD release I managed to install on an 8mb machine from > > CD-ROM+bootfloppies was 4.1.1. > > Can anybody else confirm this ? It seems like the documetation need to > be updated to state this. State what? That you should use 4.1.1 on 8M 486 machines, if you intend on installing from media that require the use of a RAM disk for installation? Seems a little specialized... 8-). > Have anybody made any recent tests on CURRENT (and STABLE for that > matter) with regards to minimum RAM requirements, install and normal > runtime? Yes; about two months ago there were a couple of people who installed on an old 386SX. The main issue was that they had to roll their own distribution from sources, specifically with a stripped down kernel without all the weird drivers (which is exactly what I talked about in my previous posting). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: passwd NIS+ YP compat mode
Untested in any other environment other than client of Solaris 8 NIS+ in YP compat.
However I am using the AMD automounter to mount users home directories from HP-UX
10.20, Solaris 8 and 9 systems succesfully.
Relevant parts of my /etc/rc.conf and /etc/amd.conf are:
ifconfig_xl0="DHCP"
nisdomainname="one.two"
nis_client_enable="YES"
nis_client_flags="-s -S one.two,a.big.expensive.server.com -m"
rpcbind_enable="YES"
nfs_server_enable="YES"
nfs_client_enable="YES"
mountd_flags="-r"
amd_enable="YES"
amd_flags="-F /etc/amd.conf"
Extract of /etc/amd.conf:
[global]
map_options = opts:=intr,rsize=8192,wsize=8192
mount_type = nfs
auto_dir = /.tmp_mnt
cache_duration = 300
log_file = syslog
restart_mounts = yes
unmount_on_exit = no
[/home]
map_name = amd.home
map_type = nis
freeme: {1005} ypmatch user1 amd.home
host==freeme;type:=link;fs:=/export/home/user1 ||
rhost:=freeme;type:=nfs;rfs:=/export/home/user1;sublink:=.
-Original Message-
From: John De Boskey [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 10:51 AM
To: Thyer, Matthew
Cc: yoshint
Subject: Re: passwd NIS+ YP compat mode
Is there a PR for this?
I understand this patch fixes ypclient to solaris NIS+ compat. Have you tested
it in any other configs?
-John
- Thyer, Matthew's Original Message -
> The silence is deafening.
>
> Please commit this if it's the correct solution.
>
> FreeBSD looks real bad when it cant be a NIS client of Solaris NIS+ (in YP compat)
> servers.
>
> > -Original Message-
> > From: Thyer, Matthew
> > Sent: Monday, June 23, 2003 12:04 PM
> > To: '[EMAIL PROTECTED]'
> > Cc: '[EMAIL PROTECTED]'; Wilkinson, Alex
> > Subject:SEC:URe: passwd NIS+ YP compat mode
> >
> > Yoshinori's patch for FreeBSD NIS clients of Solaris NIS+ servers in YP
> > compatibility mode works for me.
> >
> > Please commit this before 5 becomes -STABLE (I'm shocked the bug has made it into
> > 5.1).
> >
> > Solaris NIS+ servers in YP compatibility is a very common configuration in larger
> > enterprises.
> >
> >
> > On Tue, 27 May 2003 18:09:29 -0700, TOMITA Yoshinori wrote:
> >
> > I hope this patch will solve this problem for users living under NIS+
> > servers.
> >
> > I guess yp_order() is used to check masswd.by* or master.passwd.by*
> > databese really exists. yp_master() can be used for this purpose. But
> > I do not know the cost of yp_master() compared to yp_order().
> >
> >
> > --- /usr/src/lib/libc/gen/getpwent.c.bakTue May 27 08:47:24 2003
> > +++ /usr/src/lib/libc/gen/getpwent.cWed May 28 09:35:50 2003
> > @@ -938,14 +938,15 @@
> > nis_map(char *domain, enum nss_lookup_type how, char *buffer, size_t bufsize,
> > int *master)
> > {
> > - int rv, order;
> > + int rv;
> > + char*outname;
> >
> > *master = 0;
> > if (geteuid() == 0) {
> > if (snprintf(buffer, bufsize, "master.passwd.by%s",
> > (how == nss_lt_id) ? "uid" : "name") >= bufsize)
> > return (NS_UNAVAIL);
> > - rv = yp_order(domain, buffer, &order);
> > + rv = yp_master(domain, buffer, &outname);
> > if (rv == 0) {
> > *master = 1;
> > return (NS_SUCCESS);
> > @@ -954,7 +955,7 @@
> > if (snprintf(buffer, bufsize, "passwd.by%s",
> > (how == nss_lt_id) ? "uid" : "name") >= bufsize)
> > return (NS_UNAVAIL);
> > - rv = yp_order(domain, buffer, &order);
> > + rv = yp_master(domain, buffer, &outname);
> > if (rv == 0)
> > return (NS_SUCCESS);
> > return (NS_UNAVAIL);
> >
> >
> >
> > --
> > ---
> > TOMITA Yoshinori
> >
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
--
As said by Napolean Bonaparte:
"Never ascribe to malice, that which is adequately explained by incompetence"
After being embraced by MS:
"When accused of malice, always hide behind incompetence".
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI stuff to make Libretto 110CT work
John Baldwin writes: > > On 24-Jun-2003 Mark Murray wrote: > > Hi > > > > You (?) gave me these patches at least 6 months ago, and they've > > been working for my Libretto ever since then. Is it OK if I commit > > them? > > No, not quite yet. Those are rather hackish and I didn't develop > them, one of the other ACPI guys did. OK. Can we work on this, then? The patches are developing a bit of a following of folks who would _love_ to see them committed. :-) What is needed? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-25 20:08:47 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-25 20:08:47 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-25 20:11:35 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/jot/jot.c cc -O -pipe -o jot jot.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump/../..-c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump/kdump.c cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump/../..-c ioctl.c In file included from ioctl.c:53: /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/net80211/ieee80211_ioctl.h:40: redefinition of `struct ieee80211req' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/kdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-25 20:58:11 - /usr/bin/make returned exit code 1 TB --- 2003-06-25 20:58:11 - ERROR: failed to build world TB --- 2003-06-25 20:58:11 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
On Wed, 25 Jun 2003 16:44:56 -0400 (EDT) Robert Watson <[EMAIL PROTECTED]> wrote: > Sounds like a memory leak to me; it might also be a locking problem. > Are you actually running with any MAC policies, or just with the > framework? Just the framework, no policies. > The code most likely to cause a memory leak in the MAC Framework is > the label management code, since that's the only code that really does > much in the way of memory allocaiton. Try compiling options MAC_DEBUG > into your kernel, which causes the MAC Framework to track the number > of labels it has allocated/free'd in a series of variables: [snip] Ok, I will try and do the things du suggest (never tried that before), but am I the only one with this problem? If you'd like, I can give you root access to the laptop, then you can play all you want :-) br socketd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
Just FYI, there are actually some "legitimate" situations in which processes will appear to hang when using MAC. For example, if you have MLS or Biba turned on, and revocation support specifically enabled (not the default), you can see interactive processes appear to hang when they are interacting with a terminal that is not authorized to receive its output. For example, if you change the process labels so that they have access to top secret data, but your terminal label is set so it is only cleared for confidential data, the process can't write to the terminal. Given that you don't appear to have any policies loaded, that's presumably not what is going on. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
On Wed, 25 Jun 2003, Socketd wrote: > I have just installed 5.1 Release on my laptop (6gb harddisk and 60 mb > ram). I only installed the base system + man pages and the port > collection. A little info: / 128M Swap 256M /var 128M /var/tmp 256M > (/tmp is symlinked to this) /home 256M /usr The rest > > I compiled a new kernel, with no support for SCSI, RAID, IPv6 and all > but my USB NIC (also removed a few USB things). I added: options > SC_DISABLE_REBOOT options MAC device pcm > > It compiled fine and I installed it. Now, if I run with this kernel the > system freezes! I can boot, login and run a few commands, but that's it. > There is nothing in the logs, but when I tried ssh'ing to the mashine I > got this before it froze: fork() - Not enough ressources available at > this time > > (or something like that). > > Is there a memory leak somewhere or am I doing something wrong? (I > compiled and installed the kernel with: > make buildkernel KERNCONF=SOCKETD > make installkernel KERNCONF=SOCKETD) > > btw please cc to me as I am not on the list. Sounds like a memory leak to me; it might also be a locking problem. Are you actually running with any MAC policies, or just with the framework? The code most likely to cause a memory leak in the MAC Framework is the label management code, since that's the only code that really does much in the way of memory allocaiton. Try compiling options MAC_DEBUG into your kernel, which causes the MAC Framework to track the number of labels it has allocated/free'd in a series of variables: static unsigned int nmacmbufs, nmaccreds, nmacifnets, nmacbpfdescs, nmacsockets, nmacmounts, nmactemp, nmacvnodes, nmacdevfsdirents, nmacipqs, nmacpipes, nmacprocs; You can inspect them using a series of sysctls in the security.mac.debug tree; I'd be interested to see how those values change as you approach the hang. If you have DDB compiled into the kernel (which you probably will want for debugging this problem), I'd be interested in seeing if you can break into DDB using a console break or serial console break. If so, print out the values of those variables and see if any are through the roof. Also, you might do a ps in DDB and see if processes are blocked on anything in particular. The most likely locking problem is a vnode deadlock; if you can get into DDB, try "show lockedvnods" to see whether any locks are held, etc. If you don't have a serial console set up, you might want to set one up because it will make copying and pasting all this stuff into e-mail a lot easier. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ACPI stuff to make Libretto 110CT work
On 24-Jun-2003 Mark Murray wrote: > Hi > > You (?) gave me these patches at least 6 months ago, and they've > been working for my Libretto ever since then. Is it OK if I commit > them? No, not quite yet. Those are rather hackish and I didn't develop them, one of the other ACPI guys did. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
On Wed, 25 Jun 2003 10:24:43 -0700 "Kevin Oberman" <[EMAIL PROTECTED]> wrote: > Providing your complete configuration file and /var/run/dmesg.boot > might give a bit of a clue. Ok. /usr/src/sys/i386/conf/SOCKETD: machine i386 cpu I586_CPU ident SOCKETD options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensionsoptions KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS device isa device eisa device pci device fdc device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device npx device pmtimer device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus device sio # 8250, 16[45]50 based serial ports device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device device miibus # MII bus support device random # Entropy device device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device bpf # Berkeley packet filter device uhci# UHCI PCI->USB interface device ohci# OHCI PCI->USB interface device usb # USB Bus (required) device ugen# Generic device uhid# "Human Interface Devices" device ukbd# Keyboard device ums # Mouse device aue # ADMtek USB ethernet device pcm options SC_DISABLE_REBOOT options MAC And /var/run/dmesg.boot Copyright (c) 1992-2003 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.1-RELEASE #1: Sat Jan 2 03:46:39 CET 1999 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOCKETD Preloaded elf kernel "/boot/kernel/kernel" at 0xc048f000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc048f1f4. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 448341906 Hz CPU: AMD-K6(tm) 3D processor (448.34-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 62849024 (59 MB) avail memory = 5
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-25 19:08:44 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-25 19:08:44 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-25 19:11:26 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/jot/jot.c cc -O -pipe -o jot jot.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump/../..-c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump/kdump.c cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump/../..-c ioctl.c In file included from ioctl.c:55: /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/net80211/ieee80211_ioctl.h:40: redefinition of `struct ieee80211req' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/kdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-25 20:08:44 - /usr/bin/make returned exit code 1 TB --- 2003-06-25 20:08:44 - ERROR: failed to build world TB --- 2003-06-25 20:08:44 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driverpanic
In this mail: http://www.freebsd.org/cgi/getmsg.cgi? fetch=29403+32287+/usr/local/www/db/text/2003/freebsd-scsi/20030615.freebsd- scsi It was suggested to do a backtrace on it. I didn't have the option in 5.1- RELEASE, but I grabbed the 20030624 snapshot and was able to get the following information. First of all the error seems slightly different, but the end result is the same, unable to boot fully. First I get (the relevant parts IMO): .. pcib5: at pcibus 5 on motherboard pci5: on pcib5 ips0: mem 0xf400--xf7ff irq 9 at device 3.0 on pci5 ips0: failed to get configuration from device device_probe_and_attach: ips0 attach returned 6 .. pci9: in pcib9 Memory modified after free 0xc18cd700(252) panic: Most recently used by devbuf Here's the trace: Debugger(c0502455,c05c50e0,c05193ad,c0b35ca4,100) at Debugger+0x54 panic(c05193ad,c0500cf7,fc,c0c3aea0) at panic+0xcc mtrash_ctor(c18cd700,100,0,553,0) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3aea0,0,101,c0327620,c0599b48) at uma_zalloc_arg+0x17f malloc(a8,c0556960,101,c052254c,c0b35d6c) at malloc+0xd4 device_get_children(c433a380,c0b35d58,c0b35d5c,c0325c62,c18dd700) at device_get_children+0x47 isa_probe_children(c433a380,c051c4db,0,c0b35d98,c02e9925) at isa_probe_children+0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c This machine is the 235, as we had to install linux on the 345 to get it into production. I'm not sure how long I can do testing with this machine. Also, if someone knows how to report these backtraces without having to type them in I would be appriciate a heads up on it. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driverpanic
In this mail: http://www.freebsd.org/cgi/getmsg.cgi? fetch=29403+32287+/usr/local/www/db/text/2003/freebsd-scsi/20030615.freebsd- scsi It was suggested to do a backtrace on it. I didn't have the option in 5.1- RELEASE, but I grabbed the 20030624 snapshot and was able to get the following information. First of all the error seems slightly different, but the end result is the same, unable to boot fully. First I get (the relevant parts IMO): .. pcib5: at pcibus 5 on motherboard pci5: on pcib5 ips0: mem 0xf400--xf7ff irq 9 at device 3.0 on pci5 ips0: failed to get configuration from device device_probe_and_attach: ips0 attach returned 6 .. pci9: in pcib9 Memory modified after free 0xc18cd700(252) panic: Most recently used by devbuf Here's the trace: Debugger(c0502455,c05c50e0,c05193ad,c0b35ca4,100) at Debugger+0x54 panic(c05193ad,c0500cf7,fc,c0c3aea0) at panic+0xcc mtrash_ctor(c18cd700,100,0,553,0) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3aea0,0,101,c0327620,c0599b48) at uma_zalloc_arg+0x17f malloc(a8,c0556960,101,c052254c,c0b35d6c) at malloc+0xd4 device_get_children(c433a380,c0b35d58,c0b35d5c,c0325c62,c18dd700) at device_get_children+0x47 isa_probe_children(c433a380,c051c4db,0,c0b35d98,c02e9925) at isa_probe_children+0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c This machine is the 235, as we had to install linux on the 345 to get it into production. I'm not sure how long I can do testing with this machine. Also, if someone knows how to report these backtraces without having to type them in I would be appriciate a heads up on it. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PATCH: move cardbus container to "pci" devclass
Hello I have made a patch for -CURRENT and 5.1-RELEASE that hopefully improves the support for Cardbus devices by changing the "cardbus" driver to implement the "pci" devclass rather than the "cardbus" devclass, and to make their unit numbers correspond with the PCI secondary bus numbers that their bridges are assigned. This has a number of advantages: - User mode tools that interface with the /dev/pci interface such as pciconf and lspci (from ports) are now able to access Cardbus devices without modifications. - PCI drivers no longer need an additional driver declaration in order to support cardbus, e.g., in ./pci/if_xl.c:DRIVER_MODULE(xl, cardbus, xl_driver, xl_devclass, 0, 0); ./pci/if_xl.c:DRIVER_MODULE(xl, pci, xl_driver, xl_devclass, 0, 0); only the second line is required. (The first is harmless though.) - Because the unit numbers in the "pci" devclass now represent the PCI bus numbers in use in the system, we now have a good way of assigning bus numbers to the Cardbus bridges in lieu of the PCI BIOS doing so, which is not something we can expect all BIOSes to do. (The old code incremented a static counter starting from 2 by 3 every time this condition occurred, which wasn't correct because there could already be a pci2 in the system, and the counter would eventually recycle.) And a couple of potential drawbacks: - Drivers that need to behave differently for Cardbus devices can't do so by declaring another driver_t specifically for cardbus. (No driver that I'm aware of does this, however; they all use the same driver_t.) - Users that are accustomed to newbus nameunits containing descriptive information about devices may prefer to see, for example, "cardbus0" rather than "pci2". Note that using newbus in this way defeats a good deal of its potential for object-oriented design. The patches are at http://users.erols.com/eaja/cardbus51.diff http://users.erols.com/eaja/cardbuscurrent.diff Any comments? Thanks, Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-25 18:16:25 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-25 18:16:25 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-25 18:18:43 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -mcpu=pentiumpro-c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/jot/jot.c cc -O -pipe -mcpu=pentiumpro -o jot jot.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump/../..-c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump/kdump.c cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump/../..-c ioctl.c In file included from ioctl.c:74: /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/net80211/ieee80211_ioctl.h:40: redefinition of `struct ieee80211req' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/kdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-25 19:06:29 - /usr/bin/make returned exit code 1 TB --- 2003-06-25 19:06:29 - ERROR: failed to build world TB --- 2003-06-25 19:06:29 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: audigy 2
On Tue, Jun 24, 2003 at 10:39:09AM +0400, Yuriy Tsibizov wrote: > My PCM-only driver is commitable. Diff to emu10k1.c in -current is small > and clear (at least to me). It's stable enought to be commited. But it > will not be commited because sound@ decided to use another driver that > is better than mine. Where is the "sound@" list? I looked at the 2003 freebsd-multimedia list archives and couldn't find any real discussion on this. Where can I get your your PCM-only driver patch? > But I can merge all files into emu10kx.c, emu10kx-pcm.c and > emu10kx-midi.c when I fix it (get MIDI to work, fix PCM recording) and > add all features I want (dynamic routing, DSP resource allocation, > better mixer). If you have a patch to break the current emu10k1.c file into smaller parts (w/o adding bits), I'd be willing to sheppard that into the tree. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: audigy 2
On Mon, Jun 23, 2003 at 11:09:39AM -0700, Greg J. wrote: > Yuriy Tsibizov wrote: > > > Old driver (emu10k1.c) was too big for me to work on it and was > > difficult to add MIDI support. I know that my driver will never go > > into the tree - sound@ decided to use Orlando Bassotto's work. His > > driver is much closer to original emu10k1.c that mine. > > How about making a 'emu10k2' driver for just audigy 2.. and leaving the current > 'emu10k1' alone? I think that is a hack as the two seem to be simular enough there should be a single driver. Now I'm not a sound driver guy at all, so maybe the HW interface is different enough to warent that. I wish someone with more clue than I would charge forward and commit some of the patches running around. :-( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-25 17:27:03 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-25 17:27:03 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-25 17:28:46 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -mcpu=pentiumpro-c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/jot/jot.c cc -O -pipe -mcpu=pentiumpro -o jot jot.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump/../..-c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump/kdump.c cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump/../ktrace -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump/../..-c ioctl.c In file included from ioctl.c:74: /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/net80211/ieee80211_ioctl.h:40: redefinition of `struct ieee80211req' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/kdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-25 18:16:21 - /usr/bin/make returned exit code 1 TB --- 2003-06-25 18:16:21 - ERROR: failed to build world TB --- 2003-06-25 18:16:21 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, 25 Jun 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > M-Trade <[EMAIL PROTECTED]> writes: > : Hello, > : > : Has anyone had any success installing 5.1 release on a 486 > : w/ 8MB RAM? I can't install. > : > : avail memory = (245760) 0 MB > : > : Is this expected behavior? > > Yes. The generic kernel is a big fat pigdog. you might be able to > cope with a stripped down kernel, but sysinstall will dump core unless > you sneak in early in the process and add more swap. you really need > at least 16MB if not 24MB of RAM to install 5 Last week I installed a Pentium 90 with 16 MB - 5.1 couldn't even start the installation menu, 4.8 went well without any problems or special configuration. Uli. > > Warner > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > +---+ |Peter Ulrich Kruppa| | - Wuppertal - | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE crash
On Wed, Jun 25, 2003 at 06:20:33PM +0200, Ian Freislich <[EMAIL PROTECTED]> wrote: > About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give > ULE a go every few months), top started looking really wierd (the > CPU % just kept on accumulating for each process). Before dnetc > started, httpd showed 17% CPU, but the system was supposedly 100% > idle at the time according to top. Then dnetc started and things > got wierd. > > panic: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid = 1; lapic.id = 0100 > fault virtual address = 0x38 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01e094d > stack pointer = 0x10:0xce772be4 > frame pointer = 0x10:0xce772bf4 > 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 = 603 (dnetc) > trap number = 12 > panic: page fault > cpuid = 1; lapic.id = 0100 > Stack backtrace: > boot() called on cpu#1 > > syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown > with interrupts already disabled > cpuid = 1; lapic.id = 0100 > boot() called on cpu#1 > Uptime: 4m15s > Dumping 191 MB > ata0: resetting devices .. > done > 16 32 48 64 80 96 112 128 144 160 176 > --- I had the same panic last week after updating and had to disable [EMAIL PROTECTED] to get up in hurry. The last kernel (4BSD) ran fine for a month with two seti processes running. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best way to get max KVA setting?
On Wed, 25 Jun 2003, Terry Lambert wrote: > Mike Silbersack wrote: > > I could probably grep for this, but what's the best way to get a hold of > > the # of pages (or MB of ram) that max KVA is set to? I'm adding another > > autosize option, and I want to base it on min (KVA, ram) so that it > > doesn't balloon on boxes where ram >> KVA. > > I posted a patch about a month ago that did exactly this. > > It was for a guy who was was running with PAE enabled on an > 8G machine, and the autotuning was shooting him in the foot > when it tried to grab enough memory to create kmem_map entries > for the 8G of RAM in his 2G KVA space, and its head exploded. > > Let me know if you can't find it in the -current archives, and > I can dig it out for you, if you're willing to wait a day or > two. > > -- Terry I found the thread in question, but I didn't see a patch. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE crash
On Wed, 25 Jun 2003, Ian Freislich wrote:
> Hi
>
> About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give
> ULE a go every few months), top started looking really wierd (the
> CPU % just kept on accumulating for each process). Before dnetc
> started, httpd showed 17% CPU, but the system was supposedly 100%
> idle at the time according to top. Then dnetc started and things
> got wierd.
There is some bug that is preventing sleeping processes from loosing old
cpu usage. I'm looking into that. Can you tell me what version of the
sched_ule.c file you have? This looks like an old panic.
Thanks,
Jeff
>
> last pid: 607; load averages: 1.83, 0.63, 0.25up 0+00:04:23 16:00:48
> 35 processes: 3 running, 32 sleeping
> CPU states: 0.0% user, 99.0% nice, 0.6% system, 0.4% interrupt, 0.0% idle
> Mem: 20M Active, 14M Inact, 19M Wired, 20K Cache, 25M Buf, 130M Free
> Swap: 512M Total, 512M Free
>
> PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND
> 603 ianf 139 20 1072K 880K RUN0 0:39 105.47% 105.47% dnetc
> 575 ianf 139 20 1072K 880K CPU1 1 1:15 102.34% 102.34% dnetc
> 505 root 760 7208K 5420K select 0 0:01 17.97% 17.97% httpd
> 375 root40 1276K 948K accept 0 0:00 9.38% 9.38% nfsd
> 526 nobody 760 9280K 8564K select 1 0:04 5.47% 5.47% squid
> 607 ianf 760 2196K 1444K CPU0 0 0:00 2.34% 2.34% top
>
> Then it froze. When I got home I found that it had at least dumped
> vmcore.24. I'll keep it around for a while and perform any inspections
> people want me to. This was with sources updated at 13h30 GMT today.
>
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; lapic.id = 0100
> fault virtual address = 0x38
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01e094d
> stack pointer = 0x10:0xce772be4
> frame pointer = 0x10:0xce772bf4
> 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 = 603 (dnetc)
> trap number = 12
> panic: page fault
> cpuid = 1; lapic.id = 0100
> Stack backtrace:
> boot() called on cpu#1
>
> syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown
> with interrupts already disabled
> cpuid = 1; lapic.id = 0100
> boot() called on cpu#1
> Uptime: 4m15s
> Dumping 191 MB
> ata0: resetting devices ..
> done
> 16 32 48 64 80 96 112 128 144 160 176
> ---
>
> (kgdb) bt
> #0 doadump () at ../../../kern/kern_shutdown.c:240
> #1 0xc01cbe7f in boot (howto=260) at ../../../kern/kern_shutdown.c:372
> #2 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
> #3 0xc02e8f89 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
> at ../../../i386/i386/mp_machdep.c:2356
> #4 0xc02e92a9 in smp_invlpg_range (addr1=0, addr2=0)
> at ../../../i386/i386/mp_machdep.c:2488
> #5 0xc02eb548 in pmap_invalidate_range (pmap=0xc03996e0, sva=3365310464,
> eva=3365314560) at ../../../i386/i386/pmap.c:721
> #6 0xc02eb83d in pmap_qenter (sva=3365310464, m=0xce772884, count=0)
> at ../../../i386/i386/pmap.c:948
> #7 0xc0218a31 in vm_hold_load_pages (bp=0xc76039a0, from=0, to=3365318656)
> at ../../../kern/vfs_bio.c:3574
> #8 0xc0216f5a in allocbuf (bp=0xc76039a0, size=8192)
> at ../../../kern/vfs_bio.c:2752
> #9 0xc0216cee in geteblk (size=8192) at ../../../kern/vfs_bio.c:2634
> #10 0xc0213980 in bwrite (bp=0xc75b65d8) at ../../../kern/vfs_bio.c:818
> #11 0xc02142dc in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1153
> #12 0xc021d89a in vop_stdfsync (ap=0xce772a14)
> at ../../../kern/vfs_default.c:742
> #13 0xc0193570 in spec_fsync (ap=0xce772a14)
> at ../../../fs/specfs/spec_vnops.c:417
> #14 0xc0192a38 in spec_vnoperate (ap=0x0)
> at ../../../fs/specfs/spec_vnops.c:122
> #15 0xc0294c62 in ffs_sync (mp=0xc3950a00, waitfor=2, cred=0xc0d06e80,
> td=0xc03702a0) at vnode_if.h:624
> #16 0xc022b15b in sync (td=0xc03702a0, uap=0x0)
> at ../../../kern/vfs_syscalls.c:142
> #17 0xc01cb9a1 in boot (howto=256) at ../../../kern/kern_shutdown.c:281
> #18 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
> #19 0xc02f0da2 in trap_fatal (frame=0xce772ba4, eva=0)
> at ../../../i386/i386/trap.c:836
> #20 0xc02f0333 in trap (frame=
> {tf_fs = -1060044776, tf_es = -831062000, tf_ds = -1071775728, tf_edi =
> -1014422336, tf_esi = -1070107520, tf_ebp = -831050764, tf_isp = -831050800, tf_ebx
> = 0, tf_edx = 0, tf_ecx = -1059988168, tf_eax = 0, tf_trapno = 12, tf_err = 0,
> tf_eip = -1071773363, tf_cs = 8, tf_eflags = 66194, tf_esp = -1070107520, tf_ss =
> 0}) at ../../../i386/i386/trap.c:256
> #21 0xc02d8eb8 in calltrap () at {standard input}:97
> #22 0xc01e188b in sched_choose () at ../.
Re: tcsh being dodgy, or pipe code ishoos?
Tim Kientzle wrote this message on Wed, Jun 25, 2003 at 09:51 -0700: [...] > >Say the shell you run the above command is 10. It will fork to create > >a shell to run the commands in the outter parens. Call this 11. 11's > >job is to run: (echo 2; echo 3) | ./xargs -I% echo +% > >11 will fork/exec and run: echo 2; echo 3 creating process 12. 11 > >will see that there is no additional commands after ./xargs, and > >exec (not fork) xargs. Since 12 is stil around and a child of 11, > >when it exits, 11 will reap 12, and thinking that the first proccess > >has exited, run the second echo command. Due to scheduling, we'll > >have two processes running at the same time which can cause the > >interleaving of data. [...] > Fixing the shell would also be desirable, as Terry points > out, though it does involve removing a nice optimization. > Why do exec-ed processes inherit the children of the former > process, anyway? That doesn't entirely sound right to me. > Is that behavior mandated by some standard? If not, this > could arguably be considered a kernel bug. Hmmm... Could someone look into this for me? I don't have any of the standards document. Hmmm. does APUE even talk about this? It's more of a question if exec'd processes inherit children. hmm. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
Tim J. Robbins wrote this message on Wed, Jun 25, 2003 at 19:20 +1000: > On Wed, Jun 25, 2003 at 12:41:51AM -0700, John-Mark Gurney wrote: > > [...] > > So, now the question is, do we fix xargs to deal with unexpected > > children? Or fix the shells in question? (tcsh and zsh seem to suffer > > this problem) > > > > To me, fixing xargs is correct since it prevents another possible > > future abusers of this "feature". > > Feel free to get rid of the -P option. What tcsh and zsh are doing is a fairly > bad idea though, and it will break more than just xargs. I think -P for xargs is a GOOD option. There are cases that this is very useful. It is pretty trivial to fix too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
> Date: Wed, 25 Jun 2003 19:16:52 +0200 > From: Socketd <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Hi all > > I have just installed 5.1 Release on my laptop (6gb harddisk and 60 mb > ram). I only installed the base system + man pages and the port > collection. A little info: > / 128M > Swap 256M > /var 128M > /var/tmp 256M (/tmp is symlinked to this) > /home 256M > /usr The rest > > I compiled a new kernel, with no support for SCSI, RAID, IPv6 and all > but my USB NIC (also removed a few USB things). I added: > options SC_DISABLE_REBOOT > options MAC > device pcm > > It compiled fine and I installed it. Now, if I run with this kernel the > system freezes! I can boot, login and run a few commands, but that's it. > There is nothing in the logs, but when I tried ssh'ing to the mashine I > got this before it froze: > fork() - Not enough ressources available at this time > > (or something like that). > > Is there a memory leak somewhere or am I doing something wrong? (I > compiled and installed the kernel with: > make buildkernel KERNCONF=SOCKETD > make installkernel KERNCONF=SOCKETD) Providing your complete configuration file and /var/run/dmesg.boot might give a bit of a clue. You do mention that you are using MAC. The MAC code is rather new and clearly labeled as experimental, so that might be a source of the problem. Can you try building a kernel without MAC? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.1-Release freezes
Hi all I have just installed 5.1 Release on my laptop (6gb harddisk and 60 mb ram). I only installed the base system + man pages and the port collection. A little info: / 128M Swap256M /var128M /var/tmp 256M (/tmp is symlinked to this) /home 256M /usrThe rest I compiled a new kernel, with no support for SCSI, RAID, IPv6 and all but my USB NIC (also removed a few USB things). I added: options SC_DISABLE_REBOOT options MAC device pcm It compiled fine and I installed it. Now, if I run with this kernel the system freezes! I can boot, login and run a few commands, but that's it. There is nothing in the logs, but when I tried ssh'ing to the mashine I got this before it froze: fork() - Not enough ressources available at this time (or something like that). Is there a memory leak somewhere or am I doing something wrong? (I compiled and installed the kernel with: make buildkernel KERNCONF=SOCKETD make installkernel KERNCONF=SOCKETD) btw please cc to me as I am not on the list. br socketd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/libexec/save-entropy problem
Simon L. Nielsen wrote: On 2003.06.25 18:38:59 +0200, Rob wrote: I get e-mails from my current boxes saying: "hostname: sethostname: Operation not permitted" (original message attached). I know this is the random seed saving instance of crontab, but what goes wrong here ? (why does it fail permission) The box is updated today and mergemaster was run (This didn't help a thing ;-)) What does your /etc/rc.conf contain ? Perhaps you have commands which sets the hostname in there ? Mmmph, I had the line: 'hostname slopuh.debank.tv' in my rc.conf, this ofcourse should have been 'hostname="slopuh.debank.tv"' The funny thing is that the host name did show up correct. Problem solved thx! Rob Evers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
John-Mark Gurney wrote: ok, with some magic ktrace work, I have come up with an more complete answer to the riddle. It's how the shell exec's the processes. The bare cause can be demo'd by: ( ( echo 2 ; echo 3 ) | ./xargs -I% echo + % ) Say the shell you run the above command is 10. It will fork to create a shell to run the commands in the outter parens. Call this 11. 11's job is to run: (echo 2; echo 3) | ./xargs -I% echo +% 11 will fork/exec and run: echo 2; echo 3 creating process 12. 11 will see that there is no additional commands after ./xargs, and exec (not fork) xargs. Since 12 is stil around and a child of 11, when it exits, 11 will reap 12, and thinking that the first proccess has exited, run the second echo command. Due to scheduling, we'll have two processes running at the same time which can cause the interleaving of data. So, now the question is, do we fix xargs to deal with unexpected children? Or fix the shells in question? (tcsh and zsh seem to suffer this problem) To me, fixing xargs is correct since it prevents another possible future abusers of this "feature". Good work! Congratulations on figuring that one out. It's probably best to fix both. Fixing xargs basically involves keeping a list of child PIDs and checking harvested children against that list. If the child wasn't spawned by xargs, it should just ignore it (in particular, not decrement curprocs). Not entirely trivial, but not a lot of work, either. Fixing the shell would also be desirable, as Terry points out, though it does involve removing a nice optimization. Why do exec-ed processes inherit the children of the former process, anyway? That doesn't entirely sound right to me. Is that behavior mandated by some standard? If not, this could arguably be considered a kernel bug. Hmmm... Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/libexec/save-entropy problem
On 2003.06.25 18:38:59 +0200, Rob wrote: > I get e-mails from my current boxes saying: "hostname: sethostname: > Operation not permitted" (original message attached). > I know this is the random seed saving instance of crontab, but what > goes wrong here ? (why does it fail permission) > > The box is updated today and mergemaster was run (This didn't help a > thing ;-)) What does your /etc/rc.conf contain ? Perhaps you have commands which sets the hostname in there ? -- Simon L. Nielsen pgp0.pgp Description: PGP signature
DMA failed to complete' and 'packets buffered, but transmitter idle
Hi, Since the big fixes in the pccard code (by Warner Losh), at a date that I can't remember of because I was busy at this time but it's two weeks or more, I am getting errors with my NIC everytime I use it: [...] ed0: remote transmit DMA failed to complete ed: packets buffered, but transmitter idle ed0: remote transmit DMA failed to complete ed0: remote transmit DMA failed to complete ed: packets buffered, but transmitter idle ed0: remote transmit DMA failed to complete [...] but the NIC seems to work. But the real problem is when I shutdown or reboot my box, it stops forever after 'Uptime...' and I have to manually power off my computer (it's a laptop, not reset button :/). When these messages don't appear, the box reboots correctly. Any ideas ? I'm running on FreeBSD 5.1-CURRENT -- Aurelien PS: Please send me a copy of each reply, I'm not a member of the list. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/usr/libexec/save-entropy problem
Hi all, I get e-mails from my current boxes saying: "hostname: sethostname: Operation not permitted" (original message attached). I know this is the random seed saving instance of crontab, but what goes wrong here ? (why does it fail permission) The box is updated today and mergemaster was run (This didn't help a thing ;-)) System: FreeBSD slopuh.debank.tv 5.1-CURRENT FreeBSD 5.1-CURRENT #16: Wed Jun 25 16:33:15 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SLOPUH i386 Original Message Subject: Cron <[EMAIL PROTECTED]> /usr/libexec/save-entropy Date: Wed, 25 Jun 2003 16:00:00 +0200 (CEST) From: [EMAIL PROTECTED] (Cron Daemon) To: [EMAIL PROTECTED] hostname: sethostname: Operation not permitted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ULE crash
Hi
About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give
ULE a go every few months), top started looking really wierd (the
CPU % just kept on accumulating for each process). Before dnetc
started, httpd showed 17% CPU, but the system was supposedly 100%
idle at the time according to top. Then dnetc started and things
got wierd.
last pid: 607; load averages: 1.83, 0.63, 0.25up 0+00:04:23 16:00:48
35 processes: 3 running, 32 sleeping
CPU states: 0.0% user, 99.0% nice, 0.6% system, 0.4% interrupt, 0.0% idle
Mem: 20M Active, 14M Inact, 19M Wired, 20K Cache, 25M Buf, 130M Free
Swap: 512M Total, 512M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND
603 ianf 139 20 1072K 880K RUN0 0:39 105.47% 105.47% dnetc
575 ianf 139 20 1072K 880K CPU1 1 1:15 102.34% 102.34% dnetc
505 root 760 7208K 5420K select 0 0:01 17.97% 17.97% httpd
375 root40 1276K 948K accept 0 0:00 9.38% 9.38% nfsd
526 nobody 760 9280K 8564K select 1 0:04 5.47% 5.47% squid
607 ianf 760 2196K 1444K CPU0 0 0:00 2.34% 2.34% top
Then it froze. When I got home I found that it had at least dumped
vmcore.24. I'll keep it around for a while and perform any inspections
people want me to. This was with sources updated at 13h30 GMT today.
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01e094d
stack pointer = 0x10:0xce772be4
frame pointer = 0x10:0xce772bf4
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 = 603 (dnetc)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 4m15s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc01cbe7f in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc02e8f89 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2356
#4 0xc02e92a9 in smp_invlpg_range (addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2488
#5 0xc02eb548 in pmap_invalidate_range (pmap=0xc03996e0, sva=3365310464,
eva=3365314560) at ../../../i386/i386/pmap.c:721
#6 0xc02eb83d in pmap_qenter (sva=3365310464, m=0xce772884, count=0)
at ../../../i386/i386/pmap.c:948
#7 0xc0218a31 in vm_hold_load_pages (bp=0xc76039a0, from=0, to=3365318656)
at ../../../kern/vfs_bio.c:3574
#8 0xc0216f5a in allocbuf (bp=0xc76039a0, size=8192)
at ../../../kern/vfs_bio.c:2752
#9 0xc0216cee in geteblk (size=8192) at ../../../kern/vfs_bio.c:2634
#10 0xc0213980 in bwrite (bp=0xc75b65d8) at ../../../kern/vfs_bio.c:818
#11 0xc02142dc in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1153
#12 0xc021d89a in vop_stdfsync (ap=0xce772a14)
at ../../../kern/vfs_default.c:742
#13 0xc0193570 in spec_fsync (ap=0xce772a14)
at ../../../fs/specfs/spec_vnops.c:417
#14 0xc0192a38 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:122
#15 0xc0294c62 in ffs_sync (mp=0xc3950a00, waitfor=2, cred=0xc0d06e80,
td=0xc03702a0) at vnode_if.h:624
#16 0xc022b15b in sync (td=0xc03702a0, uap=0x0)
at ../../../kern/vfs_syscalls.c:142
#17 0xc01cb9a1 in boot (howto=256) at ../../../kern/kern_shutdown.c:281
#18 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#19 0xc02f0da2 in trap_fatal (frame=0xce772ba4, eva=0)
at ../../../i386/i386/trap.c:836
#20 0xc02f0333 in trap (frame=
{tf_fs = -1060044776, tf_es = -831062000, tf_ds = -1071775728, tf_edi =
-1014422336, tf_esi = -1070107520, tf_ebp = -831050764, tf_isp = -831050800, tf_ebx =
0, tf_edx = 0, tf_ecx = -1059988168, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1071773363, tf_cs = 8, tf_eflags = 66194, tf_esp = -1070107520, tf_ss = 0}) at
../../../i386/i386/trap.c:256
#21 0xc02d8eb8 in calltrap () at {standard input}:97
#22 0xc01e188b in sched_choose () at ../../../kern/sched_ule.c:1161
#23 0xc01d25e6 in choosethread () at ../../../kern/kern_switch.c:140
#24 0xc01d422f in mi_switch () at ../../../kern/kern_synch.c:525
#25 0xc01c1db6 in _mtx_lock_sleep (m=0xc0374a40, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:636
#26 0xc01ca585 in getrusage (td=0x0, uap=0xce772d10)
at ../../../kern/kern_resource.c:773
#27 0xc02f10fc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi
Re: 8MB install
In message: <[EMAIL PROTECTED]> M-Trade <[EMAIL PROTECTED]> writes: : Hello, : : Has anyone had any success installing 5.1 release on a 486 : w/ 8MB RAM? I can't install. : : avail memory = (245760) 0 MB : : Is this expected behavior? Yes. The generic kernel is a big fat pigdog. you might be able to cope with a stripped down kernel, but sysinstall will dump core unless you sneak in early in the process and add more swap. you really need at least 16MB if not 24MB of RAM to install 5 Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-CURRENT 23.06.2003: the floppy has ceased to work
On Wednesday 25 June 2003 17:18, Eugene V. Bontseff wrote: > Hi, > After updating system on June, 23 floppy the disk drive does not > work. > > At loading messages are given out: > >fdc0: cmd 3 failed at out byte 1 of 3 For what it's worth, I get the same with 5.1-RELEASE: [EMAIL PROTECTED] mp3]$ uname -a FreeBSD vimes.int.athame.co.uk 5.1-RELEASE FreeBSD 5.1-RELEASE #7: Sat Jun 14 23:09:29 EEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VIMES i386 [EMAIL PROTECTED] mp3]$ dmesg | grep fdc fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cannot reserve I/O port range (6 ports) Does my floppy drive work? No idea, I never use it, and I'm 20km from it right now so I can't check. A. -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] "In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates." -- anon | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem installing 4.7/4.8, etc
--On Wednesday, June 25, 2003 11:16:33 -0400 Thomas Dickey <[EMAIL PROTECTED]> wrote: Does FreeBSD still implement only one install per machine? (Is it possible to install both 4.x and 5.x on the same box) I have a dual-boot laptop with 4.x and 5.x. It's very easy. there is an article on OnLamp(IIRC) that explains it. Basically, you install to 2 different fdisk partitions, and use boot0, the FreeBSD boot manager. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem installing 4.7/4.8, etc
On Wed, Jun 25, 2003 at 04:56:56PM +0200, Soeren Schmidt wrote: > It seems Hideyuki KURASHINA wrote: > > >From your attached dmesg, > > > > > PCI: Using IRQ router SIS [1039/0008] at 00:02.0 > > [...] > > > SIS5513: IDE controller on PCI bus 00 dev 15 > > > PCI: Found IRQ 5 for device 00:02.5 > > > SIS5513: chipset revision 0 > > > SIS5513: not 100% native mode: will probe irqs later > > > SiS5513 > > > ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA > > > ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio > > > > My first machine, that is about 8 years old model, has SiS 5513. > > It works here since I installed FreeBSD snapshot as of the end of 2003/05. > > Uhm I dont think this is such an old chip actually, all SiS ATA parts > say they are a 5513 :/ but sadly it comes in many flavors... my impression is that it's no newer than last fall, since the "same" chipset appeared in another machine that I got (but it's an end-users' so I didn't add that). > > Recent FreeBSD 4.x would fail to boot because it does not have > > src/sys/dev/ata/ata-chip.c, I think. Soren, My understanding is OK, > > isn't it? > > Yes, the ATA drivers chipset support part has been radically changed > and updated in 5.1/current, the old 4.x ATA driver doesn't understand > the newer SiS parts (and the support for some of the old is wrong as well)... Does FreeBSD still implement only one install per machine? (Is it possible to install both 4.x and 5.x on the same box) -- Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem installing 4.7/4.8, etc
On Wed, Jun 25, 2003 at 11:37:30PM +0900, Hideyuki KURASHINA wrote: > Hi, > > >>> On Wed, 25 Jun 2003 09:49:50 -0400, Thomas Dickey <[EMAIL PROTECTED]> said: > > > I'm setting up a new machine, and none of the current *BSD's install on it. > > Linux works. The *BSD's choke during the device identification. Perhaps > > someone on this list knows why. Attaching a copy of dmesg output from one > > of the Linux's I installed. The *BSD's appear to be missing an interrupt > > in the IDE/PCI bus hardware (about which I know little ;-) > > >From your attached dmesg, > > > PCI: Using IRQ router SIS [1039/0008] at 00:02.0 > [...] > > SIS5513: IDE controller on PCI bus 00 dev 15 > > PCI: Found IRQ 5 for device 00:02.5 > > SIS5513: chipset revision 0 > > SIS5513: not 100% native mode: will probe irqs later > > SiS5513 > > ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA > > ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio > > My first machine, that is about 8 years old model, has SiS 5513. > It works here since I installed FreeBSD snapshot as of the end of 2003/05. > > atapci0: port > 0xfe80-0xfe8f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 1.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: simplex device, DMA on primary only > ata1: at 0x170 irq 15 on atapci0 > > SiS 5513 supports WDMA2, However, some HDDs might freeze when they > detected by kernel. I *have to* type in following instruction The exact message I see for 4.8 is ata1-slave: ATAPI identify retries exceeded ad0: READ command timeout tag=0 serv=0 - resetting which gives me the impression that it's not recognizing the DVD: hdc: _NEC DVD+RW ND-1100A, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 The SiS stuff is all on-board. The nominal specs for this system are at http://www.powerspec.com/systems/archives/system_archive.phtml That is, the 9225 with memory and hard-drives doubled. I'd like to put the 3 BSD's on the second drive. > set hw.ata.ata_dma=0 > > at loader prompt (or put equivalent into /boot/loader.conf) in order to > disable DMA and use PIO transfer for HDDs. That does get it past that point, into the installer. I'll see how far that takes me today (am working now...) > Recent FreeBSD 4.x would fail to boot because it does not have > src/sys/dev/ata/ata-chip.c, I think. Soren, My understanding is OK, > isn't it? I haven't tried 5.1 (I read earlier this year that 5.0 did not support this chipset, and had read that FreeBSD 4.x did, so I started on that path). Is this in 5.1, or is it part of upcoming 5.2? -- Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, Jun 25, 2003 at 02:44:24AM -0700 I heard the voice of Terry Lambert, and lo! it spake thus: > > Alternately, you could find a FreeBSD 1.1.5.1 distribution on the > net somewhere, and install that, instead; I have personally run > that version of FreeBSD on a 4M 386SX, to use it as an X Terminal. > 8-). No need to get silly. My 4M 386SX runs 2.1-STABLE just fine :P -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem installing 4.7/4.8, etc
It seems Hideyuki KURASHINA wrote: > >From your attached dmesg, > > > PCI: Using IRQ router SIS [1039/0008] at 00:02.0 > [...] > > SIS5513: IDE controller on PCI bus 00 dev 15 > > PCI: Found IRQ 5 for device 00:02.5 > > SIS5513: chipset revision 0 > > SIS5513: not 100% native mode: will probe irqs later > > SiS5513 > > ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA > > ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio > > My first machine, that is about 8 years old model, has SiS 5513. > It works here since I installed FreeBSD snapshot as of the end of 2003/05. Uhm I dont think this is such an old chip actually, all SiS ATA parts say they are a 5513 :/ but sadly it comes in many flavors... > Recent FreeBSD 4.x would fail to boot because it does not have > src/sys/dev/ata/ata-chip.c, I think. Soren, My understanding is OK, > isn't it? Yes, the ATA drivers chipset support part has been radically changed and updated in 5.1/current, the old 4.x ATA driver doesn't understand the newer SiS parts (and the support for some of the old is wrong as well)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem installing 4.7/4.8, etc
Hi, >>> On Wed, 25 Jun 2003 09:49:50 -0400, Thomas Dickey <[EMAIL PROTECTED]> said: > I'm setting up a new machine, and none of the current *BSD's install on it. > Linux works. The *BSD's choke during the device identification. Perhaps > someone on this list knows why. Attaching a copy of dmesg output from one > of the Linux's I installed. The *BSD's appear to be missing an interrupt > in the IDE/PCI bus hardware (about which I know little ;-) >From your attached dmesg, > PCI: Using IRQ router SIS [1039/0008] at 00:02.0 [...] > SIS5513: IDE controller on PCI bus 00 dev 15 > PCI: Found IRQ 5 for device 00:02.5 > SIS5513: chipset revision 0 > SIS5513: not 100% native mode: will probe irqs later > SiS5513 > ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA > ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio My first machine, that is about 8 years old model, has SiS 5513. It works here since I installed FreeBSD snapshot as of the end of 2003/05. atapci0: port 0xfe80-0xfe8f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 SiS 5513 supports WDMA2, However, some HDDs might freeze when they detected by kernel. I *have to* type in following instruction set hw.ata.ata_dma=0 at loader prompt (or put equivalent into /boot/loader.conf) in order to disable DMA and use PIO transfer for HDDs. Recent FreeBSD 4.x would fail to boot because it does not have src/sys/dev/ata/ata-chip.c, I think. Soren, My understanding is OK, isn't it? -- rushani ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-CURRENT 23.06.2003: the floppy has ceased to work
Hi, After updating system on June, 23 floppy the disk drive does not work. At loading messages are given out: >fdc0: cmd 3 failed at out byte 1 of 3 How to me to resolve this problem? Full dmesg it is applied. Eugene V. Boontseff Copyright (c) 1992-2003 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.1-CURRENT #16: Wed Jun 25 06:00:16 MSD 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EUKERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc05cc000. Preloaded elf module "/boot/modules/vesa.ko" at 0xc05cc26c. Preloaded elf module "/boot/modules/acpi.ko" at 0xc05cc318. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1804102976 Hz CPU: Intel(R) Celeron(R) CPU 1.80GHz (1804.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 Features=0x3febfbff real memory = 536805376 (511 MB) avail memory = 514953216 (491 MB) netsmb_dev: loaded Pentium Pro MTRR support enabled VESA: v2.0, 131072k memory, flags:0x1, mode table:0xc057ebe2 (122) VESA: ATI RADEON RV250 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f7a60 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc14ed1a0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc14ed0e0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc14ed0e0), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.PCI0 - AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc14ed1a0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc4070c40), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc4070c40), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.MEM_ - AE_AML_REGION_LIMIT acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib0: slot 29 INTA is routed to irq 11 pcib0: slot 29 INTB is routed to irq 10 pcib0: slot 29 INTC is routed to irq 10 pcib0: slot 29 INTD is routed to irq 12 pcib0: slot 31 INTB is routed to irq 12 agp0: mem 0xe000-0xe07f at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 drm0: port 0xa800-0xa8ff mem 0xdfdf-0xdfdf,0xd000-0xd7ff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe000 8MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 pci1: at device 0.1 (no driver attached) uhci0: port 0xd400-0xd41f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: vendor 0x062a product 0x, rev 1.10/2.04, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: port 0xd800-0xd81f irq 10 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xdc00-0xdc1f irq 10 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdc00-0xdfff irq 12 at device 29.7 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci3: on pcib2 pcib2: slot 1 INTA is routed to irq 12 pcib2: slot 2 INTA is routed to irq 10 dc0: port 0xb800-0xb87f mem 0xdfefec00-0xdfefefff irq 12 at device 1.0 on pci3 dc0: Ethernet address: 00:80:48:b3:53:a6 miibus0: on dc0 amphy0: on miibus0 amphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xbc00-0xbcff mem 0xdfeff000-0xdfef irq 10 at device 2.0 on pci3 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xcc00-0xcc3f,0xd000-0xd0ff mem 0xd900-0xd9ff,0xda00-0xdbff irq 12 at device 31.5 on pci0 pcm0: acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x
Re: problem installing 4.7/4.8, etc
It seems Thomas Dickey wrote: > I'm setting up a new machine, and none of the current *BSD's install on it. > Linux works. The *BSD's choke during the device identification. Perhaps > someone on this list knows why. Attaching a copy of dmesg output from one > of the Linux's I installed. The *BSD's appear to be missing an interrupt > in the IDE/PCI bus hardware (about which I know little ;-) Hmm from the dmesg's it looks like a fairly new SiS chipset which is only supported in 5.1 forward, doesn't that work ? and if not how exactly does it fail ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fatal trap 12 during boot, sys/dev/pci/pci.c
I upgrade my world to latest current yesterday. And it panic on my notebook during boot, around pci messages. I use GENERIC config for this testing. And I unset acpi_load, otherwise it will hang during boot. Here is the panic message. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fe840 pcib0: at pcibus 0 on motherboard pci0: on pcib0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xeb813 fault code= supervisor read, page not present instruction pointer = 0x8:0xc00eb714 stack pointer = 0x10:0xc06fda3c frame pointer = 0x10:0xc06fda3c 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 = 0 (swapper) kernel: type 12 trap, code=0 Stopped at 0xc00eb714: cmpb%cs:0x1(%esi),%bl db> tr kernbase(c0d31580,c04a499d,c06fdad4,50d,38) at 0xc00eb714 _end(cb9d08c4,c4f6ec8b,81067540,e5,e67f2400) at 0xc06fdaa8 db> After binary search, I found the difference between panic or not is reversion 1.215 and 1.216 of sys/dev/pci/pci.c. Kernel panic all from 1.216 to 1.221 of pci.c. If you want to have more information, please let me know. pgp0.pgp Description: PGP signature
Re: passwd NIS+ YP compat mode
On Wed, 25 Jun 2003, Thyer, Matthew wrote: > The silence is deafening. > > Please commit this if it's the correct solution. I'll do it in a few days if no-one else has anything to say about it. Speak up or forever hold your peace. > FreeBSD looks real bad when it cant be a NIS client of Solaris NIS+ (in YP compat) > servers. > > > -Original Message- > > From: Thyer, Matthew > > Sent: Monday, June 23, 2003 12:04 PM > > To: '[EMAIL PROTECTED]' > > Cc: '[EMAIL PROTECTED]'; Wilkinson, Alex > > Subject:SEC:URe: passwd NIS+ YP compat mode > > > > Yoshinori's patch for FreeBSD NIS clients of Solaris NIS+ servers in YP > > compatibility mode works for me. > > > > Please commit this before 5 becomes -STABLE (I'm shocked the bug has made it into > > 5.1). > > > > Solaris NIS+ servers in YP compatibility is a very common configuration in larger > > enterprises. > > > > -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Best way to get max KVA setting?
I'm that guy who was running PAE on an 8GB machine... BTW, it turns out the problem was _not_ the autotuning, it was simply an overflow of a 32-bit variable in the kernel. It's been fixed in -current, checked in 2 weeks ago. -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 3:26 AM To: Mike Silbersack Cc: [EMAIL PROTECTED] Subject: Re: Best way to get max KVA setting? Mike Silbersack wrote: > I could probably grep for this, but what's the best way to get a hold > of the # of pages (or MB of ram) that max KVA is set to? I'm adding > another autosize option, and I want to base it on min (KVA, ram) so > that it doesn't balloon on boxes where ram >> KVA. I posted a patch about a month ago that did exactly this. It was for a guy who was was running with PAE enabled on an 8G machine, and the autotuning was shooting him in the foot when it tried to grab enough memory to create kmem_map entries for the 8G of RAM in his 2G KVA space, and its head exploded. Let me know if you can't find it in the -current archives, and I can dig it out for you, if you're willing to wait a day or two. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problem installing 4.7/4.8, etc
I'm setting up a new machine, and none of the current *BSD's install on it. Linux works. The *BSD's choke during the device identification. Perhaps someone on this list knows why. Attaching a copy of dmesg output from one of the Linux's I installed. The *BSD's appear to be missing an interrupt in the IDE/PCI bus hardware (about which I know little ;-) -- Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com Linux version 2.4.20 ([EMAIL PROTECTED]) (gcc version 3.2.2) #2 Mon Mar 17 22:02:15 PST 2003 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3dff (usable) BIOS-e820: 3dff - 3dff3000 (ACPI NVS) BIOS-e820: 3dff3000 - 3e00 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. On node 0 totalpages: 229376 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=vmlinuz ramdisk_size=7000 root=/dev/hda12 vga=normal ro Initializing CPU#0 Detected 2666.641 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 5321.52 BogoMIPS Memory: 904536k/917504k available (1733k kernel code, 12580k reserved, 568k data, 112k init, 0k highmem) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) CPU: L1 I cache: 0K, L1 D cache: 8K CPU: L2 cache: 512K CPU: After generic, caps: bfebfbff CPU: Common caps: bfebfbff CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz stepping 07 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfbbb0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router SIS [1039/0008] at 00:02.0 PCI: Found IRQ 5 for device 00:02.5 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Diskquotas version dquot_6.4.0 initialized Journalled Block Device driver loaded pty: 512 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10e Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 15 PCI: Found IRQ 5 for device 00:02.5 SIS5513: chipset revision 0 SIS5513: not 100% native mode: will probe irqs later SiS5513 ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 4R120L0, ATA DISK drive hdb: Maxtor 6Y120P0, ATA DISK drive hdc: _NEC DVD+RW ND-1100A, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=14946/255/63 hdb: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=15881/240/63 hdc: ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache Uniform CD-ROM driver Revision: 3.12 ide-floppy driver 0.99.newide Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 > hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 7000K size 1024 blocksize loop: loaded (max 8 devices) ide-floppy driver 0.99.newide SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: measuring checksumming speed 8regs : 3099.200 MB/sec 32regs: 2028.000 MB/sec pIII_sse : 3482.400 MB/sec pII_mmx : 3123.200 MB/sec p5_mmx: 3027.200 MB/sec raid5: using function: pIII_sse (3482.400 MB/sec) md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. LVM version 1.0.5+(22/07/2002) NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP,
kernel : exclusive sleep mutex problem
Hi, i have nearly ported the SapDB (www.sapdb.org), an oracle like open source database from SAP AG, to FreeBSD. It is running fine on FreeBSD5.0, but as i updated to 5.1-Release, most of the binaries got stuck. (Also when i recompile with 5.1 libs). I soon updated to a kernel from 2003.06.23, to have a more recent one, but it didnt help. The kernel dumps an error like this : Sleeping on "stopevent" with the following non-sleepablelocks held: exclusive sleep mutex sigacts r = 0 (0xc684caa8) locked @ kern/subr_trap.c:250 The SAPDB port can be found ( as a beta preview ) on http://www.komadev.de/sapdb It is heavily using linuxthreads, but i dont think it should be a problem in 5.1 ... ? Note : When i put the 5.0 libraries like libc.so and libm.so in the LD_LIBRARY_PATH, it seems to run fine, but this is not a real solution for me ... Thanks for your help. Kai -- <---> <-> ... but believe is not to know it, believe is just a fake ... <-> <---> <-> mailto:[EMAIL PROTECTED] <-> <---> +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, Jun 25, 2003 at 12:45:19PM +0200, Simon L. Nielsen wrote: > On 2003.06.25 12:10:42 +0200, Michael Nottebrock wrote: > > On Wednesday 25 June 2003 11:44, Terry Lambert wrote: > > > > > Alternately, you could find a FreeBSD 1.1.5.1 distribution on the > > > net somewhere, and install that, instead; I have personally run > > > that version of FreeBSD on a 4M 386SX, to use it as an X Terminal. > > > 8-). > > > > FWIW, the last FreeBSD release I managed to install on an 8mb machine from > > CD-ROM+bootfloppies was 4.1.1. > > Can anybody else confirm this ? It seems like the documetation need to > be updated to state this. > > Have anybody made any recent tests on CURRENT (and STABLE for that > matter) with regards to minimum RAM requirements, install and normal > runtime? CURRENT in 8MB is a joke. For 4.x the minimum to get an installer running was something like 12MB for years now. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On 2003.06.25 12:10:42 +0200, Michael Nottebrock wrote: > On Wednesday 25 June 2003 11:44, Terry Lambert wrote: > > > Alternately, you could find a FreeBSD 1.1.5.1 distribution on the > > net somewhere, and install that, instead; I have personally run > > that version of FreeBSD on a 4M 386SX, to use it as an X Terminal. > > 8-). > > FWIW, the last FreeBSD release I managed to install on an 8mb machine from > CD-ROM+bootfloppies was 4.1.1. Can anybody else confirm this ? It seems like the documetation need to be updated to state this. Have anybody made any recent tests on CURRENT (and STABLE for that matter) with regards to minimum RAM requirements, install and normal runtime? -- Simon L. Nielsen pgp0.pgp Description: PGP signature
YP Problem
Hi how can I turn on support for protocol version1 in yp on freebsd 5.2 if this machine ist the yp master server. sincerley gerald mixa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wednesday 25 June 2003 11:44, Terry Lambert wrote: > Alternately, you could find a FreeBSD 1.1.5.1 distribution on the > net somewhere, and install that, instead; I have personally run > that version of FreeBSD on a 4M 386SX, to use it as an X Terminal. > 8-). FWIW, the last FreeBSD release I managed to install on an 8mb machine from CD-ROM+bootfloppies was 4.1.1. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: tcsh being dodgy, or pipe code ishoos?
John-Mark Gurney wrote: > So, now the question is, do we fix xargs to deal with unexpected > children? Or fix the shells in question? (tcsh and zsh seem to suffer > this problem) > > To me, fixing xargs is correct since it prevents another possible > future abusers of this "feature". Fixing the shells is correct, since it means they don't break on the next program like xargs (e.g. have you tried "team", etc. to see if they break too? Even if "team" specifically doesn't, there's no guarantee something else won't...). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
M-Trade wrote: > Has anyone had any success installing 5.1 release on a 486 > w/ 8MB RAM? I can't install. > > avail memory = (245760) 0 MB > > Is this expected behavior? Until you build a skinnier kernel, you only have 240K of memory in which to run processes. Normally, the install process uses a great huge chunk of memory for a RAM disk, which it mounts as root. Your best bet is to install the drive on another machine, or temporarily install RAM in the 486. After the install, it should barely crawl in 8M. If you want to actually fit in 8M, you should rebuild a custom kernel that leaves out all the devices for which FreeBSD has drivers, but which you do not have installed in your machine. You may also want to leave out NFS, and drivers for things which *are* installed in your machine, but which you don't intend to use (e.g. sound cards, etc.). Alternately, you could find a FreeBSD 1.1.5.1 distribution on the net somewhere, and install that, instead; I have personally run that version of FreeBSD on a 4M 386SX, to use it as an X Terminal. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: passwd NIS+ YP compat mode
The silence is deafening.
Please commit this if it's the correct solution.
FreeBSD looks real bad when it cant be a NIS client of Solaris NIS+ (in YP compat)
servers.
> -Original Message-
> From: Thyer, Matthew
> Sent: Monday, June 23, 2003 12:04 PM
> To: '[EMAIL PROTECTED]'
> Cc: '[EMAIL PROTECTED]'; Wilkinson, Alex
> Subject: SEC:URe: passwd NIS+ YP compat mode
>
> Yoshinori's patch for FreeBSD NIS clients of Solaris NIS+ servers in YP
> compatibility mode works for me.
>
> Please commit this before 5 becomes -STABLE (I'm shocked the bug has made it into
> 5.1).
>
> Solaris NIS+ servers in YP compatibility is a very common configuration in larger
> enterprises.
>
>
> On Tue, 27 May 2003 18:09:29 -0700, TOMITA Yoshinori wrote:
>
> I hope this patch will solve this problem for users living under NIS+
> servers.
>
> I guess yp_order() is used to check masswd.by* or master.passwd.by*
> databese really exists. yp_master() can be used for this purpose. But
> I do not know the cost of yp_master() compared to yp_order().
>
>
> --- /usr/src/lib/libc/gen/getpwent.c.bakTue May 27 08:47:24 2003
> +++ /usr/src/lib/libc/gen/getpwent.cWed May 28 09:35:50 2003
> @@ -938,14 +938,15 @@
> nis_map(char *domain, enum nss_lookup_type how, char *buffer, size_t bufsize,
> int *master)
> {
> - int rv, order;
> + int rv;
> + char*outname;
>
> *master = 0;
> if (geteuid() == 0) {
> if (snprintf(buffer, bufsize, "master.passwd.by%s",
> (how == nss_lt_id) ? "uid" : "name") >= bufsize)
> return (NS_UNAVAIL);
> - rv = yp_order(domain, buffer, &order);
> + rv = yp_master(domain, buffer, &outname);
> if (rv == 0) {
> *master = 1;
> return (NS_SUCCESS);
> @@ -954,7 +955,7 @@
> if (snprintf(buffer, bufsize, "passwd.by%s",
> (how == nss_lt_id) ? "uid" : "name") >= bufsize)
> return (NS_UNAVAIL);
> - rv = yp_order(domain, buffer, &order);
> + rv = yp_master(domain, buffer, &outname);
> if (rv == 0)
> return (NS_SUCCESS);
> return (NS_UNAVAIL);
>
>
>
> --
> ---
> TOMITA Yoshinori
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
On Wed, Jun 25, 2003 at 12:41:51AM -0700, John-Mark Gurney wrote: [...] > So, now the question is, do we fix xargs to deal with unexpected > children? Or fix the shells in question? (tcsh and zsh seem to suffer > this problem) > > To me, fixing xargs is correct since it prevents another possible > future abusers of this "feature". Feel free to get rid of the -P option. What tcsh and zsh are doing is a fairly bad idea though, and it will break more than just xargs. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
> Great. Do you also have working battery status now? Does anyone have a 5000e? The fix for the 5000 doesn't fix my suspend/resume problems on my 5000e. However, the battery status works fine using standard /dev/apm from the acpi module. Jason ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
On Wed, 25 Jun 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Vincent Poy <[EMAIL PROTECTED]> writes: > : On Tue, 24 Jun 2003, M. Warner Losh wrote: > : > : > In message: <[EMAIL PROTECTED]> > : > Vincent Poy <[EMAIL PROTECTED]> writes: > : > : Speaking about ACPI, has anyone figured out how to close the lid > : > : without suspending? I remember before, when the lid was closed, it would > : > > : > add the following to your /boot/loader.conf: > : > > : > hw.acpi.lid_switch_state=NONE > : > : Putting it in /boot/loader.conf doesn't work since at some port > : during the system bootup, it will set the hw.acpi.lid_switch_state: S1 > : back to S1. My /boot/loader.conf is as follows: > > you are right. that's what I get for not double checking on my laptop > at home first. Hehe, I thought you knew something we didn't. =) > : Doing /sbin/sysctl -w hw.acpi.lid_switch_state=NONE in > : /etc/rc.local does work which was the way I had it before but without the > : ACPI_DSDT patch, all it does when I close the lid is suspend the machine > : without the LCD going off and the LCD isn't alive until I reboot the > : machine. Same thing happens with hw.acpi.lid_switch_state=S1 even with > : the DSDT patch is that when the system resumes, the LCD is not live > : either. With the DSDT path and hw.acpi.lid_switch_state=NONE, the LCD > : turns off without suspending but when you open the lid, the LCD doesn't > : turn on until you hit Fn-F10. This is with the A10 BIOS on the Dell > : Inspiron 8200. > > this matches my experiences, to a point. I've not tried the patched > dsdt table on my dell yet. :-) Guess there are lots of people with Dell's and IBM Thinkpads. =) Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best way to get max KVA setting?
Mike Silbersack wrote: > I could probably grep for this, but what's the best way to get a hold of > the # of pages (or MB of ram) that max KVA is set to? I'm adding another > autosize option, and I want to base it on min (KVA, ram) so that it > doesn't balloon on boxes where ram >> KVA. I posted a patch about a month ago that did exactly this. It was for a guy who was was running with PAE enabled on an 8G machine, and the autotuning was shooting him in the foot when it tried to grab enough memory to create kmem_map entries for the 8G of RAM in his 2G KVA space, and its head exploded. Let me know if you can't find it in the -current archives, and I can dig it out for you, if you're willing to wait a day or two. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, 25 Jun 2003, M-Trade wrote: > Has anyone had any success installing 5.1 release on a 486 > w/ 8MB RAM? I can't install. > > avail memory = (245760) 0 MB > > Is this expected behavior? Yes. I got pre 5.1 running on a 386dx33 with 16mb; it wouldn't work with 8. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic with yesterday's sources
Hi, My laptop running -CURRENT (with source from yesterday morning), just panic'ed - and I am able to reproduce the problem. First of all, on boot I disable ACPI as it does not work on my system. # dhclient ep0 on which the system crashes, here is console output: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8 :0xc02bd68e stack pointer = 0x10 :0xcd233c30 frame pointer = 0x10 :0xcd233c50 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 = 21 (irq11: cbb0 cbb1) kernel: type 12 trap, code=0 Stopped at bpf_mtap+0x1e: cmpl0xc(%edi),%eax db> trace bpf_mtap(c26ad780,0,c03e6d3b,215,100) at bpf_mtap+0x1e ep_if_start(c26fd600,c26ad880,1,0,cd233cb4) at ep_if_start+0x322 ep_intr(c26fd600,c04d7354,c0ecf790,c263c350,c25fbe00) at ep_intr+0xa2 pccard_intr(c26ad880,cd233ce0,c024dbad,c047f200,1) at pccard_intr+0x83 cbb_intr(c25fbe00,0,c03fb487,230,c0ecf790) at cbb_intr+0x1e2 ithread_loop(c0ec6680,cd233d48,c03fb2f9,312,6c65) at ithread_loop+0x182 fork_exit(c0243a10,c0ec6680,cd233d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd233d7c, ebp = 0 --- If I do the same operation when booted up with ACPI enabled, the machine just restarts.. Let me know, if you need more information. /mich -- Best Regards, Michael L. Hostbaek FreeBSD Committer - FreeBSD: The power to serve [EMAIL PROTECTED] - http://www.FreeBSD.org */ PGP-key available upon request /* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
8MB install
Hello, Has anyone had any success installing 5.1 release on a 486 w/ 8MB RAM? I can't install. avail memory = (245760) 0 MB Is this expected behavior? David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
John-Mark Gurney wrote this message on Tue, Jun 24, 2003 at 23:04 -0700: > Ok, I seem to have found out that we are reaping a child that we don't > know about. slightly modified xargs produces this: ok, with some magic ktrace work, I have come up with an more complete answer to the riddle. It's how the shell exec's the processes. The bare cause can be demo'd by: > ( ( echo 2 ; echo 3 ) | ./xargs -I% echo + % ) Say the shell you run the above command is 10. It will fork to create a shell to run the commands in the outter parens. Call this 11. 11's job is to run: (echo 2; echo 3) | ./xargs -I% echo +% 11 will fork/exec and run: echo 2; echo 3 creating process 12. 11 will see that there is no additional commands after ./xargs, and exec (not fork) xargs. Since 12 is stil around and a child of 11, when it exits, 11 will reap 12, and thinking that the first proccess has exited, run the second echo command. Due to scheduling, we'll have two processes running at the same time which can cause the interleaving of data. So, now the question is, do we fix xargs to deal with unexpected children? Or fix the shells in question? (tcsh and zsh seem to suffer this problem) To me, fixing xargs is correct since it prevents another possible future abusers of this "feature". -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
In message: <[EMAIL PROTECTED]> Vincent Poy <[EMAIL PROTECTED]> writes: : On Tue, 24 Jun 2003, M. Warner Losh wrote: : : > In message: <[EMAIL PROTECTED]> : > Vincent Poy <[EMAIL PROTECTED]> writes: : > : Speaking about ACPI, has anyone figured out how to close the lid : > : without suspending? I remember before, when the lid was closed, it would : > : > add the following to your /boot/loader.conf: : > : > hw.acpi.lid_switch_state=NONE : : Putting it in /boot/loader.conf doesn't work since at some port : during the system bootup, it will set the hw.acpi.lid_switch_state: S1 : back to S1. My /boot/loader.conf is as follows: you are right. that's what I get for not double checking on my laptop at home first. : Doing /sbin/sysctl -w hw.acpi.lid_switch_state=NONE in : /etc/rc.local does work which was the way I had it before but without the : ACPI_DSDT patch, all it does when I close the lid is suspend the machine : without the LCD going off and the LCD isn't alive until I reboot the : machine. Same thing happens with hw.acpi.lid_switch_state=S1 even with : the DSDT patch is that when the system resumes, the LCD is not live : either. With the DSDT path and hw.acpi.lid_switch_state=NONE, the LCD : turns off without suspending but when you open the lid, the LCD doesn't : turn on until you hit Fn-F10. This is with the A10 BIOS on the Dell : Inspiron 8200. this matches my experiences, to a point. I've not tried the patched dsdt table on my dell yet. :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
