4.4-R kernel.GENERIC hates mlx cards?
Greetings all, Anyone else tried booting 4.4-R GENERIC with an mlx controller? The machine on which I tried[1] just sits there (numlock works, CTRL+ALT+DEL does nothing) when attempting to mount root. IIRC, it was unhappy even when root was on ad0 -- the mere presence of a DAC960 seems to be a problem. [1]The config is as follows: + Chaintech 6BTA3 m/b + Trident 9660 PCI vid (no flames, please; it was laying around) + Compaq 21143PC NIC + DAC960PDU-1 w/ 3.51-0-04 firmware Yes, I'm using the 2 GB BIOS. I can't even run the boot loader off of my mlx volume if using the 8 GB BIOS. I compiled a custom kernel minus "a lot" of extra drivers, and all is well. No big deal, as I doubt that any RAID-using person would run GENERIC, anyhow... ...but I have no ISA devices in this system. I should think that any potentially dangerous ISA-probing code would not have a chance to stumble on a PCI device. I'll check my m/b BIOS version, and will soon try a mlx 2.73 card on a Biostar M6TLA board. I'm not comfortable filing a PR until I have more info, and rule out my config, but thought that I'd pass on this much info. The system seems perfectly happy once running, but I've not flogged it heavily yet. Eddy --- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: bug or feature: "make world" static linking
> Date: Fri, 5 Oct 2001 18:10:21 -0700 > From: Kris Kennaway <[EMAIL PROTECTED]> [ snip ] > > After investigating with 'ldd', it was pretty obvious that the > > binaries had been _statically_ linked. Easy enough to change > > by adding "-Xlinker -Bdynamic" to CFLAGS. [ snip ] > It shouldn't be doing this unless you tell it to. What other local > settings have you changed? Although I had messed with CFLAGS settings in '/usr/share/mk/': 1. I think that I changed all back, and didn't change anything that looked like linker food; 2. I "maked" again after reinstalling the "source" distribution. It's conceivable that I goofed (minimal sleep when I did this), but I'm 98% certain that I had a clean environment. If nobody else can confirm or deny my observations, I'll run a clean install and 'make world' to address the 2%. Eddy --- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
panic in 4.4-stable (10/01 snap); help needed
Hi,
A couple of my machines have panic'd (rather randomly it seems)
but on one of them, I was able to get a dump. The stack trace
is included below, if anyone can help, it'd be greatly
appreciated (on the machine below, there were no nfs mount points).
thanks
-mohan
gdb -k kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
...
...
SMP 2 cpus
IdlePTD 3420160
initial pcb at 2b5600
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x1e
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01adac6
stack pointer = 0x10:0xfbaa1d48
frame pointer = 0x10:0xfbaa1df0
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 = 215 (squid)
interrupt mask = <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... 8
done
Uptime: 2d13h20m32s
dumping to dev #ad/0x20001, offset 8126464
dump ata0: resetting devices .. done
...
...
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
#1 0xc0152a9f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:313
#2 0xc0152ea0 in poweroff_wait (junk=0xc0289e59, howto=-1071081169) at
/usr/src/sys/kern/kern_shutdown.c:581
#3 0xc024f8ac in trap_fatal (frame=0xfbaa1d08, eva=30) at
/usr/src/sys/i386/i386/trap.c:956
#4 0xc024f53d in trap_pfault (frame=0xfbaa1d08, usermode=0, eva=30) at
/usr/src/sys/i386/i386/trap.c:849
#5 0xc024f0db in trap (frame={tf_fs = -754974696, tf_es = -72744944, tf_ds =
-72744944, tf_edi = -66031872, tf_esi = 0,
tf_ebp = -72737296, tf_isp = -72737484, tf_ebx = 10, tf_edx = 5, tf_ecx =
-72737244, tf_eax = 10, tf_trapno = 12,
tf_err = 0, tf_eip = -1071981882, tf_cs = 8, tf_eflags = 66054, tf_esp =
-752278720, tf_ss = -66031872})
at /usr/src/sys/i386/i386/trap.c:448
#6 0xc01adac6 in nqsrv_getlease (vp=0xfc106f00, duration=0xfbaa1e1c, flags=5,
slp=0x, procp=0xf1884c20, nam=0x0,
cachablep=0xfbaa1e20, frev=0xfbaa1e24, cred=0xd2ad8800) at
/usr/src/sys/nfs/nfs_nqlease.c:228
#7 0xc01ade3c in nqnfs_vop_lease_check (ap=0xfbaa1e64) at
/usr/src/sys/nfs/nfs_nqlease.c:366
#8 0xc017d48d in vop_defaultop (ap=0xfbaa1e64) at /usr/src/sys/kern/vfs_default.c:150
#9 0xc0209971 in ufs_vnoperate (ap=0xfbaa1e64) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:2382
#10 0xc0187423 in vn_read (fp=0xd3292340, uio=0xfbaa1ed4, cred=0xd2ad8800, flags=0,
p=0xf1884c20) at vnode_if.h:392
#11 0xc016123c in dofileread (p=0xf1884c20, fp=0xd3292340, fd=727, buf=0x10715000,
nbyte=4096, offset=-1, flags=0)
at /usr/src/sys/sys/file.h:146
#12 0xc0161102 in read (p=0xf1884c20, uap=0xfbaa1f80) at
/usr/src/sys/kern/sys_generic.c:117
#13 0xc024fbd5 in syscall2 (frame={tf_fs = -1078001617, tf_es = 47, tf_ds =
-1078001617, tf_edi = 727, tf_esi = 0,
tf_ebp = -1078199848, tf_isp = -72736812, tf_ebx = 1709052004, tf_edx =
306994816, tf_ecx = 1709044064, tf_eax = 3,
tf_trapno = 532520, tf_err = 2, tf_eip = 1708770552, tf_cs = 31, tf_eflags =
643, tf_esp = -1078199892, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1155
#14 0xc023d8ab in Xint0x80_syscall ()
cannot read proc at 0
(kgdb) frame 6
#6 0xc01adac6 in nqsrv_getlease (vp=0xfc106f00, duration=0xfbaa1e1c, flags=5,
slp=0x, procp=0xf1884c20, nam=0x0,
cachablep=0xfbaa1e20, frev=0xfbaa1e24, cred=0xd2ad8800) at
/usr/src/sys/nfs/nfs_nqlease.c:228
228 if (lp != 0) {
(kgdb) print lp
$33 = (struct nqlease *) 0x4000
(kgdb)
## $Id$
machine i386
cpu I686_CPU
ident CDS
maxusers192
options NMBCLUSTERS=65534
options MAXDSIZ="(1500*1024*1024)"
options MAXSSIZ="(512*1024*1024)"
options DFLDSIZ="(1500*1024*1024)"
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options INET#InterNETworking
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
options MD_ROOT #MD is a potential root device
options NFS #Network Filesystem
options NFS_ROOT#NFS usable as root device, NFS required
options MSDOSFS #MSDOS Filesystem
options CD9660 #ISO 9660 Filesystem
options CD9660_ROOT #CD-ROM usable as root, CD9660 required
options PROCFS #Process filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options SCSI_D
Re: bug or feature: "make world" static linking
On Fri, Oct 05, 2001 at 08:44:34PM +, E.B. Dreger wrote: > Greetings all, > > While playing around with 4.4-R, I finally did my first 'make > world'. Even after running 'strip' on the resultant binaries, I > was puzzled by their large sizes compared to -RELEASE. > > After investigating with 'ldd', it was pretty obvious that the > binaries had been _statically_ linked. Easy enough to change > by adding "-Xlinker -Bdynamic" to CFLAGS. > > However: > > Static linking for /bin and /sbin is obviously the sane choice, > but I'd prefer dynamic linking for anything in /usr. Bug, > feature, or just me cutting my teeth? It shouldn't be doing this unless you tell it to. What other local settings have you changed? Kris PGP signature
Re: Why sshd:PermitRootLogin = no ?
: :[EMAIL PROTECTED] wrote: :>I'm afraid I don't understand your point. If without-password :>makes sshd useful to a larger subsection of users without effecting :>security on the original subsection, why wouldn't you want to make :>the change? Just because it may not make a difference for YOU doesn't :>mean that it wouldn't be a useful change to make. : :But it *can't* make it useful to any more users. How do you get the :authorized-hosts file updated? You edit it. How do you get the :configuration changed to without-password from none? You edit it. : :Same work, no obvious advantage to without-password over no, and better :obvservance of "install in the most secure way possible". Just like :the discard port is disabled in inetd.conf -- same concept. : :-- :Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" I see. And at what point does editing N files make it 'easier'? 4? 5? If we were to cut the number of files you had to edit to get X to work from 5 to 3 would that be worthwhile enough to do a commit? What exactly are you arguing here? Because I don't see it. Frankly I think being able to go from 2 files to 1 to get something done, like creating an authorized_keys file for root, is well worth the commit if there are otherwise no downsides. I don't see any downsides to doing this except for a few people who seem to be arguing that status-quo is better then fixing something even if fixing that something has absolutely no effect on them. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
HP OmniBook XE3
Hello - I was wondering if anyone has gotten FreeBSD 4.4-STABLE working on an HP OmniBook XE3. I like the machine due to the built in Ethernet port, and the only real problems I've run into is getting X to run. Any help is GREATLY appreciated!! -#0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why sshd:PermitRootLogin = no ?
[EMAIL PROTECTED] wrote: >I'm afraid I don't understand your point. If without-password >makes sshd useful to a larger subsection of users without effecting >security on the original subsection, why wouldn't you want to make >the change? Just because it may not make a difference for YOU doesn't >mean that it wouldn't be a useful change to make. But it *can't* make it useful to any more users. How do you get the authorized-hosts file updated? You edit it. How do you get the configuration changed to without-password from none? You edit it. Same work, no obvious advantage to without-password over no, and better obvservance of "install in the most secure way possible". Just like the discard port is disabled in inetd.conf -- same concept. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why sshd:PermitRootLogin = no ?
: :matt. : :i think your missing the point of my comment. : :i never said it would increase or decrease the security of the :superuser account. nor did i say it was detrimental to the :person installing it. : :what i am saying is that i dont see any real point in making :the change. if you want it enabled. do so after the installation. : :jamie. I'm afraid I don't understand your point. If without-password makes sshd useful to a larger subsection of users without effecting security on the original subsection, why wouldn't you want to make the change? Just because it may not make a difference for YOU doesn't mean that it wouldn't be a useful change to make. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Sound Problem on laptop
hello, Earlier I sent a mail to this ML to report a problem with PCM device: when my kernel is compiled with it i got this msg at boot: pcm0: irq 9 at device 7.5 on pci0 pcm0: cannot allocate bus resource.device_probe_and_attach: pcm0 attach returned 6 i've been told that i have to disable PNP in my bios, but i cannot change much things in it (only boot order and the time), it's a laptop bios ... i'm on a Compaq laptop, serie 1200 model 12XL408 thanks in advance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why sshd:PermitRootLogin = no ?
matt. i think your missing the point of my comment. i never said it would increase or decrease the security of the superuser account. nor did i say it was detrimental to the person installing it. what i am saying is that i dont see any real point in making the change. if you want it enabled. do so after the installation. jamie. On Fri, Oct 05, 2001 at 01:58:28PM -0700, Matt Dillon wrote: > > : > :why? > : > :from what i can tell you want the default entry changed to accomodate > :your personal installation method? > : > :i dont see a problem with PermitRootLogin no at all. its standard. > :if you want to use keys for root then change it after the installation. > : > :again. maybe im missing the point. but i dont see what your average user > :is going to gain from making a change like this. > : > :jamie. > > Huh? > > Tell me, Jamie, what effect does changing PermitRootLogin from no to > without-password have on a default installation? And why would be > detrimental to the 'average' user or reduce root security? Think about > it a bit before shoot from the hip. > > -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
