/dev/lpt0 - always busy, except when acpi is disabled
Hello, I am running: FreeBSD xxx.x.xxx 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Aug 26 21:02:35 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386 I have a problem accessing the printer connected to the box via parallel port. Whenever I try to send something to /dev/lpt0, it always responds with 'device busy' error message, while that device is not being used by any other program. This behavior started once I upgraded to 5.1-release and continues through 'current.' When I was using 5.0-release, the system worked fine and I never had this problem, but once I upgraded, this mystery started to happen. Here is some background info. My kernel configuration file contains the following devices: device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device PPC hints in the /boot/device.hints file are: hint.ppc.0.at="isa" hint.ppc.0.irq="7" As you can see, irq number is specified, so the system is supposed to communicate with the printer in interrupt-driven mode. But, for some misterious reason that doesn't happen. Here is the part of my dmesg output related to pp* and lpt: ppc0 port 0-0x7 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 As you can see, the communication is carried out in polled mode. I am not sure why...? I was going back and forth trying to make the printer work and found a 'solution' for that problem. The 'solution' is to disable acpi. hint.acpi.0.disabled="1" - works like a charm. After disabling acpi I get the ability to use my printer and the following dmesg output: ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER ESCPL2,BDC,D4 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 As I already mentioned, this never happened when my box was running 5.0-release, but started to happen right after the moment when I upgraded to 5.1-release, and continues to happen on 5.1-current. I am wondering if this is a bug in the source code and can only be fixed with a patch, or there is a work around through acpi configuration? ACPI manual page says that one can disable parts of acpi through 'debug.acpi.disable' kernel environment variable. In that case, what is the minimal set of sub-devices that I would temporarly have to disable to resolve this problem? Perhaps I got right in the middle of ongoing work with acpi? Any hints, pointers or links will be greatly appreciated! Thanks in advance. Andrew pgp0.pgp Description: PGP signature
Re: bcm4400 driver and Dell 8500
On Wed, Aug 27, 2003 at 12:24:11 -0500, James Nobis wrote: > > > On Wed, 27 Aug 2003, Joe Marcus Clarke wrote: > > > On Wed, 2003-08-27 at 09:27, James Nobis wrote: > > > On Wed, 27 Aug 2003, Kenneth D. Merry wrote: > > > > > > > On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote: > > > > > Hello James and Ken, > > > > > > > > > > Both of you are having real problems with the bcm driver and both of you > > > > > have a Dell 8500. > > > > > > > > > > This is James' dmesg output, which from memory looks very similar to your > > > > > Ken? > > > > > > > > > > > bcm0: mem 0xfaffe000-0xfaff irq 11 > > > > > > at device 0.0 on pci2 > > > > > > bcm0: Ethernet address: ff:ff:ff:ff:ff:ff > > > > > > panic: bcm0: Strange type for core 0x > > > > > > > > Yep, the messages I get are identical when I load it as a module. > > > > > > > > > > I'm running 5.1-current from august 22nd. I can try pulling down the > > > > > > latest 5.1 tommorow if you think this might help. This is the same result > > > > > > as when I tried the driver from over a month ago. > > > > > > > > > > We think that the problem is something to do with the PCI configuration of > > > > > the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the > > > > > memory map is not right. > > > > > > > > > > > Before sending this email I was going to obtain a backtrace. I recompiled > > > > > > with the symbol table and kernel debugger and now the driver appears to > > > > > > work fine. Should it work this way? > > > > > > > > > > Hmm interesting. Ken can you try this and see if the driver then works? > > > > > > > > I've already got the kernel debugger on. Do you mean changing the module > > > > compile somehow so that more symbols are included? (It seems to resolve > > > > the function addresses in the module fine.) > > > > > > > > > > compiling with options DDB and makeoptions DEBUG=-g is what i mean > > > > Note, on my 5150, I also have a kernel built with -g. I do not have DDB > > compiled in, but I have never tried a kernel without -g. I may be > > susceptible to the same "all-ffs" problem. > > > > Joe > > When i just did a -g, it still would crash when i tried to load the Ahh. I've had DDB on the whole time, but I've found that I don't get a crash (i.e. the all ff's problem) if I don't have my fxp card plugged in when I load the bcm module. dhclient doesn't cause the system to run out of mbufs, but then again it hangs. If I ifconfig the interface manually things work fine. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bcm4400 driver and Dell 8500
On Wed, Aug 27, 2003 at 18:27:57 +0100, Duncan Barclay wrote:
>
> On 27-Aug-2003 Kenneth D. Merry wrote:
> > On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote:
> >> Hello James and Ken,
> >>
> >> Both of you are having real problems with the bcm driver and both of you
> >> have a Dell 8500.
> >>
> >> This is James' dmesg output, which from memory looks very similar to your
> >> Ken?
> >>
> >> > bcm0: mem 0xfaffe000-0xfaff irq 11
> >> > at device 0.0 on pci2
> >> > bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
> >> > panic: bcm0: Strange type for core 0x
> >
> > Yep, the messages I get are identical when I load it as a module.
> >
> >> > I'm running 5.1-current from august 22nd. I can try pulling down the
> >> > latest 5.1 tommorow if you think this might help. This is the same result
> >> > as when I tried the driver from over a month ago.
> >>
> >> We think that the problem is something to do with the PCI configuration of
> >> the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the
> >> memory map is not right.
> >>
> >> > Before sending this email I was going to obtain a backtrace. I recompiled
> >> > with the symbol table and kernel debugger and now the driver appears to
> >> > work fine. Should it work this way?
> >>
> >> Hmm interesting. Ken can you try this and see if the driver then works?
> >
> > I've already got the kernel debugger on. Do you mean changing the module
> > compile somehow so that more symbols are included? (It seems to resolve
> > the function addresses in the module fine.)
> >
> > The stack trace from the module load is:
> >
> > panic()
> > bcm_chip_get_core()
> > bcm_chip_reset()
> > bcm_attach()
> > device_probe_and_attach()
> > etc.
> >
> > If I boot a kernel with the bcm driver compiled in, and don't attach to the
> > docking station, it comes up fine until I insert my fxp card in the carbus
> > slot. Then I get the panic in bcm_ring_rx_eof() that I reported last
> > night. FWIW, when I have the driver compiled in, the memory location is
> > identical to location used when the module loads (above), but the ethernet
> > address is properly decoded:
>
> This is still smelling of memory stuff outside of my experience.
>
> > bcm0: mem 0xfaffe000-0xfaff irq 11 at
> > device 0.0 on pci2
> > bcm0: Ethernet address: 00:0b:db:94:bf:42
> > miibus0: on bcm0
> >
> > If I boot a kernel with the bcm driver compiled in, and don't attach to the
> > docking station, and don't insert my fxp card, I get slightly further. I
> > tried running dhclient, and got:
> >
> > All mbufs or mbuf clusters exhausted, please see tuning(7).
> > bcm0: initialization failed: no memory for rx buffers
>
> Just checked dhclient and it works fine for me.
I just had another failure case (when I loaded bcm(4) as a module but
didn't have my fxp card inserted) where dhclient just hung up. I didn't
get any out of mbufs errors.
> > Then I tried just manually ifconfiging the interface, and it works!
> >
> > Here's what netstat -m says:
> >
> > {erebor:/usr/home/ken:1:0} netstat -nm
> > mbuf usage:
> > GEN cache: 0/0 (in use/in pool)
> > CPU #0 cache: 576/608 (in use/in pool)
> > Total: 576/608 (in use/in pool)
> > Mbuf cache high watermark: 512
> > Maximum possible: 34304
> > Allocated mbuf types:
> > 576 mbufs allocated to data
> > 1% of mbuf map consumed
> > mbuf cluster usage:
> > GEN cache: 0/0 (in use/in pool)
> > CPU #0 cache: 575/584 (in use/in pool)
> > Total: 575/584 (in use/in pool)
> > Cluster cache high watermark: 128
> > Maximum possible: 17152
> > 3% of cluster map consumed
> > 1320 KBytes of wired memory reserved (98% in use)
> > 1 requests for memory denied
> > 0 requests for memory delayed
> > 0 calls to protocol drain routines
> >
> > Performance, once I manually assigned an address seems okay; I was able to
> > ftp a file over from another machine at a little over 11MB/sec.
>
> Cool, thats about right.
>
> > If I insert the fxp card after the bcm driver is configured, the cardbus
> > initialization fails, and then I get the following messages over and over
> > again:
> >
> > "eek j=6, macCurrent 511, con288"
>
> This is a little loop that waits for the card to finish DMAing a packet. There
> should be a DELAY(1) in there. But it may be commented out.
That's bad...in general the chip should DMA the packet and then update the
consumer index and generate an interrupt. I don't know how this particular
chip works, though. The DELAY is commented out.
> Do we think that cardbus is trashing the memory space somehow?
That could very well be the case. I don't know anything about cardbus,
though.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscri
Re: [hackers] Re: BCM4401 ethernet driver
On Tuesday, 26 August 2003 at 20:31:22 +0100, Duncan Barclay wrote: > > On 26-Aug-2003 [EMAIL PROTECTED] wrote: >> Greetings; >> >> Wondering whatever further may have come of this discussion regarding >> FreeBSD support of the built-in ethernet for the Dell Inspiron 8500 Notebook. >> Running a dual-boot system with MS Windows XP and FreeBSD 4.8 Release since >> 5.1 >> wouldn't seem to install, but not even sure how to make use of drivers beyond >> including their device code in the kernel configuration file, which may just >> be an issue with this current release. > > I fixed the RX problem yesterday. Take a look at > http://people.freebsd.org/~dmlb/ > and grab the lastest bcm_...tar.gz file. Untar this into /sys > then > cd /sys/modules/bcm > make > make install > kldload if_bcm > > This driver is for -current only. OK, I've tried this on my Inspiron 5100, and it works without any recognizable problems: $ time scp wantadilla:/dumpa/echunga/0/src.gz /dev/null src.gz 100% 28GB 10.0MB/s 48:41 real48m41.751s user15m41.577s sys 4m23.766s netstat -i shows: input (bcm0) output packets errs bytespackets errs bytes colls 7452 0 11280248 5373 0 361578 0 7502 0 11358028 5416 0 364512 0 7435 0 11256590 5366 0 361116 0 7504 0 11361056 5416 0 364464 0 7460 0 11292512 5384 0 362352 0 7500 0 11355000 5412 0 364200 0 7451 0 11279390 5379 0 362022 0 7503 0 11358088 5414 0 364332 0 7417 0 11228874 5359 0 360654 0 I'd say that this cut is good enough to commit to -CURRENT. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: bcm4400 driver and Dell 8500
From: "Kenneth D. Merry" <[EMAIL PROTECTED]> > > This is a little loop that waits for the card to finish DMAing a packet. There > > should be a DELAY(1) in there. But it may be commented out. > > That's bad...in general the chip should DMA the packet and then update the > consumer index and generate an interrupt. I don't know how this particular > chip works, though. The DELAY is commented out. Unfortunately I don't know how the chips works wither. This method comes from the drivers I used as a reference. I have recoded the loop a little so it doesn't DELAY and I've never had a timeout from it. > > Do we think that cardbus is trashing the memory space somehow? > > That could very well be the case. I don't know anything about cardbus, > though. Me neither, but my laptop needs some help in that area, so that's what I'm going to look at next. > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bcm4400 driver and Dell 8500
(apologies for the large cc list, im only subbed to -mobile so not sure who is where) On Thu Aug 28, 08:21P +0100, Duncan Barclay wrote: > From: "Kenneth D. Merry" <[EMAIL PROTECTED]> > > > > This is a little loop that waits for the card to finish DMAing a packet. > There > > > should be a DELAY(1) in there. But it may be commented out. > > > > That's bad...in general the chip should DMA the packet and then update the > > consumer index and generate an interrupt. I don't know how this > particular > > chip works, though. The DELAY is commented out. > > Unfortunately I don't know how the chips works wither. This method comes > from the drivers I used as a reference. I have recoded the loop a little so > it doesn't DELAY and I've never had a timeout from it. > That is how this chip works. It rxes a packet, prepends an rxheader to it, DMAs it and then updates the index and generates an interrupt. If it reaches the last descriptor(marked by an end of table flag) it resets it 0. The chip does have a 'lazy rx' mode which can be set to interrupt after a certain amount of frames or a certain amount of data. These problems may or may not mystically disappear when I finish merging Duncan and I's drivers, but I wouldn't hold your breath. :) Regards, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Atmel USB Wireless devices
Hi, Firstly, it would be interesting to know if anyone else is working on support for these devices before I get too far into it :) I've started working on support for the above devices and have had some limited success so far. The device requires two sets of firmware to be uploaded for it to work and I have managed to upload the first firmware but it doesnt seem to want to boot. Any attempts to read the device after uploading firmware result in error code 13(IOERROR). The Linux driver calls usb_reset_device() after uploading the firmware but I can't seem to find an equivelant in FreeBSD. If anyone has any suggestions I'd be greatful :) Thanks, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atmel USB Wireless devices
On Thursday 28 August 2003 15:26, Stuart Walsh wrote: > Hi, > > Firstly, it would be interesting to know if anyone else is working on > support for these devices before I get too far into it :) Yes, I have bought a bunch of them about a month ago, and at this moment I have a working driver for them. At this moment it's still a "beta" which can only do ad-hoc mode, but it works. > I've started working on support for the above devices and have had some > limited success so far. The device requires two sets of firmware to be > uploaded for it to work and I have managed to upload the first firmware > but it doesnt seem to want to boot. Any attempts to read the device > after uploading firmware result in error code 13(IOERROR). The Linux > driver calls usb_reset_device() after uploading the firmware but I can't > seem to find an equivelant in FreeBSD. The problem is that the device really dies after uploading the internal firmware. It really needs a reset before it will communicate again. A usb-hub can send a reset signal down it's ports with a call to : usbd_reset_port(sc->atuwi_udev->myhub,sc->atuwi_udev->powersrc->portno,&T); After that the atmel processor will start communicating again. But it's usb-address will be set to 0 (as always after a reset). So you will have to (re)set it's address back to what it was before the reset with a call to : usbd_set_address(sc->atuwi_udev,my_old_address); The story gets more complex since the descriptors of the device have changed by the reset. (first it only had a control endpoint, now it also has 2 bulk endpoints). Somehow you'll have to reload the new descriptor to please the kernel. I have come very far in this process, but I am doing something wrong with releasing the old descriptors... So at this moment I use a trick to reset the device. After uploading the internal firmware I unplug the USB connector just far enough for the data-lines to disconnect, but without disconnecting the power-lines. After plugging the device back in the kernel recognizes it again and uploads the external firmware. I'll come back to this thread tomorrow and post some links to my code, but I have to run now. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for thread testers
With reguards to apache, can I ask what the state of the network stack and drivers is? I last did any serious apache benchmarking a long time ago, circa FreeBSD 3.1. Then the request per second figure dropped by about 50% when you enabled the second CPU on an SMP system as the apached's fought over the lock.(apache1) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atmel USB Wireless devices
On Thu, 28 Aug 2003, Daan Vreeken [PA4DAN] wrote: > I have come very far in this process, but I am doing something wrong > with releasing the old descriptors... So at this moment I use a trick to > reset the device. After uploading the internal firmware I unplug the USB > connector just far enough for the data-lines to disconnect, but without > disconnecting the power-lines. After plugging the device back in the > kernel recognizes it again and uploads the external firmware. Once you have uploaded the firmware; is any of the vendor, product, or usb revision ID's different. If that is the case; you could use the /etc/usbd.conf trick; download the firmware - then rely on the v/p/r value to change and then pick it up as a new device with something else. Dw. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atmel USB Wireless devices
On Thu Aug 28, 07:15P +0200, Daan Vreeken [PA4DAN] wrote: > On Thursday 28 August 2003 15:26, Stuart Walsh wrote: > > Hi, > > > > Firstly, it would be interesting to know if anyone else is working on > > support for these devices before I get too far into it :) > Yes, I have bought a bunch of them about a month ago, and at this moment I > have a working driver for them. At this moment it's still a "beta" which can > only do ad-hoc mode, but it works. Ok, that saves some duplicated effort :) > > I've started working on support for the above devices and have had some > > limited success so far. The device requires two sets of firmware to be > > uploaded for it to work and I have managed to upload the first firmware > > but it doesnt seem to want to boot. Any attempts to read the device > > after uploading firmware result in error code 13(IOERROR). The Linux > > driver calls usb_reset_device() after uploading the firmware but I can't > > seem to find an equivelant in FreeBSD. > The problem is that the device really dies after uploading the internal > firmware. It really needs a reset before it will communicate again. > A usb-hub can send a reset signal down it's ports with a call to : > usbd_reset_port(sc->atuwi_udev->myhub,sc->atuwi_udev->powersrc->portno,&T); > That bit works fine. > After that the atmel processor will start communicating again. But it's > usb-address will be set to 0 (as always after a reset). > So you will have to (re)set it's address back to what it was before the reset > with a call to : > usbd_set_address(sc->atuwi_udev,my_old_address); This fails with another IOERROR > > The story gets more complex since the descriptors of the device have changed > by the reset. (first it only had a control endpoint, now it also has 2 bulk > endpoints). Somehow you'll have to reload the new descriptor to please the > kernel. > I have come very far in this process, but I am doing something wrong with > releasing the old descriptors... So at this moment I use a trick to reset the > device. > After uploading the internal firmware I unplug the USB connector just far > enough for the data-lines to disconnect, but without disconnecting the > power-lines. After plugging the device back in the kernel recognizes it again > and uploads the external firmware. > Hopefully I can look into this when I can talk to the device a bit better :) > I'll come back to this thread tomorrow and post some links to my code, but I > have to run now. Thanks for the info.. I'll wait to see your code and see where I'm going wrong. Regards, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug FreeBSD 4.8 ATA driver
On Tue, 26 Aug 2003, Dan Lukes wrote:
> Mikulas Patocka napsal/wrote, On 08/20/03 01:39:
> > I am reading FreeBSD ATA drivers because I want to use them as base for my
> > ATA driver and I found a total nonsence: in ata-dma.c in FreeBSD 4.8,
> > there is line
> >
> > if (!((pci_read_config(parent,0x40,4)>>(ch->unit<<8))&0x4000)) {
> >
> > if ch->unit is 1, config word is shifted by 256 bytes, which gives
> > undefined result in C. How was this meant? What should it do?
>
> Hm, it should be (IMHO)
> if (!((pci_read_config(parent,0x40,4)>>(ch->unit<<5))&0x4000))
That is incorrect too --- if ch->unit is 1, ch->unit<<5 is 32 and you
can't shift 32-bit integer by 32 bits.
> but I can't verify it as have no access to documentation for PIIX3 nor
> acces to the PIIX3 hardware now.
>
> Note the position of '8' just above the '5' key on numeric keypad also ...
>
> FYI, the gcc compile the code as equivalent of
> if (!((pci_read_config(parent,0x40,4)>>(0))&0x4000))
> effectively ignoring the ch->unit number.
>
>
> If you want wrote your own ATA driver, it may be better to look into
> current FreeBSD 5 ATA code - it's substantially rewrited.
I noticed it too late --- when I copid all code from FreeBSD 4 :-/
> A smel bych, uz asi mimo konferenci, vedet, proc si pises vlastni ATA
> ovladac ?
No, zatim to neni moc verejny projekt.
Mikulas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New European software patents law !!!
http://petition.eurolinux.org/ sign the petition against the new patents law. find more about this law at http://swpat.ffii.org/ and mirror their website (for load purposes). close your website as did www.gimp.org and protest with banners, and in any other way. God bless the virus industry. Yours, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FYI - Just got a kernel panic - RELENG_4
supped as of ~ 1:40pm EST today The panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x5b4984c8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02714a9 stack pointer = 0x10:0xd5d3ecf4 frame pointer = 0x10:0xd5d3ecf8 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 = 34411 (tar) interrupt mask = net tty bio cam trap number = 12 panic: page fault Current kldstat (shouldn't be different from the one during the panic) $ kldstat Id Refs AddressSize Name 16 0xc010 2c6d78 kernel 21 0xc1286000 a000 ntfs.ko 31 0xc12ca000 7000 linprocfs.ko 41 0xc1341000 2000 green_saver.ko 52 0xc1344000 15000linux.ko 61 0xc138a000 2000 rtc.ko kernel IP info: $ nm -n /kernel ... c0271394 T vm_page_unhold c02713b0 T vm_page_insert c0271430 T vm_page_remove c02714f8 T vm_page_lookup c0271554 T vm_page_rename c02715ac T vm_page_unqueue_nowakeup c02715f4 T vm_page_unqueue c027166c T _vm_page_list_find ... cvs tag of file containing "offending" function: * $FreeBSD: src/sys/vm/vm_page.c,v 1.147.2.19 2003/08/09 16:21:21 luoqi Exp $ Attached is the dmesg of the session that led to the panic, as well as my kernel configuration file (LAPTOP). I don't see anything very peculiar about it... How else can I help? Thanks, Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) http://www.bluecirclesoft.com http://www.mrami.com (personal)# # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.53 2003/03/25 23:33:44 jhb Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident LAPTOP maxusers0 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories 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_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options 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 USER_LDT # To make an SMP kernel, the next two are neede
non reliable nmi
I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
