acpi
Why acpi.ko module missed after latest CVS update? -- Konstantin M. Volevatch <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: APIC-UP related panic
On Thursday 06 November 2003 17:33, John Baldwin wrote: > On 06-Nov-2003 Harald Schmalzbauer wrote: > > Hello, > > > > I have one reproducable panic with sources from 04. Nov when enabling > > "device apic" in the kernel. > > While building OpenOffice about 1 1/2 hours after start the system > > reboots. This is absolutely reproducable. Removing device apic from the > > kernel solves the problem! > > The only thing I have are these lines from /var/log/messages: > > (attached the different dmesgs) > > > > Nov 5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel > > Nov 5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d > > Nov 5 13:41:40 cale kernel: stack pointer = 0x10:0xcdc9dbe0 > > Nov 5 13:41:40 cale kernel: frame pointer = 0x10:0xcdc9dbe4 > > Nov 5 13:41:40 cale kernel: code segment = base 0x0, limit > > 0xf, type 0x1b > > Nov 5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1 > > Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL > > = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: > > nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 > > Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap > > Nov 5 13:41:40 cale kernel: > > Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 > > 2202 2202 2202 2202 2202 2202 > > 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 > > Nov 5 13:41:40 cale kernel: giving up on 1022 buffers > > Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s > > Nov 5 13:41:40 cale kernel: Shutting down ACPI > > Nov 5 13:41:40 cale kernel: stray irq9 > > Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key > > on the console to abort > > Nov 5 13:41:40 cale kernel: Rebooting... > > Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch Regrettably this hasn't helped. The machine crashed aigain when building OpenOffice. This time I have something different in messages: Nov 7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 7 19:51:27 cale kernel: panic: Couldn't get vector from ISR! Nov 7 19:51:27 cale kernel: Nov 7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 7 19:51:27 cale kernel: giving up on 1109 buffers Nov 7 19:51:27 cale kernel: Uptime: 3h57m51s Nov 7 19:51:27 cale kernel: Shutting down ACPI Nov 7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 7 19:51:27 cale kernel: Rebooting... Let me know if I can help. Should I build a debug-kernel? I think that doesn't help too much since the machine rebootos immediately, so I have no chance to type anything like trace. -Harry pgp0.pgp Description: signature
[current tinderbox] failure on alpha/alpha
TB --- 2003-11-08 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-08 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-08 05:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-08 05:02:04 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-08 06:06:08 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Nov 8 06:06:08 GMT 2003 >>> Kernel build for GENERIC completed on Sat Nov 8 06:18:04 GMT 2003 TB --- 2003-11-08 06:18:04 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-08 06:18:04 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 8 06:18:04 GMT 2003 [...] awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/pccard/card_if.m -c ; cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror ! card_if.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/pccard/pccard.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/pccard/pccard_cis.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/
Re: burncd block size
Does this *fix* atapicam? Or is atapicam still only about 50% operational? I can't get atapicam to work with my atapi tape drive at all. And power calibrations malfunction via atapicam with cdrdao and cdrecord. And if I blank a cd-rw, the atapicam'ed programs return after like 2S, *THEN* it seems the commands make it to the cd burner and *THEN* it starts blanking! Argh! Soren Schmidt wrote: It seems Jeremy Messenger wrote: On Fri, 07 Nov 2003 10:10:40 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: I've been having a variety of problems burning CDs with atang: - burncd consistently failing in exactly the same spot in the ISO, and reporting "only wrote 0 of 32768 bytes: Unknown error: 0" - burncd failing right at the start with "only wrote -1 of 32768 bytes: Input/output error" (this generally happens after a couple of the previous, and once it starts happening I have to reboot) Whew, glad that I am not only one.. I *just* have wasted two of my blank CD in like fifteen minutes ago, I keep wondering if I created the ISO files in the wrong way or was it burncd's fault.. Until now here.. This is fallout from getting atapi-cd under GEOM. GEOM wasn't designed to handle medias of size 0 and where the sizes can change during an open. I just committed a fix that has solved the issue here (and its ugly). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too many uncorrectable read errors with atang
On Fri, Nov 07, 2003 at 08:36:28PM -0800, Andrew P. Lentvorski, Jr. wrote: > On Fri, 7 Nov 2003, John Baldwin wrote: > > > On 07-Nov-2003 Kris Kennaway wrote: > > > So far this has happened (well, the panic above was new) on 5 separate > > > machines that were all working on older -current. Now, these are all > > > IBM DeathStar drives, but previously I was only experiencing ata > > > errors every month or two, and they were correctable for another month > > > or two by /dev/zero'ing the drive. > > IBM Deathstar's have this annoying tendency to perform thermal > recalibration cycles that cause them to delay returning data for somewhere > between 30-90 seconds until the calibration finishes. Unfortunately, > these seem to show up as uncorrectable errors. It's a true pain with RAID > cards as the RAID array will take the drive offline when it could retry > the data. > > If you can, try to reduce the temperature of the drives. This generally > helped my Deathstars before I got rid of them all. > > Also, given the touchiness of PRML detectors, it is entirely possible that > the drive is reading increased errors due to the solar flares as a need to > thermally recalibrate more often. > > Other than tossing the drives, ATAng, like Windows, would have to be more > aggressive about retrying even uncorrectable errors for up to a minute or > so before giving up. Thanks..that's interesting, perhaps there's something sos can do here. Unfortunately the drives in question are in Yahoo's datacenter, so I do not have physical access. Kris pgp0.pgp Description: PGP signature
RE: Too many uncorrectable read errors with atang
On Fri, 7 Nov 2003, John Baldwin wrote: > On 07-Nov-2003 Kris Kennaway wrote: > > So far this has happened (well, the panic above was new) on 5 separate > > machines that were all working on older -current. Now, these are all > > IBM DeathStar drives, but previously I was only experiencing ata > > errors every month or two, and they were correctable for another month > > or two by /dev/zero'ing the drive. IBM Deathstar's have this annoying tendency to perform thermal recalibration cycles that cause them to delay returning data for somewhere between 30-90 seconds until the calibration finishes. Unfortunately, these seem to show up as uncorrectable errors. It's a true pain with RAID cards as the RAID array will take the drive offline when it could retry the data. If you can, try to reduce the temperature of the drives. This generally helped my Deathstars before I got rid of them all. Also, given the touchiness of PRML detectors, it is entirely possible that the drive is reading increased errors due to the solar flares as a need to thermally recalibrate more often. Other than tossing the drives, ATAng, like Windows, would have to be more aggressive about retrying even uncorrectable errors for up to a minute or so before giving up. -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Small bug with pppctl
Hello, I noticed that using pppctl interactively doesn't work quite right, at least for certain commands that produce a lot of output. I cut and pasted a few invocations to show what works and what doesn't quite work: $ pppctl /var/ppp/ppp PPP ON bogushost2> show route Destination Gateway Flags Netif Connection closed $ pppctl /var/ppp/ppp PPP ON bogushost2> show ? (o) = Optional context, (c) = Context required Connection closed $ pppctl /var/ppp/ppp PPP ON bogushost2> help (o) = Optional context, (c) = Context required Connection closed $ pppctl /var/ppp/ppp PPP ON bogushost2> close PPp ON bogushost2> ppp ON bogushost2> Ppp ON bogushost2> PPp ON bogushost2> PPP ON bogushost2> quit ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE kernel panic
Hello! I'm having some trouble booting the 5.1-RELEASE installation floppies on an old AST Premmia GX P/133 SMP machine. The system is currently running 3.5-STABLE without any problems. Any ideas anyone?? dmesg output follows: FreeBSD/i386 boot Default: 0:fd(0,a)/boot/loader boot: Uncompressing ... done Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 640kB/97280kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Thu Jun 5 00:52:26 GMT 2003) /kernel text=0x237550 data=0x2f140+0x4b63c - Please insert MFS root floppy and press enter: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel] in 9 seconds... Booting [/kernel] in 8 seconds... Booting [/kernel] in 7 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v stray irq 7 SMAP type=01 base= len=000a SMAP type=02 base=000f len=0001 SMAP type=01 base=0010 len=05f0 SMAP type=02 base=fffe len=0002 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=c3fe72bf base=c3b736bbc3af2ebb len=c3ffdebbc3ffe0bb Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Thu Jun 5 03:08:07 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel "/kernel" at 0xc07ec000. Preloaded mfs_root "/mfsroot" at 0xc07ec1dc. Calibrating clock(s) ... i8254 clock: 1193784 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 133262060 Hz Timecounter "TSC" frequency 133262060 Hz CPU: Pentium/P54C (133.26-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x3bf real memory = 100663296 (96 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00813000 - 0x05e29fff, 90271744 bytes (22039 pages) avail memory = 89374720 (85 MB) bios32: Found BIOS32 Service Directory header at 0xc00fe100 bios32: Entry = 0xfa8f6 (c00fa8f6) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xa1a0 pnpbios: Found PnP BIOS data at 0xc00f1790 pnpbios: Entry = f:185e Rev = 1.0 pnpbios: OEM ID 1127406 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug null: mem: md0: Preloaded image 4423680 bytes at 0xc03b2cdc npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x80002000 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -- nothing found pci_open(1b): mode1res=0x8000 (0xff01) pci_cfgcheck: device 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -- nothing found pci_open(2):mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086) pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x04a3, revid=0x11 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2400, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0482, revid=0x03 bus=0, slot=2, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base fe80, size 14, enabled map[14]: type 3, range 32, base fe00, size 23, enabled found-> vendor=0x102b, dev=0x0519, revid=0x01 bus=0, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 4, range 32, base 01f0, size 4, enabled map[14]: type 4, range 32, base 03f4, size 2, enabled map[18]: type 4, range 32, base , size 3, enabled map[1c]: type 4, range 32, base , size 2, enabled map[20]: type 4, range 32, base 0900, size 4, enabled found-> vendor=0x1095, dev=0x0646, revid=0x01 bus=0, slot=6, func=0 class=01-01-8e, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 eisab0: at device 2.0 on pci0 eisa0: on eisab0 mainboard0:
Re: small regression in cbb and a confusion with rl driver
In message: <[EMAIL PROTECTED]> Sven Petai <[EMAIL PROTECTED]> writes: : this bug is introduced by the version 1.86 of the file I think I've committed a fix for this. It disables the workaround for some chipsets. I'll reenable it when I can verify things better. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an off by one error there. Grr. I've seen, but I didn't found a bios option to set it to edge. Is there anything I can do on my machine to fix the problem, or should Asus be notified for a bios update or ...? Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
On 07-Nov-2003 Jens Rehsack wrote: > John Baldwin wrote: >> On 07-Nov-2003 Jens Rehsack wrote: >> >>>Lars Eggert wrote: >>> John Baldwin wrote: >On 07-Nov-2003 Lars Eggert wrote: > >>This looks similar to what I described in the "fwohci0 running wild" >>thread. In both cases, irq16 seems to cause the problem... > > >Really. Does this only happen with ACPI enabled? Don't know about "only", since I have never booted this machine without ACPI. I'll test next time I'm rebooting. >>> >>>Don't do it. I do it for testing a few minutes ago - and it >>>prevents irq 16 from storming. But it does because the machine >>>hangs at boot with: >>>isa_probe_children: probing PnP devices >>> >>>I let it probe for about 10 minutes (you'll never know :-)), >>>but it wont do. >> >> Grrr, ok. Can you try the patch at >> http://www.FreeBSD.org/~jhb/patches/io_apic.patch and nab a boot -v >> dmesg with ACPI enabled? Thanks. > > Attached. Or shall I upload it to a web-server, too? Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an off by one error there. Grr. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: On 07-Nov-2003 Jens Rehsack wrote: Lars Eggert wrote: John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about "only", since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Don't do it. I do it for testing a few minutes ago - and it prevents irq 16 from storming. But it does because the machine hangs at boot with: isa_probe_children: probing PnP devices I let it probe for about 10 minutes (you'll never know :-)), but it wont do. Grrr, ok. Can you try the patch at http://www.FreeBSD.org/~jhb/patches/io_apic.patch and nab a boot -v dmesg with ACPI enabled? Thanks. Attached. Or shall I upload it to a web-server, too? Jens Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Fri Nov 7 22:43:13 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER Preloaded elf kernel "/boot/kernel/kernel" at 0xc087f000. Calibrating clock(s) ... i8254 clock: 1193214 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2398855680 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c29000 - 0x3ed0afff, 1041113088 bytes (254178 pages) avail memory = 1032667136 (984 MB) ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 bios32: Found BIOS32 Service Directory header at 0xc00f bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x31 pnpbios: Found PnP BIOS data at 0xc00f5580 pnpbios: Entry = f:616a Rev = 1.0 Other BIOS signatures found: MADT: Found IO APIC ID 2, Vector 0 at 0xfec0 ioapic0: intpin 0 -> ExtINT (edge, activehi) ioapic0: intpin 1 -> irq 1 (edge, activehi) ioapic0: intpin 2 -> irq 2 (edge, activehi) ioapic0: intpin 3 -> irq 3 (edge, activehi) ioapic0: intpin 4 -> irq 4 (edge, activehi) ioapic0: intpin 5 -> irq 5 (edge, activehi) ioapic0: intpin 6 -> irq 6 (edge, activehi) ioapic0: intpin 7 -> irq 7 (edge, activehi) ioapic0: intpin 8 -> irq 8 (edge, activehi) ioapic0: intpin 9 -> irq 9 (edge, activehi) ioapic0: intpin 10 -> irq 10 (edge, activehi) ioapic0: intpin 11 -> irq 11 (edge, activehi) ioapic0: intpin 12 -> irq 12 (edge, activehi) ioapic0: intpin 13 -> irq 13 (edge, activehi) ioapic0: intpin 14 -> irq 14 (edge, activehi) ioapic0: intpin 15 -> irq 15 (edge, activehi) ioapic0: intpin 16 -> irq 16 (level, activelo) ioapic0: intpin 17 -> irq 17 (level, activelo) ioapic0: intpin 18 -> irq 18 (level, activelo) ioapic0: intpin 19 -> irq 19 (level, activelo) ioapic0: intpin 20 -> irq 20 (level, activelo) ioapic0: intpin 21 -> irq 21 (level, activelo) ioapic0: intpin 22 -> irq 22 (level, activelo) ioapic0: intpin 23 -> irq 23 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: active-hi ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 43 57 00 c0 01 00 00 00 cd 52 00 c0 00 02 04 01 58 57 00 c0 5f 57 00 c0 6b 57 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 23 mode(s) found VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd) VESA: Matrox Graphics Inc. VESA: Matrox Matrox G550 00 null: acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25708086) pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f5410 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded28A 0x68 3 4 5 6 7 10 11 12 14 15 embedded0 31A 0x62 3 4 5 6 7 10 11 12 14 15 embedded0 31B 0x61 3 4 5 6 7 10 11 12 14 15 embedded0 29A 0x60 3 4 5 6 7 10 11 12 14 15 emb
Re: small regression in cbb and a confusion with rl driver
In message: <[EMAIL PROTECTED]> John Baldwin <[EMAIL PROTECTED]> writes: : The keyboard uses IRQ 1. Disabling using IRQ 1 for the CSC interrupt : fixes several problems I've had recently with my laptop's keyboard (such : as key repeat not working at all, the keyboard typically not working even : in the BIOS after a warm reboot, etc.) OK. I t looks like this chip is sending the IRQ 1 over the serial signalling mechanism. This is part of the work around for the o2micro controllers, since otherwise they will hang the system while configuring. Lemme see if there's something that I can do. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too many uncorrectable read errors with atang
On Fri, Nov 07, 2003 at 10:10:07AM -0800, Kris Kennaway wrote:
> ad0: FAILURE - READ_DMA status=51 error=40
> ad0: FAILURE - READ_DMA status=51 error=40
> ad0: TIMEOUT - READ_DMA retrying (2 retries left)
> ata0: resetting devices ..
> ad0: FAILURE - already active DMA on this device
> ad0: setting up DMA failed
> panic: initiate_write_inodeblock_ufs2: already started
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> trace
I just had another machine panic in the same failure mode.
kris
pgp0.pgp
Description: PGP signature
Re: small regression in cbb and a confusion with rl driver
On 07-Nov-2003 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Baldwin <[EMAIL PROTECTED]> writes:
>:
>: On 07-Nov-2003 John Baldwin wrote:
>: >
>: > On 07-Nov-2003 Sven Petai wrote:
>: >> hi
>: >>
>: >> I upgraded my laptop (compaq Evo n1020V) from 5.1 beta to recent current few
>: >> days ago. I noticed two regressions and hunted down commits that introduced
>: >> them
>: >>
>: >> the first one is that my keyboard doesn't respond before single user mode if I
>: >> reboot fBSD, so I can't break into loader.. it works fine when doing cold
>: >> boot though.
>: >> this bug is introduced by the version 1.86 of the file
>: >> src/sys/dev/pccbb/pccbb.c
>: >> my cbb is recognized as
>: >> cbb0: mem 0xffbfe000-0xffbfefff irq 10 at device
>: >> 10.0 on pci0
>: >> cbb0: Found memory at ffbfe000
>: >> full dmesg is available @
>: >> http://bsd.ee/~hadara/dump/dmesg.2003.11.04_evon1020v
>: >
>: > Hmm, I have this keyboard problem as well but my bridge is:
>: >
>: > cbb0: at device 4.0 on pci0
>: > cbb1: at device 4.1 on pci0
>: >
>: > I'm going to try disabling the func_intr() functions to see if that makes
>: > my keyboard happier.
>:
>: Yes. this has helped immensely. My keyboard now works again after
>: reboot and key repeat now works again. I just disabled both of
>: the enable and disable func_intr functions.
>
> I have no clue what you are talking about here...
Index: pccbb.c
===
RCS file: /usr/cvs/src/sys/dev/pccbb/pccbb.c,v
retrieving revision 1.96
diff -u -r1.96 pccbb.c
--- pccbb.c 24 Oct 2003 07:20:13 - 1.96
+++ pccbb.c 7 Nov 2003 18:21:27 -
@@ -409,7 +409,7 @@
return (ENXIO);
}
-
+#if 0
/*
* Disable function interrupts by telling the bridge to generate IRQ1
* interrupts. These interrupts aren't really generated by the chip, since
@@ -442,6 +442,7 @@
EXCA_INTR_IRQ_NONE;
exca_putb(&sc->exca, EXCA_INTR, reg);
}
+#endif
static void
cbb_chipinit(struct cbb_softc *sc)
@@ -618,7 +619,9 @@
exca_putb(&sc->exca, EXCA_INTR, EXCA_INTR_ENABLE);
exca_putb(&sc->exca, EXCA_CSC_INTR, 0);
+#if 0
cbb_disable_func_intr(sc);
+#endif
/* close all memory and io windows */
pci_write_config(sc->dev, CBBR_MEMBASE0, 0x, 4);
@@ -915,7 +918,9 @@
ih->arg = arg;
ih->flags = flags & INTR_MPSAFE;
STAILQ_INSERT_TAIL(&sc->intr_handlers, ih, entries);
+#if 0
cbb_enable_func_intr(sc);
+#endif
/*
* XXX need to turn on ISA interrupts, if we ever support them, but
* XXX for now that's all we need to do.
@@ -1137,7 +1142,9 @@
mtx_lock(&sc->mtx);
cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD);
sc->flags &= ~CBB_CARD_OK;
+#if 0
cbb_disable_func_intr(sc);
+#endif
DPRINTF(("Waking up thread\n"));
cv_signal(&sc->cv);
mtx_unlock(&sc->mtx);
The keyboard uses IRQ 1. Disabling using IRQ 1 for the CSC interrupt
fixes several problems I've had recently with my laptop's keyboard (such
as key repeat not working at all, the keyboard typically not working even
in the BIOS after a warm reboot, etc.)
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM-Problem
On Fri, 2003-11-07 at 14:12, Ralf Folkerts wrote: > Hi Erik and Scott, > > > The agpmessage, however, is something I haven't seen or heard about > before. > > What does dmesg| grep agp say? > > the Board uses an Intel Chipset; here's the dmesg | grep agp... > > agp0: mem 0xd800-0xd9ff > > at device 0.0 on pci0 > > (This is w/o starting X after boot ;-)) > > Btw: I'm also running Linux (Gentoo) on that box (dual-boot). However > Gentoo's DRM just works fine... > > Any hints are welcome; however, as I also have a 4.9 box running STABLE I > can just live with that Problem :D > > _ralf_ > > > Do you happen to force it to AGP 4x? or 1x? or don't even try? ie. Options "AGPMode" "4" in XF86Config ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM-Problem
On 07-Nov-2003 Eric Anholt wrote: > On Fri, 2003-11-07 at 13:23, Ralf Folkerts wrote: >> Hi, >> >> I have a Problem with DRM (Radeon) on my "Current"-Box. >> >> I cvsuped and made my last buildworld/-kernel/installkernel/-world last week >> (Oct 31). >> >> FreeBSD penguin.home.folkerts-net.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri >> Oct 31 20:04:27 CET 2003 >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PENGUINKERNEL i386 >> >> >From this List I think this Problem should have been fixed a while ago?! >> >> When starting X I get >> >> agp0: binding memory at bad offset 0 >> error: [drm:pid704:radeon_cp_init] *ERROR* radeon_cp_init called without >> lock held >> error: [drm:pid704:radeon_unlock] *ERROR* Process 704 using kernel context 0 >> >> on the Console. When I then shutdown X and start it up again I don't get any >> display any >> longer (however, the machine still works and i.e. can be shutdown -r now, >> but w/o seing >> anything until the reboot). >> >> Pls note: Except for these Problems (Lock when restarting X and no DRM) X >> runs nice and w/o >> any other Problems! >> >> Does anyone have a hint? Did I shred my Config(s)? Or is this a real >> Problem? > > Linux users have also been experiencing those *ERROR* messages. I'm not > sure what's going on here. I don't think the hangs are related to the > error, since Linux people haven't been complaining about hangs. The agp > message, however, is something I haven't seen or heard about before. > What does dmesg| grep agp say? We get that message all the time if we have AGPSize set in XF86Config to a size bigger than the actual GART size set in the BIOS. For example, if the GART is set to 64 and AGPSize is set to 128. The fact that X can't read the GART size from /dev/agpart automatically is really annoying by the way. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
On 07-Nov-2003 Jens Rehsack wrote: > Lars Eggert wrote: >> John Baldwin wrote: >> >>> On 07-Nov-2003 Lars Eggert wrote: >>> Jens Rehsack wrote: > interrupt total rate > irq1: atkbd0 512 2 > irq8: rtc 23419127 > irq13: npx01 0 > irq14: ata0 4422 24 > irq15: ata1 82 0 > irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... >>> >>> >>> Really. Does this only happen with ACPI enabled? >> >> Don't know about "only", since I have never booted this machine without >> ACPI. I'll test next time I'm rebooting. > > Don't do it. I do it for testing a few minutes ago - and it > prevents irq 16 from storming. But it does because the machine > hangs at boot with: > isa_probe_children: probing PnP devices > > I let it probe for about 10 minutes (you'll never know :-)), > but it wont do. Grrr, ok. Can you try the patch at http://www.FreeBSD.org/~jhb/patches/io_apic.patch and nab a boot -v dmesg with ACPI enabled? Thanks. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: small regression in cbb and a confusion with rl driver
In message: <[EMAIL PROTECTED]> John Baldwin <[EMAIL PROTECTED]> writes: : : On 07-Nov-2003 John Baldwin wrote: : > : > On 07-Nov-2003 Sven Petai wrote: : >> hi : >> : >> I upgraded my laptop (compaq Evo n1020V) from 5.1 beta to recent current few : >> days ago. I noticed two regressions and hunted down commits that introduced : >> them : >> : >> the first one is that my keyboard doesn't respond before single user mode if I : >> reboot fBSD, so I can't break into loader.. it works fine when doing cold : >> boot though. : >> this bug is introduced by the version 1.86 of the file : >> src/sys/dev/pccbb/pccbb.c : >> my cbb is recognized as : >> cbb0: mem 0xffbfe000-0xffbfefff irq 10 at device : >> 10.0 on pci0 : >> cbb0: Found memory at ffbfe000 : >> full dmesg is available @ : >> http://bsd.ee/~hadara/dump/dmesg.2003.11.04_evon1020v : > : > Hmm, I have this keyboard problem as well but my bridge is: : > : > cbb0: at device 4.0 on pci0 : > cbb1: at device 4.1 on pci0 : > : > I'm going to try disabling the func_intr() functions to see if that makes : > my keyboard happier. : : Yes. this has helped immensely. My keyboard now works again after : reboot and key repeat now works again. I just disabled both of : the enable and disable func_intr functions. I have no clue what you are talking about here... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM-Problem
Hi Erik and Scott, > The agpmessage, however, is something I haven't seen or heard about before. > What does dmesg| grep agp say? the Board uses an Intel Chipset; here's the dmesg | grep agp... agp0: mem 0xd800-0xd9ff at device 0.0 on pci0 (This is w/o starting X after boot ;-)) Btw: I'm also running Linux (Gentoo) on that box (dual-boot). However Gentoo's DRM just works fine... Any hints are welcome; however, as I also have a 4.9 box running STABLE I can just live with that Problem :D _ralf_ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM-Problem
On Fri, 2003-11-07 at 13:23, Ralf Folkerts wrote: > Hi, > > I have a Problem with DRM (Radeon) on my "Current"-Box. > > I cvsuped and made my last buildworld/-kernel/installkernel/-world last week > (Oct 31). > > FreeBSD penguin.home.folkerts-net.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri > Oct 31 20:04:27 CET 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PENGUINKERNEL i386 > > >From this List I think this Problem should have been fixed a while ago?! > > When starting X I get > > agp0: binding memory at bad offset 0 > error: [drm:pid704:radeon_cp_init] *ERROR* radeon_cp_init called without > lock held > error: [drm:pid704:radeon_unlock] *ERROR* Process 704 using kernel context 0 > > on the Console. When I then shutdown X and start it up again I don't get any > display any > longer (however, the machine still works and i.e. can be shutdown -r now, > but w/o seing > anything until the reboot). > > Pls note: Except for these Problems (Lock when restarting X and no DRM) X > runs nice and w/o > any other Problems! > > Does anyone have a hint? Did I shred my Config(s)? Or is this a real > Problem? > > Thanks, > _ralf_ Sounds like a problem with your AGPGART possibly. What AGP Gart would you be using? Intel? Via? ALI? SiS? NVidia? Please god don't tell me Nvidia. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
Lars Eggert wrote: John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about "only", since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Don't do it. I do it for testing a few minutes ago - and it prevents irq 16 from storming. But it does because the machine hangs at boot with: isa_probe_children: probing PnP devices I let it probe for about 10 minutes (you'll never know :-)), but it wont do. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM-Problem
On Fri, 2003-11-07 at 13:23, Ralf Folkerts wrote: > Hi, > > I have a Problem with DRM (Radeon) on my "Current"-Box. > > I cvsuped and made my last buildworld/-kernel/installkernel/-world last week > (Oct 31). > > FreeBSD penguin.home.folkerts-net.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri > Oct 31 20:04:27 CET 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PENGUINKERNEL i386 > > >From this List I think this Problem should have been fixed a while ago?! > > When starting X I get > > agp0: binding memory at bad offset 0 > error: [drm:pid704:radeon_cp_init] *ERROR* radeon_cp_init called without > lock held > error: [drm:pid704:radeon_unlock] *ERROR* Process 704 using kernel context 0 > > on the Console. When I then shutdown X and start it up again I don't get any > display any > longer (however, the machine still works and i.e. can be shutdown -r now, > but w/o seing > anything until the reboot). > > Pls note: Except for these Problems (Lock when restarting X and no DRM) X > runs nice and w/o > any other Problems! > > Does anyone have a hint? Did I shred my Config(s)? Or is this a real > Problem? Linux users have also been experiencing those *ERROR* messages. I'm not sure what's going on here. I don't think the hangs are related to the error, since Linux people haven't been complaining about hangs. The agp message, however, is something I haven't seen or heard about before. What does dmesg| grep agp say? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too many uncorrectable read errors with atang
On Fri, Nov 07, 2003 at 07:33:41PM +0100, Soren Schmidt wrote: > > 1) All my drives have performed mass suicide at once > > You know, with deathstar's you cant really rule that out :) :-) > > Furthermore, I'd like to know why the panic occurred above. > > Is this on a brand new -current ? lots of things that could > cause this has been fixed... Yes, it was updated last night. Kris pgp0.pgp Description: PGP signature
Re: savecore changed?
- Original Message - From: "Doug White" <[EMAIL PROTECTED]> To: "Jaco H. van Tonder" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 07/11/2003 11:28 PM Subject: Re: savecore changed? > On Fri, 7 Nov 2003, Jaco H. van Tonder wrote: > > > Doug, > > > > Sorry, my bad, there was no dump availible. I still dont know how I > > would manage to get a dump if the kernel panics while busy booting (It > > does not know about dumpdev yet?) > > Ouch. Yeah this is one of those times when you can't grab a dump. You can > compile DDB in and at least poke around. > > You do have a listing of the panic & boot messages up to the point of the > panic, yes? If not this would be a good time to learn about serial > console. I will investigate serial console, but I do have physical access to the machine, and I do have a monitor on it, but it reboots so quickly, its just a flash of the panic, and the system reboots. :( I cannot make out a thing exept for "12" which I assume is part of ``Fatal trap 12'' - something. I do have DDB compiled in, but I will leave the ``poking around'' for the hackers. :P Jaco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about "only", since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: savecore changed?
On Fri, 7 Nov 2003, Jaco H. van Tonder wrote: > Doug, > > Sorry, my bad, there was no dump availible. I still dont know how I > would manage to get a dump if the kernel panics while busy booting (It > does not know about dumpdev yet?) Ouch. Yeah this is one of those times when you can't grab a dump. You can compile DDB in and at least poke around. You do have a listing of the panic & boot messages up to the point of the panic, yes? If not this would be a good time to learn about serial console. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex in ip_output.c
Sam Leffler wrote: > On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: > > On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: > > > I have a Dell 4150 laptop using dhcp and ntpd on the > > > xl0 interface. I did "ifconfig xl0 down" and received > > > the following panic (hand transcribed :-( ). > > > > > > panic: mtx_lock() of spin mutex (null) @ > > > /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: > > > backtrace() > > > panic() > > > panic: process 414(ntpd):2 Giant but isn't blocked on a mutex > > > > > Make sure you have rev 1.250 of ip_input.c. > Okay. I'll update my source tree. This panic occurred for sources circa 31 Oct 03. I'm going to be offline for the next week, so I won't be able to pursue this until then. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Radeon DRM-Problem
Hi, I have a Problem with DRM (Radeon) on my "Current"-Box. I cvsuped and made my last buildworld/-kernel/installkernel/-world last week (Oct 31). FreeBSD penguin.home.folkerts-net.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Oct 31 20:04:27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PENGUINKERNEL i386 >From this List I think this Problem should have been fixed a while ago?! When starting X I get agp0: binding memory at bad offset 0 error: [drm:pid704:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:pid704:radeon_unlock] *ERROR* Process 704 using kernel context 0 on the Console. When I then shutdown X and start it up again I don't get any display any longer (however, the machine still works and i.e. can be shutdown -r now, but w/o seing anything until the reboot). Pls note: Except for these Problems (Lock when restarting X and no DRM) X runs nice and w/o any other Problems! Does anyone have a hint? Did I shred my Config(s)? Or is this a real Problem? Thanks, _ralf_ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex in ip_output.c
On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: > On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: > > I have a Dell 4150 laptop using dhcp and ntpd on the > > xl0 interface. I did "ifconfig xl0 down" and received > > the following panic (hand transcribed :-( ). > > > > panic: mtx_lock() of spin mutex (null) @ > > /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: > > backtrace() > > panic() > > panic: process 414(ntpd):2 Giant but isn't blocked on a mutex > > > > In ddb> I get, > > > > Debugger() > > panic() > > propagate_priority() > > _mtx_lock_sleep() > > _mtx_lock_flags() > > softclock() > > ithread_loop() > > fork_exit() > > fork_trampoline() > > > > I have a crash dump and kernel.debug if further info is need Make sure you have rev 1.250 of ip_input.c. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
On 07-Nov-2003 Lars Eggert wrote: > Jens Rehsack wrote: >> interrupt total rate >> irq1: atkbd0 512 2 >> irq8: rtc 23419127 >> irq13: npx01 0 >> irq14: ata0 4422 24 >> irq15: ata1 82 0 >> irq16: uhci0 uhci3 5379815 29238 > > This looks similar to what I described in the "fwohci0 running wild" > thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... But I cannot unload the uhci driver, 'cause I need my mouse when using X. Ok, it would work even without, but I think then will I become the bottleneck, not irq 16 ;-) Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex in ip_output.c
On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote:
> I have a Dell 4150 laptop using dhcp and ntpd on the
> xl0 interface. I did "ifconfig xl0 down" and received
> the following panic (hand transcribed :-( ).
>
> panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
> Stack backtrace:
> backtrace()
> panic()
> panic: process 414(ntpd):2 Giant but isn't blocked on a mutex
>
> In ddb> I get,
>
> Debugger()
> panic()
> propagate_priority()
> _mtx_lock_sleep()
> _mtx_lock_flags()
> softclock()
> ithread_loop()
> fork_exit()
> fork_trampoline()
>
> I have a crash dump and kernel.debug if further info is need
>
See the gdb -k trace below for further details. Note,
for some unknown reason, I issued a "panic" command at
the ddb> prompt instead of calling dodump directly, so
I think the dump I have below is not the actually trace
we need.
--
Steve
Script started on Fri Nov 7 11:40:42 2003
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd"...
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
panic messages:
---
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
Stack backtrace:
panic: process 414(ntpd):2 holds Giant but isn't blocked on a mutex
panic: from debugger
Uptime: 1m32s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/vesa/vesa.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/vesa/vesa.ko.debug
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_ich.ko...done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/agp/agp.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/agp/agp.ko.debug
Reading symbols from /boot/kernel/radeon.ko...done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04fc14c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04fc4d7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc043cf42 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc043cea2 in db_command (last_cmdp=0xc068a6c0, cmd_table=0x0,
aux_cmd_tablep=0xc065db30, aux_cmd_tablep_end=0xc065db34)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc043cfe5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc043ffe5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc05fd3ac in kdb_trap (type=3, code=0, regs=0xd77cabb0)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc060e20a in trap (frame=
{tf_fs = 24, tf_es = -1066794992, tf_ds = -679739376, tf_edi = 0, tf_esi =
-1067168428, tf_ebp = -679695364, tf_isp = -679695396, tf_ebx = 0, tf_edx = 0, tf_ecx
= 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067461020, tf_cs = 8,
tf_eflags = 662, tf_esp = -1067090437, tf_ss = -1067165548})
at /usr/src/sys/i386/i386/trap.c:582
#9 0xc05fed98 in calltrap () at {standard input}:102
#10 0xc04fc465 in panic (
fmt=0xc0644d54 "process %d(%s):%d holds %s but isn't blocked on a mutex\n")
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc04f23d1 in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:166
#12 0xc04f2b19 in _mtx_lock_sleep (m=0xc069dc80, opts=0,
---Type to continue, or q to quit---
file=0xc0646935 "/usr/src/sys/kern/kern_timeout.c", line=216)
at /usr/src/sys/kern/kern_mutex.c:635
#13 0xc04f2567 in _mtx_lock_flags (m=0xc069dc80, opts=0,
file=0xc0646935 "/usr/src/sys/kern/kern_timeout.c", line=216)
at /usr/src/sys/kern/kern_mutex.c:333
#14 0xc050c9c4 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:216
#15 0xc04e8332 in ithread_loop (arg=0xc1d16d00)
at /usr/src/sys/kern/kern_intr.c:540
#16 0xc04e7334 in fork
Re: burncd block size
On Fri, 7 Nov 2003 10:28:42 +0100 (CET), Soren Schmidt <[EMAIL PROTECTED]> wrote: It seems Jeremy Messenger wrote: On Fri, 07 Nov 2003 10:10:40 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > I've been having a variety of problems burning CDs with atang: > > - burncd consistently failing in exactly the same spot in the ISO, >and reporting "only wrote 0 of 32768 bytes: Unknown error: 0" > > - burncd failing right at the start with "only wrote -1 of 32768 >bytes: Input/output error" (this generally happens after a couple >of the previous, and once it starts happening I have to reboot) Whew, glad that I am not only one.. I *just* have wasted two of my blank CD in like fifteen minutes ago, I keep wondering if I created the ISO files in the wrong way or was it burncd's fault.. Until now here.. This is fallout from getting atapi-cd under GEOM. GEOM wasn't designed to handle medias of size 0 and where the sizes can change during an open. I just committed a fix that has solved the issue here (and its ugly). It's fixed, now I am able to burn it full on CD. I get the new messages (see bottom) when it boot, but it seems to be harmless since I can use anything and work ok. Does this messages mean I need to give the SCSI_DELAY more time? == Nov 7 13:21:43 mezz kernel: acd0: CDRW at ata0-master PIO4 Nov 7 13:21:43 mezz kernel: Waiting 5 seconds for SCSI devices to settle Nov 7 13:21:43 mezz kernel: GEOM: create disk cd0 dp=0xc2e44e00 Nov 7 13:21:43 mezz kernel: GEOM: create disk da0 dp=0xc2e36450 Nov 7 13:21:43 mezz kernel: da0 at ahc0 bus 0 target 0 lun 0 Nov 7 13:21:43 mezz kernel: da0: Fixed Direct Access SCSI-3 device Nov 7 13:21:43 mezz kernel: da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled Nov 7 13:21:43 mezz kernel: da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Recovered Sense Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): NOT READY asc:3a,0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Medium not present Nov 7 13:21:43 mezz kernel: cd0 at ata0 bus 0 target 0 lun 0 Nov 7 13:21:43 mezz kernel: cd0: Removable CD-ROM SCSI-0 device Nov 7 13:21:43 mezz kernel: cd0: 16.000MB/s transfers Nov 7 13:21:43 mezz kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Recovered Sense Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): NOT READY asc:3a,0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Medium not present Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Recovered Sense Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): NOT READY asc:3a,0 Nov 7 13:21:43 mezz kernel: (cd0:ata0:0:0:0): Medium not present Nov 7 13:21:43 mezz kernel: Mounting root from ufs:/dev/da0s1a == Cheers, Mezz -Søren -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
RE: small regression in cbb and a confusion with rl driver
On 07-Nov-2003 John Baldwin wrote: > > On 07-Nov-2003 Sven Petai wrote: >> hi >> >> I upgraded my laptop (compaq Evo n1020V) from 5.1 beta to recent current few >> days ago. I noticed two regressions and hunted down commits that introduced >> them >> >> the first one is that my keyboard doesn't respond before single user mode if I >> reboot fBSD, so I can't break into loader.. it works fine when doing cold >> boot though. >> this bug is introduced by the version 1.86 of the file >> src/sys/dev/pccbb/pccbb.c >> my cbb is recognized as >> cbb0: mem 0xffbfe000-0xffbfefff irq 10 at device >> 10.0 on pci0 >> cbb0: Found memory at ffbfe000 >> full dmesg is available @ >> http://bsd.ee/~hadara/dump/dmesg.2003.11.04_evon1020v > > Hmm, I have this keyboard problem as well but my bridge is: > > cbb0: at device 4.0 on pci0 > cbb1: at device 4.1 on pci0 > > I'm going to try disabling the func_intr() functions to see if that makes > my keyboard happier. Yes. this has helped immensely. My keyboard now works again after reboot and key repeat now works again. I just disabled both of the enable and disable func_intr functions. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt code slows hyperthreading down
John Baldwin wrote:
On 07-Nov-2003 Jens Rehsack wrote:
Hi,
I recompiled my system today and when it came up again,
it was terrible slow. Using top I've seen, that there're
around 25% cpu-time is used to handle interrupts.
The kernel was configured using SMP ('cause it's a HTT
enabled CPU) and APIC. Setting machdep.hlt_logical_cpus
to 1 didn't change anything. Simply getting a few mails
(around 30) takes about 20 minutes. Most of time while
getting the mails my mozilla was in "*Giant" state,
what shouldn't be good, should it?
I've recompiled the kernel without SMP and APIC and
now the system's behaviour is more "normal". Is the
behaviour of the new interrupt code better on real
multiprocessor systems?
Can you do a 'vmstat -i' under your SMP kernel to see where
all the interrupts are coming from? It sounds like a device
is interrupt storming. There has been report of this so far
with fwohci(4).
It's attached as well as the dmesg output booting with -v.
Jens
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Fri Nov 7 10:12:42 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER
Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc087f000.
Calibrating clock(s) ... i8254 clock: 1193211 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2398854804 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.85-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
Features=0xbfebfbff
Hyperthreading: 2 logical CPUs
real memory = 1072889856 (1023 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00c29000 - 0x3ed0afff, 1041113088 bytes (254178 pages)
avail memory = 1032667136 (984 MB)
ACPI APIC Table:
APIC ID: physical 0, logical 0:0
APIC ID: physical 1, logical 0:1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
bios32: Found BIOS32 Service Directory header at 0xc00f
bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xf+0x31
pnpbios: Found PnP BIOS data at 0xc00f5580
pnpbios: Entry = f:616a Rev = 1.0
Other BIOS signatures found:
MADT: Found IO APIC ID 2, Vector 0 at 0xfec0
ioapic0: intpin 0 -> ExtINT
ioapic0: intpin 1 -> irq 1
ioapic0: intpin 2 -> irq 2
ioapic0: intpin 3 -> irq 3
ioapic0: intpin 4 -> irq 4
ioapic0: intpin 5 -> irq 5
ioapic0: intpin 6 -> irq 6
ioapic0: intpin 7 -> irq 7
ioapic0: intpin 8 -> irq 8
ioapic0: intpin 9 -> irq 9
ioapic0: intpin 10 -> irq 10
ioapic0: intpin 11 -> irq 11
ioapic0: intpin 12 -> irq 12
ioapic0: intpin 13 -> irq 13
ioapic0: intpin 14 -> irq 14
ioapic0: intpin 15 -> irq 15
ioapic0: intpin 16 -> irq 16
ioapic0: intpin 17 -> irq 17
ioapic0: intpin 18 -> irq 18
ioapic0: intpin 19 -> irq 19
ioapic0: intpin 20 -> irq 20
ioapic0: intpin 21 -> irq 21
ioapic0: intpin 22 -> irq 22
ioapic0: intpin 23 -> irq 23
MADT: intr override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
ioapic0: intpin 2 trigger: edge
ioapic0: intpin 2 polarity: active-hi
MADT: intr override: source 9, irq 9
ioapic0: intpin 9 trigger: level
ioapic0: intpin 9 polarity: active-hi
ioapic0 irqs 0-23 on motherboard
cpu0 BSP:
ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff
lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
random:
mem:
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 03 43 57 00 c0 01 00 00 00 cd 52
00 c0 00 02 04 01 58 57 00 c0 5f 57 00 c0 6b 57
00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
VESA: 23 mode(s) found
VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd)
VESA: Matrox Graphics Inc.
VESA: Matrox Matrox G550 00
null:
acpi0: on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a): mode1res=0x8000 (0x8000)
pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25708086)
pcibios: BIOS version 2.10
Using $PIR table, 14 entries at 0xc00f5410
PCI-Only Interrupts: none
Location Bus Device Pin Link IRQs
embedded28A 0x68 3 4 5 6 7 10 11 12 14 15
embedded0 31A 0x62 3 4 5 6 7 10 11 12 14 15
embedded0 31B 0x61 3 4 5 6 7 10 11 12 14 15
embedded0 29A 0x60 3 4 5 6 7 10 11 12 14 15
embedded0 29B 0x63 3 4 5 6 7 10 11 12 14 15
embedded0 29C 0x62 3 4 5 6 7 10 11 12 14 15
embedded0 29D 0x6b 3 4 5 6 7 10 11 12 14 15
embedded01A 0x60 3 4 5 6 7 10 11 12 14 15
embedded01B 0x61 3 4 5 6 7 10 11 12 14 15
embedded03A 0x60 3 4 5 6
Re: Too many uncorrectable read errors with atang
If you are running -CURRENT, you can check the SMART status of the drives with the port sysutils/smartmontools. If the drive supports > ATA-3 commands, you should be able to see if there are errors being reported by the drive itself. Ed On Fri, 2003-11-07 at 13:33, Soren Schmidt wrote: > It seems Kris Kennaway wrote: > -- Start of PGP signed section. > > Since upgrading the bento package machines to -current I am getting > > a lot of the following errors: > > > > ad0: FAILURE - READ_DMA status=51 error=40 > > That does look like a valid error condition from the drive... > > > 1) All my drives have performed mass suicide at once > > You know, with deathstar's you cant really rule that out :) > > > 2) ATAng is detecting errors that the ATAog did not > > That is true, the error detection is better in ATAng. > > > 3) ATAng is not trying as hard as ATAog to recover from the errors > > from the crappy drives > > Neither ATAog nor ATAnr retried uncorrectable errors... > > > 4) ATAng has a bug on this hardware. > > That we cant rule out, and it probably likely.. > > > Furthermore, I'd like to know why the panic occurred above. > > Is this on a brand new -current ? lots of things that could > cause this has been fixed... > > -Søren > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Eduard Martinescu <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck: CANNOT SEEK BLK: -1 (after changing the mainboard)
Quoting Dag-Erling Smørgrav <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] writes: >> The quick story: after a change of the MB from a GA-7VT600 1393 >> to a GA-7VT600-L, both with VIA Apollo KT600 / 8237 cipset, my >> system's preen fsck can't find the superblock on partitions other >> that >> / As far as I can say the fs where clean (note however that / was >> mounted read-only AFAIR). > > You probably switched your disk from CHS to LBA mode or vice > versa. > > DES Unfortunatly, I don't think that is the case (and I've checked it before posting). For reference this is what my AWARD BIOS reads: Capacity 120GB Access Mode Auto CHS LBALarge Cylinder.57460.5746014593.3830 Head1616..255..240 Precomp..0.000 Landing Zone.57459.57459.57459...57459 Sector.255...25563.255 If I'm trying CHS or Large in BIOS It will not boot at all, but promting me to choose the boot partition with no luck (if I try XP it hangs or complain about missing NT..DLL) I would really apreciate any other sugestion. IOnut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: mtx_lock() of spin mutex in ip_output.c
I have a Dell 4150 laptop using dhcp and ntpd on the xl0 interface. I did "ifconfig xl0 down" and received the following panic (hand transcribed :-( ). panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: backtrace() panic() panic: process 414(ntpd):2 Giant but isn't blocked on a mutex In ddb> I get, Debugger() panic() propagate_priority() _mtx_lock_sleep() _mtx_lock_flags() softclock() ithread_loop() fork_exit() fork_trampoline() I have a crash dump and kernel.debug if further info is need -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Too many uncorrectable read errors with atang
On 07-Nov-2003 Kris Kennaway wrote: > So far this has happened (well, the panic above was new) on 5 separate > machines that were all working on older -current. Now, these are all > IBM DeathStar drives, but previously I was only experiencing ata > errors every month or two, and they were correctable for another month > or two by /dev/zero'ing the drive. > > To suddenly start receiving errors on 5 out of 7 drives in the past > few weeks is a significant anomaly. Perhaps one of the following is > happening: > > 1) All my drives have performed mass suicide at once > > 2) ATAng is detecting errors that the ATAog did not > > 3) ATAng is not trying as hard as ATAog to recover from the errors > from the crappy drives > > 4) ATAng has a bug on this hardware. 5) Interference from abnormally high solar activity. It is known to cause an increase in NMI's from ECC errors, so it could be a possible explanation here even if it's a bit far-fetched. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: New interrupt code slows hyperthreading down
On 07-Nov-2003 Jens Rehsack wrote:
> Hi,
>
> I recompiled my system today and when it came up again,
> it was terrible slow. Using top I've seen, that there're
> around 25% cpu-time is used to handle interrupts.
> The kernel was configured using SMP ('cause it's a HTT
> enabled CPU) and APIC. Setting machdep.hlt_logical_cpus
> to 1 didn't change anything. Simply getting a few mails
> (around 30) takes about 20 minutes. Most of time while
> getting the mails my mozilla was in "*Giant" state,
> what shouldn't be good, should it?
>
> I've recompiled the kernel without SMP and APIC and
> now the system's behaviour is more "normal". Is the
> behaviour of the new interrupt code better on real
> multiprocessor systems?
Can you do a 'vmstat -i' under your SMP kernel to see where
all the interrupts are coming from? It sounds like a device
is interrupt storming. There has been report of this so far
with fwohci(4).
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: small regression in cbb and a confusion with rl driver
On 07-Nov-2003 Sven Petai wrote: > hi > > I upgraded my laptop (compaq Evo n1020V) from 5.1 beta to recent current few > days ago. I noticed two regressions and hunted down commits that introduced > them > > the first one is that my keyboard doesn't respond before single user mode if I > reboot fBSD, so I can't break into loader.. it works fine when doing cold > boot though. > this bug is introduced by the version 1.86 of the file > src/sys/dev/pccbb/pccbb.c > my cbb is recognized as > cbb0: mem 0xffbfe000-0xffbfefff irq 10 at device > 10.0 on pci0 > cbb0: Found memory at ffbfe000 > full dmesg is available @ > http://bsd.ee/~hadara/dump/dmesg.2003.11.04_evon1020v Hmm, I have this keyboard problem as well but my bridge is: cbb0: at device 4.0 on pci0 cbb1: at device 4.1 on pci0 I'm going to try disabling the func_intr() functions to see if that makes my keyboard happier. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel memory leak in ATAPI/CAM or ATAng?
> Date: Fri, 07 Nov 2003 00:45:47 -0700 > From: Scott Long <[EMAIL PROTECTED]> > > Kevin Oberman wrote: > >>Date: Thu, 6 Nov 2003 11:23:30 -0500 (EST) > >>From: Robert Watson <[EMAIL PROTECTED]> > >> > >> > >>On Thu, 6 Nov 2003, Kevin Oberman wrote: > >> > >> > >>>I have learned a bit more about the problems I have been having with > >>>the DVD drive on my T30 laptop. When I have run the drive for an > >>>extended time (like 2 or 3 hours), I invariably have my system lock up > >>>because it can't malloc kernel memory for the ATAPI/CAM or ATA > >>>device. (Usually it's both.) > >>> > >>>The only recovery seems to be to reboot the system. > >> > >>Is it possible to drop to DDB and generate a coredump at that point? If > >>so, you can run vmstat on the core to look at memory use statistics in a > >>post-mortem way. As to what to look for: "big numbers" is about the limit > >>of what I can suggest, I'm afraid :-). Usually the activity of choice is > >>to compare vmstat statistics (with -m and -z) during normal operation and > >>when the leak has occurred, and look for any marked differences. It's > >>worth observing that there are two failure modes here that appear almost > >>identical: (1) a memory leak resulting in address space exhaustion for the > >>kernel, and (2) a tunable maximum allocation being too high for the > >>available address space. Note that (2) isn't a leak, simply a poorly > >>tuned value. We've noticed a number of tuned memory limits were set when > >>memory sizes on systems were much lower, and so we've had to readjust the > >>tuning parameters for large memory systems. Likewise, a number of > >>problems were observed when PAE was introduced, as some of the tuning > >>parameters scaled with the amount of physical memory, not with the > >>addressable space for the kernel. So we probably want to be on the look > >>out for both of these possibilities. > > > > > > Well, I have no details to this point, but 'vmstat -m' makes the > > problem obvious. The amount of kernel memory allocated to ATA request > > climbs forever and after enough data is transferred, it runs out of > > KVM. This is a continual leak, and monitoring it on the running system > > makes it pretty clear that something is leaking. I don't think (2) is > > the issue. Because the field allocated in vmstat are not large enough, > > this is a bit hard to read. The field all merge into some REALLY large > > numbers. After reboot, it is <5K. When running mencode I see this > > increasing at a rate of a bit under 1.9 MB per minute. > > > > It does not look like a tuning issue. No matter how big KVM is allowed > > to grow, it's only a matter of time until it is gone. > > > > I am going to do some testing to see what operations seem to causse > > this. I assume it does not happen all of the time or everyone would > > have seen it. I suspect it only happens with ATAPI/CAM activity, > > possibly only with simultaneous ATA and ATAPI/COM activity. > > Does vmstat -m show which malloc type is growing? Knowing this will > greatly speed up the debugging process. I'm not sure I follow. The leak is in "ATA request". Is there something more to be seen in "vmstat -m"? I have confirmed that it seems to happen with any reads from the DVD device, but my testing has been done with mplayer. Makes it a bit tough to watch a full-length movie! I have opened kern/59043 on the problem. Let me know if I can do further testing. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too many uncorrectable read errors with atang
It seems Kris Kennaway wrote: -- Start of PGP signed section. > Since upgrading the bento package machines to -current I am getting > a lot of the following errors: > > ad0: FAILURE - READ_DMA status=51 error=40 That does look like a valid error condition from the drive... > 1) All my drives have performed mass suicide at once You know, with deathstar's you cant really rule that out :) > 2) ATAng is detecting errors that the ATAog did not That is true, the error detection is better in ATAng. > 3) ATAng is not trying as hard as ATAog to recover from the errors > from the crappy drives Neither ATAog nor ATAnr retried uncorrectable errors... > 4) ATAng has a bug on this hardware. That we cant rule out, and it probably likely.. > Furthermore, I'd like to know why the panic occurred above. Is this on a brand new -current ? lots of things that could cause this has been fixed... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wireless laptop card revisited
I am having the same problem that was discussed a couple months ago with an Avaya gold card giving the "busy bit won't clear" on boot up when using DHCP. If I manually configure it everything works ok. The fix that was given before was to update the firmware. I have searched everywhere for the firware with no luck. I may have missed it, but all I found were windows updates. I even got my hands on a windows laptop and tried to update it, which looked succesful, but when I put the card back into the laptop it showed the old firware number. I called avaya and they said there is no way (even if I had windows) to update the firmware... How exactly did others on this list get thier card working? Thanks! k. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Too many uncorrectable read errors with atang
Since upgrading the bento package machines to -current I am getting
a lot of the following errors:
ad0: FAILURE - READ_DMA status=51 error=40
For example:
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: FAILURE - READ_DMA status=51 error=40
ad0: TIMEOUT - READ_DMA retrying (2 retries left)
ata0: resetting devices ..
ad0: FAILURE - already active DMA on this device
ad0: setting up DMA failed
panic: initiate_write_inodeblock_ufs2: already started
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0739e72,c07ac4a0,c074d9d0,d897b7a4,100) at Debugger+0x54
panic(c074d9d0,c058d793,d897b7cc,c058d72b,c07af7e0) at panic+0xd5
initiate_write_inodeblock_ufs2(c54c8780,cec0f1e8,1,c5a88400,c46f2b40) at
initiate_write_inodeblock_ufs2+0x6e6
softdep_disk_io_initiation(cec0f1e8,c073916a,167,1,fcf58000) at
softdep_disk_io_initiation+0x8d
spec_xstrategy(c4ed3b68,cec0f1e8,c13e6720,c4e791bc,200200a0) at spec_xstrategy+0x117
spec_specstrategy(d897b8ec,d897b914,c05adbf4,d897b8ec,1) at spec_specstrategy+0x72
spec_vnoperate(d897b8ec,1,c073ff9e,360,0) at spec_vnoperate+0x18
bwrite(cec0f1e8,cec0f1e8,1,8000,0) at bwrite+0x424
ffs_update(c5aab490,1,d897b9b0,c058d72b,c07af880) at ffs_update+0x31b
ffs_truncate(c5aab490,0,0,c00,0) at ffs_truncate+0x8d8
ufs_inactive(d897bbfc,d897bc18,c05c1a13,d897bbfc,0) at ufs_inactive+0x10c
ufs_vnoperate(d897bbfc,0,c074185c,8d3,c07953a0) at ufs_vnoperate+0x18
vput(c5aab490,825d2,0,d897bc38,c074185c) at vput+0x143
handle_workitem_remove(c5b40a20,0,2,c07afa88,c4e63800) at handle_workitem_remove+0x1d1
process_worklist_item(0,0,3faba10a,0,d897bcf0) at process_worklist_item+0x19e
softdep_process_worklist(0,0,c074185c,6e0,0) at softdep_process_worklist+0xe0
sched_sync(0,d897bd48,c0737724,311,aaf2e368) at sched_sync+0x384
fork_exit(c05c0770,0,d897bd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd897bd7c, ebp = 0 ---
db>
So far this has happened (well, the panic above was new) on 5 separate
machines that were all working on older -current. Now, these are all
IBM DeathStar drives, but previously I was only experiencing ata
errors every month or two, and they were correctable for another month
or two by /dev/zero'ing the drive.
To suddenly start receiving errors on 5 out of 7 drives in the past
few weeks is a significant anomaly. Perhaps one of the following is
happening:
1) All my drives have performed mass suicide at once
2) ATAng is detecting errors that the ATAog did not
3) ATAng is not trying as hard as ATAog to recover from the errors
from the crappy drives
4) ATAng has a bug on this hardware.
Furthermore, I'd like to know why the panic occurred above.
Following is an excerpt from boot -v:
atapci0: port 0xffa0-0xffaf at device 31.1 on pci0
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00
ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00
ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
[...]
ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin
ad0: setting UDMA66 on Intel ICH chip
GEOM: create disk ad0 dp=0xc47a4070
ad0: ATA-5 disk at ata0-master
ad0: 29314MB (60036480 sectors), 59560 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, UDMA66
GEOM: new disk ad0
GEOM: Configure ad0b, start 0 length 1073741824 end 1073741823
GEOM: Configure ad0c, start 0 length 30738677760 end 30738677759
GEOM: Configure ad0e, start 1073741824 length 2147483648 end 3221225471
GEOM: Configure ad0f, start 3221225472 length 27517452288 end 30738677759
Kris
pgp0.pgp
Description: PGP signature
Re: [CURRENT] Panic in -CURRENT of 20031105
On Friday 07 November 2003 07:49 am, Jaco H. van Tonder wrote: > Hi All, > > I get panics at random times of the day with -CURRENT from 20031105, with > absolutely no load on the machine. > > The machine acts as a dial-up server/gateway/firewall for my local lan. I > managed to get a coredump. > > The contents of the rt pointer passed to RTFREE() does really not look > right to me. These in particular: > rt_llinfo = 0xc0f95880 "\220ǼÁ\200qùÀ" > rn_Key = 0xc1bcc7a0 "0AùÀ8AùÀ" > > Anyone got any ideas? This looks like the problem I fixed yesterday. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: since 2 days apm / ACPI doesn't work and boot instabilities
It's borked in 4.9 as well. I just had to downgrade a bunch of Servers to 4.8 :( Lanny On Fri, 2003-11-07 at 11:07, Andreas Klemm wrote: > Hi, > > wanted to let you know, that since yesterday ACPI on my > Dell Latitude D600 doesn't work anymore. > > Does anybody have an idea what this breakage might have caused ? > > About a week ago I got apm/acpi working with an unoff patch from this URL. > > http://sandcat.nl/~stijn/freebsd/dell.php > > I didn't changed anything in: > /etc/rc.conf > /boot/loader.conf > and nothing in the kernel config file. > > I only did a "make world" as well as a new kernel and rebooted. > > Another thing is, that sometimes I can only boot 1 of 3 times > without a kernel panic. This morning 2 or 3 consecutive panics, > prior being able to boot my laptop. > > The problem with apm/acpi is since my last make world yesterday. > > The boot problems with many panics are longer ... > > But its always the same process, where it panics... > > In my next mail I'll attach a boot log. > > I could offer ssh access, if somebody would be willed trying to > troubleshoot one or both of these problems. > > A comconsole would also be possible. > > BTW, -current on my Server is stable. Its only the laptop, > where those panics happen. > > > Andreas /// -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Lanny Baron Proud to be 100% FreeBSD http://www.FreeBSDsystems.COM =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: since 2 days apm / ACPI doesn't work and boot instabilities
On Fri, Nov 07, 2003 at 11:28:19AM -0500, Ken Menzel wrote: > Hi Andreas, > I bet acpi isn't even running. As of a few days ago acpi is disabled > as a loadable module due to some changes in progress. Try adding > 'device acpi' to your kernel.conf file and rebuild/reinstall the > kernel. > > Ken On Fri, Nov 07, 2003 at 05:31:02PM +0100, Richard Arends wrote: > On Fri, 7 Nov 2003, Andreas Klemm wrote: > > > wanted to let you know, that since yesterday ACPI on my > > Dell Latitude D600 doesn't work anymore. > > /usr/src/UPDATING > > 20031103: > The i386 APIC_IO kernel option has been replaced by > 'device apic'. The ACPI module has also been temporarily > disabled, so ACPI must be statically compiled into your > kernel using 'device acpi' if you wish to use the ACPI driver. > > Regards, > > Richard. Thanks, Ken, Richard will try that ! BTW, who has currently the pointy hat ? I could need it now ;-) So if you don't need it no longer, give it to me with a colorful sticker on it: "read UPDATING" ;-) Sorry, completely forgot about that and didn't think about how quickly things can change in the wonderful -current land ;-) O.k., but the pancis might stay, so I will "ring" again and offer a developer account if necessary. Regards Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: since 2 days apm / ACPI doesn't work and boot instabilities
Hi Andreas, I bet acpi isn't even running. As of a few days ago acpi is disabled as a loadable module due to some changes in progress. Try adding 'device acpi' to your kernel.conf file and rebuild/reinstall the kernel. Ken - Original Message - From: "Andreas Klemm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 07, 2003 11:07 AM Subject: since 2 days apm / ACPI doesn't work and boot instabilities > Hi, > > wanted to let you know, that since yesterday ACPI on my > Dell Latitude D600 doesn't work anymore. > > Does anybody have an idea what this breakage might have caused ? > > About a week ago I got apm/acpi working with an unoff patch from this URL. > > http://sandcat.nl/~stijn/freebsd/dell.php > > I didn't changed anything in: > /etc/rc.conf > /boot/loader.conf > and nothing in the kernel config file. > > I only did a "make world" as well as a new kernel and rebooted. > > Another thing is, that sometimes I can only boot 1 of 3 times > without a kernel panic. This morning 2 or 3 consecutive panics, > prior being able to boot my laptop. > > The problem with apm/acpi is since my last make world yesterday. > > The boot problems with many panics are longer ... > > But its always the same process, where it panics... > > In my next mail I'll attach a boot log. > > I could offer ssh access, if somebody would be willed trying to > troubleshoot one or both of these problems. > > A comconsole would also be possible. > > BTW, -current on my Server is stable. Its only the laptop, > where those panics happen. > > > Andreas /// > > -- > Andreas Klemm - Powered by FreeBSD 5.1-CURRENT > Need a magic printfilter today ? -> http://www.apsfilter.org/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: since 2 days apm / ACPI doesn't work and boot instabilities
On Fri, 7 Nov 2003, Andreas Klemm wrote: > wanted to let you know, that since yesterday ACPI on my > Dell Latitude D600 doesn't work anymore. /usr/src/UPDATING 20031103: The i386 APIC_IO kernel option has been replaced by 'device apic'. The ACPI module has also been temporarily disabled, so ACPI must be statically compiled into your kernel using 'device acpi' if you wish to use the ACPI driver. Regards, Richard. Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
since 2 days apm / ACPI doesn't work and boot instabilities
Hi, wanted to let you know, that since yesterday ACPI on my Dell Latitude D600 doesn't work anymore. Does anybody have an idea what this breakage might have caused ? About a week ago I got apm/acpi working with an unoff patch from this URL. http://sandcat.nl/~stijn/freebsd/dell.php I didn't changed anything in: /etc/rc.conf /boot/loader.conf and nothing in the kernel config file. I only did a "make world" as well as a new kernel and rebooted. Another thing is, that sometimes I can only boot 1 of 3 times without a kernel panic. This morning 2 or 3 consecutive panics, prior being able to boot my laptop. The problem with apm/acpi is since my last make world yesterday. The boot problems with many panics are longer ... But its always the same process, where it panics... In my next mail I'll attach a boot log. I could offer ssh access, if somebody would be willed trying to troubleshoot one or both of these problems. A comconsole would also be possible. BTW, -current on my Server is stable. Its only the laptop, where those panics happen. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: savecore changed?
Doug, Sorry, my bad, there was no dump availible. I still dont know how I would manage to get a dump if the kernel panics while busy booting (It does not know about dumpdev yet?) Regards, Jaco - Original Message - From: "Doug White" <[EMAIL PROTECTED]> To: "Jaco H. van Tonder" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 07/11/2003 3:06 AM Subject: Re: savecore changed? > On Thu, 6 Nov 2003, Jaco H. van Tonder wrote: > > > Hi all, > > > > I have a -CURRENT kernel that panics the moment it starts booting, and I > > have to use another kernel to boot properly (GENERIC). The problem is that I > > want to dump the core from the faulty kernel, and I see that savecore no > > longer support a -N flag like in 4.X? How do I save the core in -CURRENT > > from a different kernel? UPDATING does not mention any change in savecore. > > :( > > savecore won't recover the old kernel? Can't say I've ever had that > problem. Can you show error messages? -CURRENT savecore no longer grabs > kernel.0, so it shouldn't matter what the running kernel is. > > -- > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New interrupt code slows hyperthreading down
Hi,
I recompiled my system today and when it came up again,
it was terrible slow. Using top I've seen, that there're
around 25% cpu-time is used to handle interrupts.
The kernel was configured using SMP ('cause it's a HTT
enabled CPU) and APIC. Setting machdep.hlt_logical_cpus
to 1 didn't change anything. Simply getting a few mails
(around 30) takes about 20 minutes. Most of time while
getting the mails my mozilla was in "*Giant" state,
what shouldn't be good, should it?
I've recompiled the kernel without SMP and APIC and
now the system's behaviour is more "normal". Is the
behaviour of the new interrupt code better on real
multiprocessor systems?
Regards,
--
Jens Rehsack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[CURRENT] Panic in -CURRENT of 20031105
Hi All, I get panics at random times of the day with -CURRENT from 20031105, with absolutely no load on the machine. The machine acts as a dial-up server/gateway/firewall for my local lan. I managed to get a coredump. The contents of the rt pointer passed to RTFREE() does really not look right to me. These in particular: rt_llinfo = 0xc0f95880 "\220ǼÁ\200qùÀ" rn_Key = 0xc1bcc7a0 "0AùÀ8AùÀ" Anyone got any ideas? Thanks Jaco firewall# uname -a FreeBSD firewall.symphiano 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Nov 7 15:31:34 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWALL i386 firewall# dmesg Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Fri Nov 7 15:31:34 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWALL Preloaded elf kernel "/boot/kernel/kernel" at 0xc06cf000. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 134217728 (128 MB) avail memory = 124952576 (119 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fded0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:8 INTA BIOS irq 11 pci_cfgintr: 0:10 INTA BIOS irq 10 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci_cfgintr: 0:1 INTA routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xe800-0xe87f mem 0xdf80-0xdf80007f irq 11 at device 8.0 on pci0 xl0: Ethernet address: 00:50:da:45:92:81 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 10.0 (no driver attached) orm0: at iomem 0xc8000-0xc87ff,0xc-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppi0: on ppbus0 sc0: 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: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 501139304 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 1000 packets/entry by default GEOM: create disk ad0 dp=0xc1c48370 ad0: 2014MB [4092/16/63] at ata0-master UDMA33 acd0: CDROM at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted firewall# cat /usr/src/sys/i386/conf/FIREWALL machine i386 cpu I686_CPU ident FIREWALL maxusers0 options SCHED_4BSD #4BSD scheduler options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 #optionsSCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SC
Issues with disk layout (different from -stable)?
I'm trying to bring up -current on my new IBM ThinkPad T40. Once I specified hw.pci.allow_unsupported_io_range, the snapshot CD booted up cleanly. The current problem: Sysinstall claims the disk layout as provided by BIOS is bogus (it's something like 10/32/32). It provides its own, newfs works clean, but writes fail on the 1st package read from CD. I tried another alternative layout (the drive is a IBM/Hitachi Travelstar 80GN) but get the same result. As an experiment, I booted from a 4.8 CD, and it just accepted the provided layout and installed without any problems. Thanks in advance, Jeff Katcher __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
small regression in cbb and a confusion with rl driver
hi I upgraded my laptop (compaq Evo n1020V) from 5.1 beta to recent current few days ago. I noticed two regressions and hunted down commits that introduced them the first one is that my keyboard doesn't respond before single user mode if I reboot fBSD, so I can't break into loader.. it works fine when doing cold boot though. this bug is introduced by the version 1.86 of the file src/sys/dev/pccbb/pccbb.c my cbb is recognized as cbb0: mem 0xffbfe000-0xffbfefff irq 10 at device 10.0 on pci0 cbb0: Found memory at ffbfe000 full dmesg is available @ http://bsd.ee/~hadara/dump/dmesg.2003.11.04_evon1020v the second regression seemed to be the fact that my built in network card that uses realtek chip wasn't found anymore by rl driver but it turned out to be not a regression after all. After doing exhaustive binary search I traced it down to commit that separated support for 8139C+ into re driver. Wouldn't it be nice if it were mentioned in the UPDATING file too so everyone doesn't have to find it out the hard way :-) ? OTOH it seems to be very rare chip and probably only 2-3 fBSD users have it anyway so why bother... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New interrupt stuff breaks ASUS 2 CPU system
On Fri, 7 Nov 2003, Stefan [iso-8859-1] Eßer wrote: > On 2003-11-07 20:04 +1100, Bruce Evans <[EMAIL PROTECTED]> wrote: > > However, using the apic almost doubles the overheads for the a45 cases. > > This seems to be due to extra interrupts. The UART and/or driver already > > Just another data point: > > Seems that the interrupt rate doubled for drm0 on my system > (from 60 to 120 driving a LCD at 60Hz vertical refresh). > > I thought this might be a problem with shared interrupts (drm0 > and xl0 shared APIC IRQ 16), but removing the (actually unused) > xl driver did not make a difference ... Hmm. My a45 UARTs are the only ones with a pci level triggered interrupt: Nov 7 01:48:44 gamplex kernel: ioapic0: Routing IRQ 5 -> intpin 19 Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 5 disabled Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 19 trigger: level Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 19 polarity: active-lo There is only one other level triggered interrupt the system that is used: Nov 7 01:48:44 gamplex kernel: ioapic0: Routing IRQ 11 -> intpin 18 Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 11 disabled Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 18 trigger: level Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 18 polarity: active-lo and I suspect it may be doing strange things too: I found that rev.1.23 of ata_lowlevel.c broke atapicam, but the new interrupt code magically fixed it. One of the atapicam devices is the only device on IRQ11. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the PS/2 mouse problem
On Fri, 7 Nov 2003, Morten Johansen wrote:
> Morten Johansen wrote:
> > Scott Long wrote:
> >
> >> One thought that I had was to make psmintr() be INTR_FAST. I need to
> >> stare at the code some more to fully understand it, but it looks like it
> >> wouldn't be all that hard to do. Basically just use the interrupt
> >> handler
> >> to pull all of the data out of the hardware and into a ring buffer in
> >> memory, and then a fast taskqueue to process that ring buffer. It would
> >> at least answer the question of whether the observed problems are due to
> >> ithread latency. And if done right, no locks would be needed in
> >> psmintr().
However, it is usually easier to use a lock even if not strictly necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
> > I can reproduce the problem consistently on my machine, by moving the
> > mouse around, while executing e.g this command in a xterm:
> >
> > dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
> >
> > when the sync'ing sets in the mouse attacks.
> > It is very likely due to interrupt latency.
> >
> > I'd be happy to test any clever patches.
>
> Wow. You are completly right!
> By using a MTX_SPIN mutex instead, and marking the interrupt handler
> INTR_MPSAFE | INTR_FAST, my problem goes away.
> I am no longer able to reproduce the mouse attack.
> I have not noticed any side-effects of this. Could there be any?
> I will file a PR with an updated patch, unless you think it's a better
> idea to rearrange the driver.
> Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler, starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc->kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers. In general, fast interrupt handlers may not call
any functions, since the "any" function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard subsystem).
- it calls other functions. The closure of all these calls must be examined
and made fast-interrupt-handler safe before this is safe. The lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually private
psm data that mainly points to PSMPORT. Then there is no problem with the
data accesses. But the function calls make it unclear who owns the data.)
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt handlers
are not permitted to busy-wait.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE. This is nontrival, however.
Fine grained locking gaves many of the complications that were only
in fast interrupt handlers in RELENG_4. E.g., for psmintr() to be MPSAFE,
all of its calls into the keyboard subsystem need to be MPSAFE, and they
are unlikely to be so unless the keyboard subsystem is made MPSAFE.
The following method can be used to avoid some of the complications:
make the interrupt handler not touch much data, so that it can be
locked easily. The data should be little more than a ring buffer.
Make the handler either INTR_MPSAFE or INTR_FAST (it doesn't matter
for slow devices like psm). Put all the rest of what was in the
interrupt handler in non-MPSAFE code (except where it accesses data
shared with the interrupt handler) so that all of this code and its
closure doesn't need to be made MPSAFE. This method is what the sio
driver uses in -current, sort of accident
Re: fsck: CANNOT SEEK BLK: -1 (after changing the mainboard)
[EMAIL PROTECTED] writes: > The quick story: after a change of the MB from a GA-7VT600 1393 > to a GA-7VT600-L, both with VIA Apollo KT600 / 8237 cipset, my > system's preen fsck can't find the superblock on partitions other that > / As far as I can say the fs where clean (note however that / was > mounted read-only AFAIR). You probably switched your disk from CHS to LBA mode or vice versa. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: New interrupt stuff breaks ASUS 2 CPU system
On Thu, 6 Nov 2003, John Baldwin wrote: JB> JB>On 06-Nov-2003 Harti Brandt wrote: JB>> JB>I figured out what is happenning I think. You are getting a spurious JB>> JB>interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JB>> JB>lists pending interrupts still waiting to be serviced. Try using JB>> JB>'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JB>> JB>the spurious IRQ 7 interrupts go away. JB>> JB>> Ok, that seems to help. Interesting although why do these interrupts JB>> happen only with a larger HZ and when the kernel is doing printfs (this JB>> machine has a serial console). I have also not tried to disable SIO2 and JB>> the parallel port. JB> JB>Can you also try turning mixed mode back on and using JB>http://www.FreeBSD.org/~jhb/patches/spurious.patch JB> JB>You should get some stray IRQ 7's in the vmstat -i output as well as a few JB>printf's to the kernel console. Now I'm getting the same 'Couldn't get vector from ISR!' as before on Xapic_isr1. Again ISR1 is 0 and IRR1 is 0x100. Here is some data: db> trace Debugger(c05ea5f4,0,c05fa63b,c0821b5c,100) at Debugger+0x55 panic(c05fa63b,c0821b6c,c062ab80,c0821bb4,c05ab57d) at panic+0x156 lapic_handle_intr() at lapic_handle_intr+0x1b Xapic_isr1() at Xapic_isr1+0x3d --- interrupt, eip = 0xc04bbbfd, esp = 0xc0821bb0, ebp = 0xc0821bb4 --- critical_exit(c0821bf4,c059af49,c0638100,0,c05f7a08) at critical_exit+0x2d _mtx_unlock_spin_flags(c0638100,0,c05f7a08,c88,c0821bec) at _mtx_unlock_spin_flags+0x23 siocnputc(c061e8e0,a,5,c0821d10,a) at siocnputc+0xe9 cnputc(a,2060d900,1,0,c05eec77) at cnputc+0x7a putchar(a,c0821d10,1,0,0) at putchar+0x6c kvprintf(c05eec76,c04d46b0,c0821d10,a,c0821d30) at kvprintf+0x8d printf(c05eec76,0,,0,c05c6e20) at printf+0x57 tc_init(c0622c60,c0821d78,c05c7b8f,8,8) at tc_init+0xc4 init_TSC_tc(8,8,c05c6e20,0,a0) at init_TSC_tc+0x91 cpu_initclocks(c0821d98,c0490ac5,0,81e000,81ec00) at cpu_initclocks+0x11f initclocks(0,81e000,81ec00,81e000,0) at initclocks+0x8 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> x *lapic+0x110 0xd78f8110: 0 db> x *lapic+0x210 0xd78f8210: 100 IRQ7 is the parallel port according to dmesg. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd block size
On Fri, 7 Nov 2003 10:28:42 +0100 (CET), Soren Schmidt <[EMAIL PROTECTED]> wrote: It seems Jeremy Messenger wrote: On Fri, 07 Nov 2003 10:10:40 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > I've been having a variety of problems burning CDs with atang: > > - burncd consistently failing in exactly the same spot in the ISO, >and reporting "only wrote 0 of 32768 bytes: Unknown error: 0" > > - burncd failing right at the start with "only wrote -1 of 32768 >bytes: Input/output error" (this generally happens after a couple >of the previous, and once it starts happening I have to reboot) Whew, glad that I am not only one.. I *just* have wasted two of my blank CD in like fifteen minutes ago, I keep wondering if I created the ISO files in the wrong way or was it burncd's fault.. Until now here.. This is fallout from getting atapi-cd under GEOM. GEOM wasn't designed to handle medias of size 0 and where the sizes can change during an open. I just committed a fix that has solved the issue here (and its ugly). Thanks! /me goes to update his -CURRENT... Cheers, Mezz -Søren -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd block size
It seems Jeremy Messenger wrote: > On Fri, 07 Nov 2003 10:10:40 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > > I've been having a variety of problems burning CDs with atang: > > > > - burncd consistently failing in exactly the same spot in the ISO, > >and reporting "only wrote 0 of 32768 bytes: Unknown error: 0" > > > > - burncd failing right at the start with "only wrote -1 of 32768 > >bytes: Input/output error" (this generally happens after a couple > >of the previous, and once it starts happening I have to reboot) > > Whew, glad that I am not only one.. I *just* have wasted two of my blank > CD in like fifteen minutes ago, I keep wondering if I created the ISO > files in the wrong way or was it burncd's fault.. Until now here.. This is fallout from getting atapi-cd under GEOM. GEOM wasn't designed to handle medias of size 0 and where the sizes can change during an open. I just committed a fix that has solved the issue here (and its ugly). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd block size
On Fri, 07 Nov 2003 10:10:40 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: I've been having a variety of problems burning CDs with atang: - burncd consistently failing in exactly the same spot in the ISO, and reporting "only wrote 0 of 32768 bytes: Unknown error: 0" - burncd failing right at the start with "only wrote -1 of 32768 bytes: Input/output error" (this generally happens after a couple of the previous, and once it starts happening I have to reboot) Whew, glad that I am not only one.. I *just* have wasted two of my blank CD in like fifteen minutes ago, I keep wondering if I created the ISO files in the wrong way or was it burncd's fault.. Until now here.. I get like this: = # burncd -f /dev/acd0 -e -s 6 data NT2004.iso fixate next writeable LBA 0 writing from file NT2004.iso size 662576 KB written this track 410656 KB (61%) total 410656 KB only wrote 4096 of 32768 bytes: Unknown error: 0 fixating CD, please wait.. = I tried the another ISO and I get the same thing by stopped at 32768 bytes. I am going to use cdrecord for now, hope it will work ok. Cheers, Mezz - burncd getting stuck in acdcld for a long time while fixating - a *lot* of "sensekey=ILLEGAL REQUEST error=4"; fixating a CD causes about half a dozen TEST_UNIT_READY failures, and I occasionally get READ_BIG, START_STOP, PREVENT_ALLOW and SET_SPEED failures as well, all of them with "status=51 sensekey=ILLEGAL REQUEST error=4" I've discovered that reducing the buffer size in burncd fixes at least the first problem, and possibly the second, but not the third. I've attached a patch that adds a command-line option for that (the default will still be 16 blocks at a time, but you can specify anything from 1 to 64 on the command line) The drive is an LG 8400B with which I've previously had little or no trouble; prior to atang, it burned CDs just fine at 40x with a failure rate of precisely 0. # dmesg | grep acd acd0: CDRW at ata1-master WDMA2 # atacontrol info ata1 Master: acd0 ATA/ATAPI rev 0 Slave: no device present # atacontrol cap ata1 0 ATA channel 1, Master, device acd0: ATA/ATAPI revision0 device model HL-DT-ST GCE-8400B serial number firmware revision 1.00 cylinders 0 heads 0 sectors/track 0 lba supported lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheno no read ahead no no dma queued no no 0/0x00 SMART no no microcode download no no security no no power management no no advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 DES -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: current panics
Hi, On Thu, Nov 06, 2003 at 01:42:30PM +0100, Soren Schmidt wrote: > Dunno, but I get it as well when I set interrupt mode to APIC in > the BIOS, if I choose PIC it works (but without an APIC of course). I had the same situation as you. But jhb@ fixed it already. -Kirill pgp0.pgp Description: PGP signature
burncd block size
I've been having a variety of problems burning CDs with atang:
- burncd consistently failing in exactly the same spot in the ISO,
and reporting "only wrote 0 of 32768 bytes: Unknown error: 0"
- burncd failing right at the start with "only wrote -1 of 32768
bytes: Input/output error" (this generally happens after a couple
of the previous, and once it starts happening I have to reboot)
- burncd getting stuck in acdcld for a long time while fixating
- a *lot* of "sensekey=ILLEGAL REQUEST error=4"; fixating a
CD causes about half a dozen TEST_UNIT_READY failures, and I
occasionally get READ_BIG, START_STOP, PREVENT_ALLOW and SET_SPEED
failures as well, all of them with "status=51
sensekey=ILLEGAL REQUEST error=4"
I've discovered that reducing the buffer size in burncd fixes at least
the first problem, and possibly the second, but not the third. I've
attached a patch that adds a command-line option for that (the default
will still be 16 blocks at a time, but you can specify anything from 1
to 64 on the command line)
The drive is an LG 8400B with which I've previously had little or no
trouble; prior to atang, it burned CDs just fine at 40x with a failure
rate of precisely 0.
# dmesg | grep acd
acd0: CDRW at ata1-master WDMA2
# atacontrol info ata1
Master: acd0 ATA/ATAPI rev 0
Slave: no device present
# atacontrol cap ata1 0
ATA channel 1, Master, device acd0:
ATA/ATAPI revision0
device model HL-DT-ST GCE-8400B
serial number
firmware revision 1.00
cylinders 0
heads 0
sectors/track 0
lba supported
lba48 not supported
dma supported
overlap not supported
Feature Support EnableValue Vendor
write cacheno no
read ahead no no
dma queued no no 0/0x00
SMART no no
microcode download no no
security no no
power management no no
advanced power management no no 0/0x00
automatic acoustic management no no 0/0x00 0/0x00
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
Index: burncd.c
===
RCS file: /home/ncvs/src/usr.sbin/burncd/burncd.c,v
retrieving revision 1.37
diff -u -r1.37 burncd.c
--- burncd.c 26 Jul 2003 12:14:58 - 1.37
+++ burncd.c 6 Nov 2003 22:01:00 -
@@ -45,7 +45,8 @@
#include
#include
-#define BLOCKS 16
+#define DEFAULT_BLOCKS 16
+#define MAX_BLOCKS 64
struct track_info {
int file;
@@ -58,6 +59,7 @@
};
static struct track_info tracks[100];
static int global_fd_for_cleanup, quiet, verbose, saved_block_size, notracks;
+static int blocks = DEFAULT_BLOCKS;
void add_track(char *, int, int, int);
void do_DAO(int fd, int, int);
@@ -81,8 +83,15 @@
if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";
- while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
+ while ((ch = getopt(argc, argv, "b:def:Flmnpqs:tv")) != -1) {
switch (ch) {
+ case 'b':
+ blocks = atoi(optarg);
+ if (blocks < 0)
+blocks = 1;
+ if (blocks > MAX_BLOCKS)
+blocks = MAX_BLOCKS;
+ break;
case 'd':
dao = 1;
break;
@@ -94,7 +103,7 @@
case 'f':
dev = optarg;
break;
-
+
case 'F':
force = 1;
break;
@@ -136,7 +145,7 @@
verbose = 1;
break;
- default:
+ default:
usage();
}
}
@@ -149,11 +158,11 @@
if ((fd = open(dev, O_RDWR, 0)) < 0)
err(EX_NOINPUT, "open(%s)", dev);
- if (ioctl(fd, CDRIOCGETBLOCKSIZE, &saved_block_size) < 0)
- err(EX_IOERR, "ioctl(CDRIOCGETBLOCKSIZE)");
+ if (ioctl(fd, CDRIOCGETBLOCKSIZE, &saved_block_size) < 0)
+ err(EX_IOERR, "ioctl(CDRIOCGETBLOCKSIZE)");
- if (ioctl(fd, CDRIOCWRITESPEED, &speed) < 0)
- err(EX_IOERR, "ioctl(CDRIOCWRITESPEED)");
+ if (ioctl(fd, CDRIOCWRITESPEED, &speed) < 0)
+ err(EX_IOERR, "ioctl(CDRIOCWRITESPEED)");
global_fd_for_cleanup = fd;
err_set_exit(cleanup);
@@ -164,26 +173,26 @@
break;
}
if (!strcasecmp(argv[arg], "msinfo")) {
- struct ioc_read_toc_single_entry entry;
+ struct ioc_read_toc_single_entry entry;
struct ioc_toc_header header;
- if (ioctl(fd, CDIOREADTOCHEADER, &header) < 0)
+ if (ioctl(fd, CDIOREADTOCHEADER, &header) < 0)
err(EX_IOERR, "ioctl(CDIOREADTOCHEADER)");
bzero(&entry, sizeof(struct ioc_read_toc_single_entry));
entry.address_format = CD_LBA_FORMAT;
entry.track = header.ending_track;
- if (ioctl(fd, CDIOREADTOCENTRY, &entry) < 0)
+ if (ioctl(fd, CDIOREADTOCENTRY, &entry) < 0)
err(EX_IOERR, "ioctl(CDIOREADTOCENTRY)");
- if (ioctl(fd, CDRIOCNEXTWRITEABLEADDR, &addr) < 0)
+ if (ioctl(fd, CDRIOCNEXTWRITEABLEADDR, &addr) < 0)
err(EX_IOERR, "ioctl(CDRIOCNEXTWRITEABLEADDR)");
- fprintf(stdout, "%d,%d\n",
+ fprintf(stdout, "%d,%d\n",
ntohl(entry.entry.addr.lba), addr);
break;
}
i
RE: New interrupt stuff breaks ASUS 2 CPU system
On Thu, 6 Nov 2003, John Baldwin wrote: > On 06-Nov-2003 Harti Brandt wrote: > > JB>I figured out what is happenning I think. You are getting a spurious > > JB>interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register > > JB>lists pending interrupts still waiting to be serviced. Try using > > JB>'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if > > JB>the spurious IRQ 7 interrupts go away. > > > > Ok, that seems to help. Interesting although why do these interrupts > > happen only with a larger HZ and when the kernel is doing printfs (this > > machine has a serial console). I have also not tried to disable SIO2 and > > the parallel port. > > Can you also try turning mixed mode back on and using > http://www.FreeBSD.org/~jhb/patches/spurious.patch > > You should get some stray IRQ 7's in the vmstat -i output as well as a few > printf's to the kernel console. Other changes fixed the problem with the apic case not working on my BP6, except the apic causes many more interrupts on serial ports at 921600 bps, almost enough to overload the system with just 2 active serial ports. I've now gathered lots of statistics for sio interrupt performance. The bad effect of the apic on performance is shown in the "-current(apic)" lines for a45 and a45b only: %%% Keywords: c04 = send at 115200 bps on cuac00, receive at 115200 bps on cuac04 c04b = like c04 plus send and receive in other direction too (b = bidirectional) (cuac* are on a Cyclades 8yo (2 * cd1400 isa)) a01 = like c04 except use ports cuaa[01] a01b = like a01 except bidirectional (cuaa[01] are standard motherboard 16550 clones) a45 = like a01 except use speed 921600 bps and ports cuaa[45] a45b = like a45 except bidirectional (cuaa[45] are on a VScom 200HV2 (2 * 16950 pci)) -current(ointr) = -current before new interrupt code -current = plain current (2003/11/06) -current(apic) = -current with apic configured for UP kernel on SMP hardware -current(bde) = my version of -current (new interrupt code not merged yet) &+iir,+stream,+intr0 = my version of -current with variants of sio optimizations (only UART-independent ones; optimizations for 16950 UARTs give factor of 2 reduction in overheads) Overheads for doing above I/O in percent (min-max for 3 runs) on an ABIT BP6 with 366 MHz and 400 MHz Celerons: Devices OS UP SMP --- -- -- --- c04 RELENG_4(4.9) 6.58-6.59 Not measured (method problems) -current(ointr) 9.65-9.76 6.77-7.11 -current10.64-10.69 6.09-6.36 -current(apic) 9.63-9.90 As above (apic standard) -current(bde) 6.83-6.96 3.54-3.78 c04bRELENG_4(4.9) 12.83-12.90 Not measured (method problems) -current(ointr) 19.42-19.44 13.70-13.90 -current20.23-20.24 12.01-12.48 -current(apic) 17.77-17.89 As above (apic standard) -current(bde) 12.74-13.23 6.23-6.53 a01 RELENG_4(4.9) 7.50-7.50 Not measured (method problems) -current(ointr) 7.67-7.69 4.44-4.77 -current8.09-8.13 4.72-5.60 -current(apic) 7.75-8.02 As above (apic standard) -current(bde) 7.53-7.63 4.49-4.54 &+iir 7.09-7.30 Not measured (kernel problems) &+stream6.23-6.24 &+iir+stream5.47-5.52 &+intr0+iir 5.24-5.26 2.75-2.91 a01bRELENG_4(4.9) 14.64-14.84 Not measured (method problems) -current(ointr) 14.36-15.10 8.65-8.92 -current14.79-14.87 8.18-9.77 -current(apic) 14.80-14.91 As above (apic standard) -current(bde) 14.19-14.24 8.13-8.46 &+iir 14.05-14.13 &+stream12.12-12.17 &+iir+stream10.58-10.62 &+intr0+iir 10.07-10.12 5.10-5.63 a45 RELENG_4(4.9) 21.81-21.86 Not measured (method problems) -current(ointr) 24.00-24.04 13.3 -current25.13-25.20 31.4-31.5(86) -current(apic) 51.02-51.05(87) As above (apic standard) -current(bde) 21.83-22.02 10.71-10.89 &+iir 21.98-22.05 &+stream27.78-27.81 &+iir+stream22.08-22.16 &+intr0+iir 16.76-16.92 6.85-8.11 a45bRELENG_4(4.9) 46.23-46.44(87) Not measured (method problems) -current(ointr) 54.01-54.37(86) 25.2 (82/82) -current56.04-56.93(85) 70.1-70.7(80) -current(apic) 87.35-88.22(78) As above (apic standard) -current(bde) 42.06-42.12
Re: g++ problem
On Fri, Nov 07, 2003 at 09:19:53AM +0100, Christoph P. Kukulies wrote: > Clearly. :-) > I should have mentioned that it is not in the Makefile or in variables > defined through /etc/make.conf. (I was using gmake for this). It seems > to be wired somewhere else. There just aren't many possibilities here: 1) Environment 2) The makefile or something included by the makefile. g++ doesn't come up with the command line it is executed with; gmake executes g++ with the arguments specified in the makefile. Kris pgp0.pgp Description: PGP signature
Re: current panics
It seems Kirill Ponomarew wrote: > I got panic during the boot: > > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > panic: Can't find ExtINT pin to route through! > cpuid=0; > > Is it known problem ? Dunno, but I get it as well when I set interrupt mode to APIC in the BIOS, if I choose PIC it works (but without an APIC of course). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acd0: FAILURE - READ_BIG status=51
It seems Josef Karthauser wrote: -- Start of PGP signed section. > I've been getting a lot of this kind of error from my cdrom drive on a > variety of disks recently: > > acd0: FAILURE - READ_BIG status=51 sensekey=ILLEGAL REQUEST > error=1 > acd0: FAILURE - READ_BIG status=51 sensekey=ILLEGAL REQUEST > error=1 > acd0: FAILURE - READ_BIG status=51 sensekey=MEDIUM ERROR error=0 > > Is this a bug in the new atapi code or an indication of a hardware fault > that's just developed? Acutally its fallout from the hacs I had to put into atapi-cd.c to work around deficiencies in GEOM. I might have a better way now, but it needs more testing. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make install fails on 11.pm cst current cvs..
On Thu, Nov 06, 2003 at 05:00:04PM -0800, Neal Hamilton Jr. wrote: > I cvsup at 11 pm CST. It compiles fine however make installworld fails > with: > > #make installworld [...] > -- > >>> Installing everything.. > -- > cd /usr/src; make -f Makefile.inc1 install > ===> share/info > ===> include > creating osreldate.h from newvers.sh > touch: not found > *** Error code 127 > SEARCH THE ARCHIVES! SEARCH THE ARCHIVES! SEARCH THE ARCHIVES! Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: g++ problem
On Thu, Nov 06, 2003 at 11:28:28AM -0500, Alexander Kabaev wrote: > On Thu, 6 Nov 2003 16:55:00 +0100 (CET) > "C. Kukulies" <[EMAIL PROTECTED]> wrote: > > > I tried to compile a virus-scanner for Linux that allows for scanning > > Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and > > such). > > > > http://www.enyo.de/fw/software/doscan > > > > Compilation fails with the following: > > > > kukuboo2k# gmake > > g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ > > -MMD -MF src/doscan.d \ > > -c -o src/doscan.o src/doscan.cc > > In file included from src/doscan.cc:28: > > /usr/local/include/getopt.h:115: error: declaration of C function `int > > getopt() > >' conflicts with > > /usr/include/unistd.h:377: error: previous declaration `int > > getopt(int, char* > >const*, const char*)' here > > gmake: *** [src/doscan.o] Error 1 > > > > I wonder where /usr/local/include comes from. If I remove that it > > compiles smoothly. > > Uhm, from you command line? What _this_ has to do with a compiler? Clearly. :-) I should have mentioned that it is not in the Makefile or in variables defined through /etc/make.conf. (I was using gmake for this). It seems to be wired somewhere else. -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compaq Proliant 2500 - freebsd 5.1 install problems
Sounds very similar to a problem that I have with FreeBSD 5.1. As soon as /stand/sysinstall is started, the display adaptor turns off! This is on a Dell Poweredge 6350 with 4xXeon 550s. I never did get FreeBSD 5.x working on any of the 6350s that I have, but 4.8 works perfectly. Tom On Thu, 6 Nov 2003, Christer Solskogen wrote: > I`m trying to get FreeBSD 5.1 installed, but sysinstall never shows. > The last info I get is "/stand/sysinstall running as init on vty0" and it > stops. It dont do anything more. > FreeBSD 4.8(and 4.9 i guess, havent tried yet) works. > > Any sollution? > Btw, I have set the OS to be 'Other' in BIOS. > > > -- > Med vennlig hilsen / Best regards > Christer Solskogen > http://dtz.cjb.net - http://carebears.mine.nu > > "Cheap, but not as cheap as your girlfriend!" > -Spider Jerusalem > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel memory leak in ATAPI/CAM or ATAng?
Kevin Oberman wrote: Date: Thu, 6 Nov 2003 11:23:30 -0500 (EST) From: Robert Watson <[EMAIL PROTECTED]> On Thu, 6 Nov 2003, Kevin Oberman wrote: I have learned a bit more about the problems I have been having with the DVD drive on my T30 laptop. When I have run the drive for an extended time (like 2 or 3 hours), I invariably have my system lock up because it can't malloc kernel memory for the ATAPI/CAM or ATA device. (Usually it's both.) The only recovery seems to be to reboot the system. Is it possible to drop to DDB and generate a coredump at that point? If so, you can run vmstat on the core to look at memory use statistics in a post-mortem way. As to what to look for: "big numbers" is about the limit of what I can suggest, I'm afraid :-). Usually the activity of choice is to compare vmstat statistics (with -m and -z) during normal operation and when the leak has occurred, and look for any marked differences. It's worth observing that there are two failure modes here that appear almost identical: (1) a memory leak resulting in address space exhaustion for the kernel, and (2) a tunable maximum allocation being too high for the available address space. Note that (2) isn't a leak, simply a poorly tuned value. We've noticed a number of tuned memory limits were set when memory sizes on systems were much lower, and so we've had to readjust the tuning parameters for large memory systems. Likewise, a number of problems were observed when PAE was introduced, as some of the tuning parameters scaled with the amount of physical memory, not with the addressable space for the kernel. So we probably want to be on the look out for both of these possibilities. Well, I have no details to this point, but 'vmstat -m' makes the problem obvious. The amount of kernel memory allocated to ATA request climbs forever and after enough data is transferred, it runs out of KVM. This is a continual leak, and monitoring it on the running system makes it pretty clear that something is leaking. I don't think (2) is the issue. Because the field allocated in vmstat are not large enough, this is a bit hard to read. The field all merge into some REALLY large numbers. After reboot, it is <5K. When running mencode I see this increasing at a rate of a bit under 1.9 MB per minute. It does not look like a tuning issue. No matter how big KVM is allowed to grow, it's only a matter of time until it is gone. I am going to do some testing to see what operations seem to causse this. I assume it does not happen all of the time or everyone would have seen it. I suspect it only happens with ATAPI/CAM activity, possibly only with simultaneous ATA and ATAPI/COM activity. Does vmstat -m show which malloc type is growing? Knowing this will greatly speed up the debugging process. Thanks! Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
Mike Silbersack wrote: > On Wed, 5 Nov 2003, [ISO-8859-1] "Branko F. Grac(nar" wrote: > > I tried today with yesterday's -CURRENT. Same symptoms. No kernel panic, > > just lockup. > > Ok, submit a PR with clear details on how to recreate the problem, and > we'll see if someone can take a look into it. I'm too busy to look at it, > but at least putting it in a PR will ensure that it doesn't get too lost. > Once the PR is filed, you might want to try asking on the freebsd-threads > list; it sounds like the issue might be thread-related. > > (Note that your original e-mail might contain enough detail, I'm not > certain; I just skimmed it. Filing a good PR is important either way, > mailing list messages get easily lost.) Is gdb good enough in FreeBSD that you can break to the kernel debugger with GDB enabled, and dump out the stacks for all threads currently in the kernel for all processes? The way to find this, if it's a threads related issue, is to do exactly that, and then look to se if there's something like a close in one thread of an fd being used in a blocking operation in another thread. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the PS/2 mouse problem
Morten Johansen wrote: Morten Johansen wrote: Scott Long wrote: One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott I can reproduce the problem consistently on my machine, by moving the mouse around, while executing e.g this command in a xterm: dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync when the sync'ing sets in the mouse attacks. It is very likely due to interrupt latency. I'd be happy to test any clever patches. Morten Wow. You are completly right! By using a MTX_SPIN mutex instead, and marking the interrupt handler INTR_MPSAFE | INTR_FAST, my problem goes away. I am no longer able to reproduce the mouse attack. I have not noticed any side-effects of this. Could there be any? I will file a PR with an updated patch, unless you think it's a better idea to rearrange the driver. Probably the locking could be done better anyway. Morten Great! By all means, please submit a PR and assign it to me. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
