Re: SMP kernel panics after calling acquire_timer0
On Sat, 8 Jan 2000, Mohit Aron wrote: > Hi, > I'm using FreeBSD-current (snapshot from Jan 3rd) which is configured > with both SMP and APIC_IO support. This version panics upon calling > acquire_timer0() (to modify the interrupt frequency of the 8254). On the other > hand, if the kernel is not configured as an SMP, then it works fine. The panic > reports some problem with some SMP lock - I can get more details if someone > is interested in looking at the problem. This is cause by calling disable_intr() when a lock is held. disable_intr() is a funky macro in the SMP case. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP kernel panics after calling acquire_timer0
> > You may want to upgrade to a more recent source tree : > I've cvsupped from a 4.0-19991229-CURRENT snapshot to the sources around > 01/05 21h00 GMT and SMP works fine on my machine (I have seen strange > things with the snapshot : cvs did not want to check out the source tree > ! not a pleasant discovery when wanting to update the sources) > Well, SMP does work fine otherwise - I was doing experiments with some past code that I ported over to FreeBSD-4.0. As soon as I make the call acquire_timer0, it panics. I'm sorry if my mail earlier made it appear as if I can't even bring up the machine as an SMP. > Is your machine specific in some ways ? (Compaq, for example) > Its a standard 500MHz Xeon processor in a server machine. I don't think there's anything specific. > You may also post excerpts from your dmesg when booting as UP. > Here are some if they help: Jan 8 00:33:43 idli /kernel: Timecounter "i8254" frequency 1193182 Hz Jan 8 00:33:43 idli /kernel: CPU: Pentium III/Xeon (500.04-MHz 686-class CPU) Jan 8 00:33:43 idli /kernel: Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Jan 8 00:33:43 idli /kernel: Features=0x387fbff Jan 8 00:33:43 idli /kernel: real memory = 1342177280 (1310720K bytes) Jan 8 00:33:43 idli /kernel: avail memory = 1297195008 (1266792K bytes) Jan 8 00:33:43 idli /kernel: Preloaded elf kernel "kernel" at 0xc0382000. Jan 8 00:33:43 idli /kernel: Pentium Pro MTRR support enabled - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP kernel panics after calling acquire_timer0
hello, You may want to upgrade to a more recent source tree : I've cvsupped from a 4.0-19991229-CURRENT snapshot to the sources around 01/05 21h00 GMT and SMP works fine on my machine (I have seen strange things with the snapshot : cvs did not want to check out the source tree ! not a pleasant discovery when wanting to update the sources) Is your machine specific in some ways ? (Compaq, for example) You may also post excerpts from your dmesg when booting as UP. TfH Mohit Aron wrote: > > Hi, > I'm using FreeBSD-current (snapshot from Jan 3rd) which is configured > with both SMP and APIC_IO support. This version panics upon calling > acquire_timer0() (to modify the interrupt frequency of the 8254). On the other > hand, if the kernel is not configured as an SMP, then it works fine. The panic > reports some problem with some SMP lock - I can get more details if someone > is interested in looking at the problem. > > - Mohit > > 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
SMP kernel panics after calling acquire_timer0
Hi, I'm using FreeBSD-current (snapshot from Jan 3rd) which is configured with both SMP and APIC_IO support. This version panics upon calling acquire_timer0() (to modify the interrupt frequency of the 8254). On the other hand, if the kernel is not configured as an SMP, then it works fine. The panic reports some problem with some SMP lock - I can get more details if someone is interested in looking at the problem. - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
