Panic in -current
Latest (this night) current, no system activity: panic: mutex Giant owned at ../../kern/kern_intr.c:238 I can sen you kernel conf if needed. Is this known or should I invest some time to debug it? Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
Nicolas Souchu [EMAIL PROTECTED] writes: What are kernel mutex? A new mechanism for spl replacement? Is it introduced with the new SMP? I found nothing in the mail archives... You mean you don't read -committers, -developers and -arch? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
On Mon, 27 Nov 2000, Alfred Perlstein wrote: * The Hermit Hacker [EMAIL PROTECTED] [001127 18:12] wrote: Morning all ... Every since the SMPng code went into -current way back when, I've been experiencing hangs ... and am not quite sure how to debug this. I'm in X all the time, so breaking to the debugger to see where its hanging isn't possible ... Some kernels its relatively easy to trigger, some kernels are harder to trigger, but they all do at some point in time ... Can someone suggestion a method of being able to debug this? Serial console, add BREAK_TO_DEBUGGER (sp?) to your kernel config and hook your laptop up to it. actually, got everything compiled nicely, rebooted and figured I'd pound the system the best way I know how: while(1) make -j16 world end system hung solid ... ctl-alt-esc won't even get me to DDB ... this kernel seems to do it faster then the previous one ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
On Mon, 27 Nov 2000, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [001127 21:56] wrote: * The Hermit Hacker [EMAIL PROTECTED] [001127 18:12] wrote: Morning all ... Every since the SMPng code went into -current way back when, I've been experiencing hangs ... and am not quite sure how to debug this. I'm in X all the time, so breaking to the debugger to see where its hanging isn't possible ... Some kernels its relatively easy to trigger, some kernels are harder to trigger, but they all do at some point in time ... Can someone suggestion a method of being able to debug this? Serial console, add BREAK_TO_DEBUGGER (sp?) to your kernel config and hook your laptop up to it. Marc, I noticed you tried the BREAK_TO_DEBUGGER and whatnot already, perhaps letting us know what hardware you have in your smp box might help some, I'm running SMP and doing buildworlds and kernel compiles without a problem. I'm not however, running X nor doing any desktop work on it. I think I also figured out what makes the box so damn sluggish when doing lots of IO *bops dillon* :) well, here's a current dmesg .. any more detail then that needed? Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Nov 26 18:22:52 AST 2000 [EMAIL PROTECTED]:/usr/local/mp3/obj/usr/local/base/src/sys/kernel Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (467.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268435456 (262144K bytes) avail memory = 258248704 (252196K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0309000. Preloaded elf module "random.ko" at 0xc030909c. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia GeForce 256 graphics accelerator at 0.0 irq 16 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 11 Timecounter "PIIX" frequency 3579545 Hz pci0: Intel 82371AB Power management controller at 7.3 ahc0: Adaptec 2910/15/20/30C SCSI adapter port 0xc400-0xc4ff mem 0xef00-0xef000fff irq 19 at device 9.0 on pci0 aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs vx0: 3COM 3C590 Etherlink III PCI port 0xc800-0xc81f irq 18 at device 11.0 on pci0 utp[*utp*]: disable 'auto select' with DOS util! address 00:20:af:f7:8f:d2 Warning! Defective early revision adapter! ahc1: Adaptec 2940 Ultra SCSI adapter port 0xcc00-0xccff mem 0xef001000-0xef001fff irq 17 at device 13.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: unknown card (vendor=0x1274, dev=0x5000) at 17.0 irq 19 atapci1: HighPoint HPT366 ATA66 controller port 0xdc00-0xdcff,0xd800-0xd803,0xd400-0xd407 irq 18 at device 19.0 on pci0 ata2: at 0xd400 on atapci1 atapci2: HighPoint HPT366 ATA66 controller port 0xe800-0xe8ff,0xe400-0xe403,0xe000-0xe007 irq 18 at device 19.1 on pci0 ata3: at 0xe000 on atapci2 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0501 can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acd0: CDROM CD-ROM 32X/AKU at ata0-master using PIO4 Waiting 15 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 4 lun 0 sa0: DEC DLT2700 851A Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) da0 at ahc1 bus 0 target
Re: status of http://www.freebsd.org/handbook/makeworld.html
On Mon, Nov 27, 2000 at 08:28:57PM -0500, Garance A Drosihn wrote: Unless I'm missing something, which is certainly possible, it seems to me that http://www.freebsd.org/handbook/makeworld.html is missing some information that it used to have. Send patches. When I wrote that section I was running "make world" once or twice a day. I don't generally do that anymore. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3dfx.ko
The standard way of loading a particular module at boot from /boot/loader.conf is 'modulename_load="YES"', right? This doesn't seem to be possible with the 3dfx module, however... Since it's name starts with a number, it causes a syntax error. Being FORTH-impaired, I have no idea how to work around this... Anybody know how to make this work? Also, it doesn't seem to be possible to compile 'device tdfx' statically into the kernel either, since it depends on symbols that only exist in the kernel when compat_linux is defined, and COMPAT_LINUX is no longer an option, is it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for current on LCA based alphas
On Mon, Nov 27, 2000 at 02:42:52PM -0600, Mike Eldridge wrote: On Sat, 25 Nov 2000, Bernd Walter wrote: LCA systems doesn't like probing after PCI slot 19. Probing slot 20 panics the system. The following patch made it into single user mode on my AXPpci33. I asume it will also work on multias. I can't tell more as the tested system is a 4.1-RELEASE and I need to update the world before further testing. Hmm, what exactly happens when slot 20 is probed? I remember my problems with my Multia were related to PCI interrupts. It would spit out "dec_axppci_33_intr_map: bad interrupt pin 192" about 50 or so times and then panic. Wasn't this somehow related to the version of the SRM console code? -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -current kernel hangs machine solid ...
On 28-Nov-00 The Hermit Hacker wrote: Just tried to build a kernel based on sources from today, to enable BREAK_TO_DEBUGGER so that I can try and get in and see where its hanging ... the compile hung the machine solid. Even hitting the 'numlock'/'capslock' on my keyboard generated no results ... It is spinning with interrupts disabled, probably due to holding a spinlock for far too long. Debugging this is not all that fun. :-P If you can rig up an NMI switch, you can use that to drop into ddb and then use 'x' to see who owns various mutexes (sched_lock and callout_mtx being the primary spin mutexes of concern). If you compile your kernel with WITNESS and MUTEX_DEBUG, then you can use 'x' to look at the sched_lock and callout_mtx mutex structures, find the pointer to the mtx_debug structure, and examine that to find the mtxd_file and mtxd_line members. Then you can look at those (x/s to look at the filename as a string) to find the filename and line number when the mutex was last acquired. Grr, except that this is broken for spin mutexes. If you are patient, you can try rigging up a serial console, compile KTR into your kernel as so: options KTR options KTR_EXTEND options KTR_COMPILE=(KTR_LOCK|KTR_PROC|KTR_INTR) Then when the machine has booted, log in via ssh or a tty other than the serial console and type the following: # sysctl -w debug.ktr_mask=0x1208 # sysctl -w debug.ktr_verbose=2 # while (1) do make -j 16 buildworld end Unfortunately, there is a chance the machine will die before it hangs due to exceeding the stack space. In that case, you can _try_ bumping UPAGES, but that didn't help on my test machines. :-/ However, if your machine doesn't blow up and die, then when it hangs, the KTR output dumped to the serial console (which you should probably log to a file via script or somesuch) will show what mutex was acquired and where it was acquired that is causing the hang. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for current on LCA based alphas
On Tue, 28 Nov 2000, Wilko Bulte wrote: On Mon, Nov 27, 2000 at 02:42:52PM -0600, Mike Eldridge wrote: On Sat, 25 Nov 2000, Bernd Walter wrote: LCA systems doesn't like probing after PCI slot 19. Probing slot 20 panics the system. The following patch made it into single user mode on my AXPpci33. I asume it will also work on multias. I can't tell more as the tested system is a 4.1-RELEASE and I need to update the world before further testing. Hmm, what exactly happens when slot 20 is probed? I remember my problems with my Multia were related to PCI interrupts. It would spit out "dec_axppci_33_intr_map: bad interrupt pin 192" about 50 or so times and then panic. Wasn't this somehow related to the version of the SRM console code? Well, 4.0 didn't panic. That brings me to another point, for some reason, when I attempted to upgrade the SRM, it appeared as if it wrote the firmmware successfully, there were no errors, it went through the process, *but* when I checked the version of SRM, it was still the same. I really haven't messed with it at all lately because I'm waiting for a proper serial cable so that I can plug the Multia's serial port up to one of my linux boxen. D25M to D9M, quite possibly the most difficult cable to assemble. I had 2 dozen various 9-25 pin adapters, and I couldn't combine any of them with a D9M-D9F cable in any way to come out with a D25M-D9M cable. I've only seen this particular problem with 4.1.1 (I don't think I've tried 4.1 yet, although I can't remember for sure). Mike - Save the whales. Feed the hungry. Free the mallocs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic in -current
On 28-Nov-00 Andrea Campi wrote:
Latest (this night) current, no system activity:
panic: mutex Giant owned at ../../kern/kern_intr.c:238
I can sen you kernel conf if needed.
Is this known or should I invest some time to debug it?
Eek! I haven't seen this. If you can reproduce this, stick DDB, WITNESS, and
MUTEX_DEBUG in your kernel. Then when you get to the ddb prompt, do a
'x __mtx_debug_Giant' followed by 'x/x,8 __mtx_debug_Giant' (to work around
weird bugs in ddb). The last commad is a dump of Giant's mtx_debug structure:
struct mtx_debug {
struct witness *mtxd_witness;
LIST_ENTRY(mtx) mtxd_held;
const char *mtxd_file;
int mtxd_line;
const char *mtxd_description;
};
We want mtxd_file and mtxd_line. If you look at the output of the last
command, it will probably look something like this:
db x/x,8 __mtx_debug_Giant
__mtx_debug_Giant: c03303d80 cb6475ac c02fdd2a
__mtx_debug_Giant+0x10: da c02f97ad0 0
The last number of the first line is the address of the string holding the
filename:
db x/s 0xc02fdd2a
__set_sysinit_set_sym...: ../../i386/isa/ithread.c
The first number on the second line is the line number:
db x/d __mtx_debug_Giant+0x10
__mtx_debug_Giant+0x10: 218
So in this case Giant was last acquired at line 218 of ../../i386/isa/ithread.c.
Finding out where Giant was last obtained will help with finding out where it
was supposed to be dropped but wasn't.
Bye,
Andrea
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: -current kernel hangs machine solid ...
gah ... okay, first "problem" is coming up with a serial console, as I
only have the one machine ... but, am going to search one out and save
this email ... will come back to it once I get it setup that far ...
thanks ...
On Tue, 28 Nov 2000, John Baldwin wrote:
On 28-Nov-00 The Hermit Hacker wrote:
Just tried to build a kernel based on sources from today, to enable
BREAK_TO_DEBUGGER so that I can try and get in and see where its hanging
... the compile hung the machine solid. Even hitting the
'numlock'/'capslock' on my keyboard generated no results ...
It is spinning with interrupts disabled, probably due to holding a spinlock for
far too long. Debugging this is not all that fun. :-P If you can rig up an
NMI switch, you can use that to drop into ddb and then use 'x' to see who owns
various mutexes (sched_lock and callout_mtx being the primary spin mutexes of
concern). If you compile your kernel with WITNESS and MUTEX_DEBUG, then you
can use 'x' to look at the sched_lock and callout_mtx mutex structures, find
the pointer to the mtx_debug structure, and examine that to find the mtxd_file
and mtxd_line members. Then you can look at those (x/s to look at the filename
as a string) to find the filename and line number when the mutex was last
acquired. Grr, except that this is broken for spin mutexes. If you are
patient, you can try rigging up a serial console, compile KTR into your kernel
as so:
options KTR
options KTR_EXTEND
options KTR_COMPILE=(KTR_LOCK|KTR_PROC|KTR_INTR)
Then when the machine has booted, log in via ssh or a tty other than the serial
console and type the following:
# sysctl -w debug.ktr_mask=0x1208
# sysctl -w debug.ktr_verbose=2
# while (1) do
make -j 16 buildworld
end
Unfortunately, there is a chance the machine will die before it hangs due to
exceeding the stack space. In that case, you can _try_ bumping UPAGES, but
that didn't help on my test machines. :-/ However, if your machine doesn't
blow up and die, then when it hangs, the KTR output dumped to the serial console
(which you should probably log to a file via script or somesuch) will show what
mutex was acquired and where it was acquired that is causing the hang.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
In message [EMAIL PROTECTED] Christian Carstensen writes: : sound output results in "pcm0: play interrupt timeout, channel dead". : when inserting a pccard, the card is not being recognized, pccardd tends : to call it something like "Null, Null". You must change the default pccardd memory address from 0xd to 0xd8000. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
On Tue, 28 Nov 2000 12:17:14 -0400 (AST), The Hermit Hacker [EMAIL PROTECTED] said: this kernel seems to do it faster then the previous one ... That's been my observation over the past 24 hours too. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] Where ignorance is our master, there is no possibility of real peace. -- the Dalai Lama To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wall/rwall cleanups
In message [EMAIL PROTECTED] Kris Kennaway writes: : Please review. This syncs up our code with some NetBSD changes, as well : as attempting to sync rwall up with wall. You might also want to bruing in the openBSD changes for wall -g. Plus a few nits: + char *tty, hostname[MAXHOSTNAMELEN], lbuf[256], tmpname[64]; tmpname should be tmpname[MAXPATHLEN] since it is a path. Note well, not MAXPATHLEN + 1 since MAXPATHLEN is defined to include the trailing NUL (I have patches in my tree that fix this for the rest of the tree, at least the +1 issue, other issues will have to wait until I can audit all strings passed to open, mktemp, et al). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx.ko
"Donald J . Maddox" wrote: Also, it doesn't seem to be possible to compile 'device tdfx' statically into the kernel either, since it depends on symbols that only exist in the kernel when compat_linux is defined, and COMPAT_LINUX is no longer an option, is it? COMPAT_LINUX is still supported. It's broken on the Alpha though. If it's broken on i386 as well, let me know. I'm not aware of any brokeness at this time. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
well, John just gave a good break down on what needs to be done to debug
it ... do you have easy access to a serial console? I'm trying to
scrounge up hardware at this end to do it with, but its difficult :)
On 28 Nov 2000, Michael Harnois wrote:
On Tue, 28 Nov 2000 12:17:14 -0400 (AST), The Hermit Hacker [EMAIL PROTECTED] said:
this kernel seems to do it faster then the previous one ...
That's been my observation over the past 24 hours too.
--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
[EMAIL PROTECTED] [EMAIL PROTECTED]
Where ignorance is our master, there is
no possibility of real peace. -- the Dalai Lama
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
On Tue, 28 Nov 2000 19:34:03 -0400 (AST), The Hermit Hacker [EMAIL PROTECTED] said: well, John just gave a good break down on what needs to be done to debug it ... do you have easy access to a serial console? I'm trying to scrounge up hardware at this end to do it with, but its difficult :) no, i don't ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] Where ignorance is our master, there is no possibility of real peace. -- the Dalai Lama To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx.ko
I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... On Tue, Nov 28, 2000 at 06:22:33PM -0500, Marcel Moolenaar wrote: "Donald J . Maddox" wrote: Also, it doesn't seem to be possible to compile 'device tdfx' statically into the kernel either, since it depends on symbols that only exist in the kernel when compat_linux is defined, and COMPAT_LINUX is no longer an option, is it? COMPAT_LINUX is still supported. It's broken on the Alpha though. If it's broken on i386 as well, let me know. I'm not aware of any brokeness at this time. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx.ko
"Donald J . Maddox" wrote: I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... It's not a deprecated option. I'm not aware of config ever emitting a warning for it. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
no sweat I'll try and hijack a laptop from work tomorrow for a couple
of days, or wait for hte boss to get back from her trip and hijack hers
... if nothing for tomorrow, early next week instead ...
On 28 Nov 2000, Michael Harnois wrote:
On Tue, 28 Nov 2000 19:34:03 -0400 (AST), The Hermit Hacker [EMAIL PROTECTED] said:
well, John just gave a good break down on what needs to be done
to debug it ... do you have easy access to a serial console? I'm
trying to scrounge up hardware at this end to do it with, but
its difficult :)
no, i don't ...
--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
[EMAIL PROTECTED] [EMAIL PROTECTED]
Where ignorance is our master, there is
no possibility of real peace. -- the Dalai Lama
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On 28-Nov-00 Dag-Erling Smorgrav wrote: Nicolas Souchu [EMAIL PROTECTED] writes: What are kernel mutex? A new mechanism for spl replacement? Is it introduced with the new SMP? I found nothing in the mail archives... You mean you don't read -committers, -developers and -arch? Even if he did it's fairly easy to not read a mail that is important. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to debug ppp
Well, I haven't seen this before !!! Your ISP is *insisting* that you negotiate a multi-link connection. You can do this by simply adding set mrru 1506 to your config. I sometimes have trouble connecting to my flat-rate isp via i4bsd. Most of the time it works, but sometimes the handshake fails. What is the log trying to tell me here? What can I tell my isp? When it fails, I can connect to another isp, which charges per minute charges, which I rather not use when I have flat rate. Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: Phone: x Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: Connected! Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: opening - dial Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: 1: Dial attempt 1 of 2 Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: dial - carrier Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: /dev/i4brbch0: CD detected Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: carrier - login Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: login - lcp Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: FSM: Using "1" as a transport Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Initial -- Closed Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: Entering STOPPED state for 2 s econds Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Closed -- Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x0bde8bbc Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: LayerStart Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Stopped -- Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(2) state = Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(2) state = Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Looping: Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(3) state = Req-Sent Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(3) state = Req-Sent Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Until hangup Leif -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Other Linux stuff...
Huh... I was sure it did... Oh, well, guess my memory ain't what it used to be :-/ But... Since you are the Linux Guru, and it seems I momentarily have your attention, let me ask you about another Linux emulation matter. :) The Linux 'ldd' program is, as I'm sure you know, just a shell script that tries to directly execute 'ld-linux.so.2' on the filename passed in argv to the script. This doesn't work with our Linux emulation. Apparently, ld-linux.so.2 is simply (and not too surprisingly) not recognized as an executable file. While I'm surprised that this works on Linux, shouldn't our emulator emulate this behavior too? On Tue, Nov 28, 2000 at 07:03:38PM -0500, Marcel Moolenaar wrote: "Donald J . Maddox" wrote: I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... It's not a deprecated option. I'm not aware of config ever emitting a warning for it. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing interrupts (was Re: CURRENT is freezing again ...)
On Mon, 27 Nov 2000, Andrew Gallatin wrote: Bruce Evans writes: Possible causes of the problem: 1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but actually sends non-specific ones (0x20 | garbage). Since interrupts I think that sending non-specific EOIs is the problem. Sending specific EOIs seem to eliminate my nic timeouts and the need to manually feed an eoi to recover from a missing interrupt. My question is: how does one send a specific EOI correctly? I don't have decent documentation for this. Above, you seem to imply that 0x30 is a specific EOI. That does not seem to work for me (machine locks at boot). Linux uses 0xe0. According to some Tru64 docs I have, that means "Rotate Priority on specific EOI". According to that same documentation, 0x60 is a specific EOI. Both of these Oops, I misread the data sheet. 0x60 is correct, 0x30 is wrong. The irq number is in the lowest 3 bits. appear to work just fine. What should the alpha port use? I think it should use non-specific EOIs and send them early (when there is no ambiguity about which interrupt is being handled), as in the i386 port. Sending them late mainly gives the ICU's braindamaged interrupt priority scheme for longer than necessary. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
"Donald J . Maddox" wrote: The Linux 'ldd' program is, as I'm sure you know, just a shell script that tries to directly execute 'ld-linux.so.2' on the filename passed in argv to the script. This doesn't work with our Linux emulation. Apparently, ld-linux.so.2 is simply (and not too surprisingly) not recognized as an executable file. While I'm surprised that this works on Linux, shouldn't our emulator emulate this behavior too? It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would propagate the bug to FreeBSD at large. I don't think we should do that. I did make patches once. They're probably outdated, but there's a change they apply: http://people.FreeBSD.org/~marcel/elf-2.2.8.diff http://people.FreeBSD.org/~marcel/elf-stable.diff http://people.FreeBSD.org/~marcel/elf-current.diff WARNING: -stable probably represents 3.x (which makes -current represent 4.x) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would Could you elaborate on this, please. I am interested in what is meant with execution of shared objects (as opposed to programs). Why is this wrong? Thanks, Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
[EMAIL PROTECTED] wrote: It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would Could you elaborate on this, please. I am interested in what is meant with execution of shared objects (as opposed to programs). Why is this wrong? Because the ELF file doesn't have the right attribute and therefore may not have all the necessary information to execute it properly (such as start address). In principle a shared object will have the same structure as an executable in that both are loadable. So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: on FreeBSD: gauss% ./libc.so.4 ./libc.so.4: Permission denied. on HP-UX (why not, it's accessable): barra:marcel_as% ./libc.2 ./libc.2: Exec format error. Binary file not executable. on Linux: [marcel@hpcll510 /lib]$ ./libc.so.6 GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14-1.5.0 system on 2000-02-29. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Report bugs using the `glibcbug' script to [EMAIL PROTECTED]. And for a different library (still on Linux): [marcel@hpcll510 /lib]$ ./libutil.so.1 Abort -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx.ko
"Donald J . Maddox" wrote: The standard way of loading a particular module at boot from /boot/loader.conf is 'modulename_load="YES"', right? This doesn't seem to be possible with the 3dfx module, however... Since it's name starts with a number, it causes a syntax error. Ugh. Evil stuff. Are environment variables starting with digits allowed in sh(1)? If so, I'll extend loader's syntax. Otherwise, see below. Anybody know how to make this work? Use two variables to control this. For instance: threedfx_load="YES" threedfx_name="3dfx" The way loader is set up, you put the _name line in /boot/defaults/loader.conf, so that the user only needs to put the threedfx_load="YES" line in his config. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
atomic.h problem with compiling the kernel
For quite a while I couldn't get into the CVS server to update /usr/src.
I finnaly did and /usr/src compiled ok but the kernel is giving me
a problem with some asm macros in atomic.h and they aren't trivial
macros.
I was wondering if you knew what the problem was or who could
help set me straight.
-piet
--
~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^`
, ,
/( )`
\ \__ / |
/- _ `-/ ' Pete Delaney
(/\/ \ \ /\Network/Kernel Hacker
/ / | `\ Rocky Mountain UNIX
O O ) |
`-^--'` ' 2812 Toledo Ave.
(_.) _ )/Santa Clara Ca. 95051-4734
`.___/`/ USA
`-' /
---. __ / __ \
---|O)))==) \) /=
---'`--' `.__,' \
| |E-mail: [EMAIL PROTECTED]
\ / [EMAIL PROTECTED]
( (_ / \URL : www.piet.net
,' ,' | \ Voice : +1 (408) 243-8872
`--{__) \/ ISDN : +1 (408) 244-8290 / 244-2614
~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^`
"Every one that is of the truth heareth my voice" - J.C.Superstar
~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^``~*-,._.,-*~``^`
/*-
* Copyright (c) 1998 Doug Rabson
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD: src/sys/i386/include/atomic.h,v 1.16 2000/10/28 00:28:15 jhb Exp $
*/
#ifndef _MACHINE_ATOMIC_H_
#define _MACHINE_ATOMIC_H_
/*
* Various simple arithmetic on memory which is atomic in the presence
* of interrupts and multiple processors.
*
* atomic_set_char(P, V)(*(u_char*)(P) |= (V))
* atomic_clear_char(P, V) (*(u_char*)(P) = ~(V))
* atomic_add_char(P, V)(*(u_char*)(P) += (V))
* atomic_subtract_char(P, V) (*(u_char*)(P) -= (V))
*
* atomic_set_short(P, V) (*(u_short*)(P) |= (V))
* atomic_clear_short(P, V) (*(u_short*)(P) = ~(V))
* atomic_add_short(P, V) (*(u_short*)(P) += (V))
* atomic_subtract_short(P, V) (*(u_short*)(P) -= (V))
*
* atomic_set_int(P, V) (*(u_int*)(P) |= (V))
* atomic_clear_int(P, V) (*(u_int*)(P) = ~(V))
* atomic_add_int(P, V) (*(u_int*)(P) += (V))
* atomic_subtract_int(P, V)(*(u_int*)(P) -= (V))
* atomic_readandclear_int(P) (return *(u_int*)P; *(u_int*)P = 0;)
*
* atomic_set_long(P, V)(*(u_long*)(P) |= (V))
* atomic_clear_long(P, V) (*(u_long*)(P) = ~(V))
* atomic_add_long(P, V)(*(u_long*)(P) += (V))
* atomic_subtract_long(P, V) (*(u_long*)(P) -= (V))
*
Re: How to debug ppp
On Wed, 29 Nov 2000, Brian Somers wrote: Well, I haven't seen this before !!! Your ISP is *insisting* that you negotiate a multi-link connection. You can do this by simply adding set mrru 1506 to your config. Strange, since my subscription is single channel flat rate isdn... I'll try it. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system hangs ... not sure how to debug ...
On 28 Nov 2000, Michael Harnois wrote: On Tue, 28 Nov 2000 19:34:03 -0400 (AST), The Hermit Hacker [EMAIL PROTECTED] said: well, John just gave a good break down on what needs to be done to debug it ... do you have easy access to a serial console? I'm trying to scrounge up hardware at this end to do it with, but its difficult :) no, i don't ... I've got a couple. I'm at 55.67689N, 12.56869E. Just adjust the transporter beam, Scotty :-) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic.h problem with compiling the kernel
For quite a while I couldn't get into the CVS server to update /usr/src. I finnaly did and /usr/src compiled ok but the kernel is giving me a problem with some asm macros in atomic.h and they aren't trivial macros. I was wondering if you knew what the problem was or who could help set me straight. Include the error message, and we may be able to help. Please also dont 1) Send our own files back to us, we know what/where they are. 2) Use such a _huge_ signature. 5 lines is usually considered the maximum size. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FFS Snapshot issues
Howdy,
Get the attached panic repeatedly when doing an rm -rf /usr/ports and trying
to create a snapshot of the root partition. Sometimes I get the panic when
there's no apparent disk activity and trying to create a snapshot on 2GB
filesystems. I've included gdb output, dmesg and my kernel config.
Hopefully, some-one can make more sense of it in a shorter timeframe than
me. If any further information is required, please let me know and I'll try
my best to get it to you.
BTW, is there any reason I had to enter panic twice in ddb to get the sucker
to dump core?
Regards,
Chris Knight
Systems Administrator
AIMS Independent Computer Professionals
Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795
Web: http://www.aims.com.au
ait0fd02# gdb -k kernel.0 vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 3362816
initial pcb at 2a7fe0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0170fd8
stack pointer = 0x10:0xc3b38f14
frame pointer = 0x10:0xc3b38f24
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 5 (syncer)
panic: from debugger
panic: from debugger
Uptime: 6m21s
dumping to dev #ad/0x20001, offset 344064
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) back
#0 dumpsys () at ../../kern/kern_shutdown.c:477
#1 0xc0175247 in boot (howto=260) at ../../kern/kern_shutdown.c:320
#2 0xc0175685 in panic (fmt=0xc022d5d4 "from debugger")
at ../../kern/kern_shutdown.c:568
#3 0xc011c2b5 in db_panic (addr=-1072230440, have_addr=0, count=-1,
modif=0xc3b38d88 "") at ../../ddb/db_command.c:433
#4 0xc011c255 in db_command (last_cmdp=0xc025be40, cmd_table=0xc025bca0,
aux_cmd_tablep=0xc029f92c) at ../../ddb/db_command.c:333
#5 0xc011c31a in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc011e4c3 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#7 0xc02088d2 in kdb_trap (type=12, code=0, regs=0xc3b38ed4)
at ../../i386/i386/db_interface.c:163
#8 0xc0214d54 in trap_fatal (frame=0xc3b38ed4, eva=0)
at ../../i386/i386/trap.c:936
#9 0xc0214add in trap_pfault (frame=0xc3b38ed4, usermode=0, eva=0)
at ../../i386/i386/trap.c:855
#10 0xc0214557 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = -1070810528, tf_ebp = -1011642588, tf_isp = -1011642624,
tf_ebx = 0, tf_edx = 1, tf_ecx = -1064877056, tf_eax = 8,
tf_trapno = 12, tf_err = 0, tf_eip = -1072230440, tf_cs = 8,
tf_eflags = 65670, tf_esp = -1070810528, tf_ss = 8})
at ../../i386/i386/trap.c:438
#11 0xc0170fd8 in mtx_exit_hard (m=0xc02cba60, type=0)
at ../../kern/kern_mutex.c:402
---Type return to continue, or q return to quit---
#12 0xc01a9cab in sync_fsync (ap=0xc3b38f7c) at ../../sys/mutex.h:603
#13 0xc01a7c0e in sched_sync () at vnode_if.h:508
(kgdb) quit
ait0fd02# dmesg
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-20001129-SNAP #0: Wed Nov 29 15:12:51 EST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/DEBUG
Timecounter "i8254" frequency 1193168 Hz
Timecounter "TSC" frequency 199430220 Hz
CPU: Pentium/P55C (199.43-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x543 Stepping = 3
Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX
real memory = 33554432 (32768K bytes)
config di pcic0
config di pcm0
config di sn0
config di lnc0
config di le0
config di ie0
config di fe0
config di ed0
config di cs0
config di bt0
config di aic0
config di aha0
config di adv0
config q
avail memory = 29642752 (28948K bytes)
Preloaded elf kernel "kernel" at 0xc0323000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc032309c.
Intel Pentium detected, installing workaround for F00F bug
seq0-15: Midi sequencers.
VESA: v1.2, 1024k memory, flags:0x0, mode table:0xc00c4c13 (c0004c13)
VESA: S3 Incorporated. Trio64V+
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX3 ATA controller port 0xf000-0xf00f at device
Re: Other Linux stuff...
If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? Bruce. PGP signature
Re: 3dfx.ko
Thanks! This works great. I remember reading the stuff at the bottom of /boot/defaults/loader.conf about the 'module_name' variable, etc. and wondering what on Earth it might be useful for :) Guess I know now :) Thanks again... "Daniel C. Sobral" wrote: Use two variables to control this. For instance: threedfx_load="YES" threedfx_name="3dfx" The way loader is set up, you put the _name line in /boot/defaults/loader.conf, so that the user only needs to put the threedfx_load="YES" line in his config. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
"Bruce A. Mah" wrote: If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? The only gain I see, if you can call it a gain, is that you can get non-trivial information out of a shared object from within scripts, but I don't know if this has been the reason. If you don't allow execution of shared objects, you have to use dlopen(3) and call some functions or query some variables. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
Here's a report, that you may ignore if needed... I'm building news machines with two partitions for OSen, to allow me to boot into my choice, where my choice has been FreeBSD-STABLE or FreeBSD-CURRENT to see how the two compare, and if there are any significant improvements in -CURRENT. I know, ``don't do that'' but hey... Anyway, using the performance with -STABLE as a reference on this system with currently a single CPU, I built a freshly cvsup'ed -CURRENT just under 24 hours ago and then ran it in production for about ten hours before reverting back to -STABLE. First of all, after building a custom kernel and mounting several disks with softupdates, I then gave a command to cp -pR /news/dir to /news/FreeBSD-STABLE-dir , where the /news disk is mounted with both softupdates and noatime. Quickly I got a panic: ffs_valloc: dup alloc and everything froze solid. I didn't attempt to repeat this to see if it is repeatable. I disabled the softupdates, remounted the disk (just noatime) and again gave the cp -pR command, which succeesed. In fact, for the next ten hours, I attempted to pump a full newsfeed through this machine with no problems and stable operation. A few other drives are mounted with both noatime and softupdates, but without the file creation activity one gets with the command I gave. Also, I was sort of running low on inodes, although I never actually ran out, if that would make any difference. Now, as far as performance goes, after running for ten hours and getting a feel for how well it was doing, I rebooted back into -STABLE and restarted things. However, I see a huge performance increase with -STABLE compared to -CURRENT. That is, I'm able to take in many more times the number of articles with -STABLE than the machine running -CURRENT could handle. Like by a factor of ten. Basically, apart from the current/stable switch, the machine is identical in both OSen, and there shoulr be no difference in the news software proper. The kernel configs should be comparable too. Yeah, I know, -current is in a state of transition, but I didn't expect its performance to be quite *this* bad... These are just some observations, in the hope they might be useful. thanks, barry bouwsma, putting hardware to waste since 1997 (use reply-to header if this message is worthy of comment best kept off the list) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
On Thu, 23 Nov 2000, Julian Elischer wrote: locore.s includes: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ movl$((foo)*PAGE_SIZE),%ecx ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb might it be a very slight optimisation to change this to: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ movl%eax, %ecx ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb This can be improved more (3 instructions) by not loading physfree into the wrong register, and depending on stosb to increment the register, but it should be written in C anyway. A relocation macro like R() should work just as well in C as in asm. In C, the above is: bzero(R(physfree), (foo) * PAGE_SIZE); R(physfree) += (foo) * PAGE_SIZE); return (R(physfree)); /* In unusual as well as wrong reg %esi. */ Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
