FreeBSD 7.1 on MacBook Pro: sysinstall keyboard problems
Hi, I'm trying to install FreeBSD 7.1-RELEASE/i386 on a MacBook Pro (October 2008 model) with a US international keyboard. The DVD boots fine, but once I get into sysinstall, it's like the Ctrl key is stuck. Whenever I type 'C' it actually does Ctrl+C (and exits the install), and I can't even get a dmesg from fixit because 'D' acts like Ctrl+D and logs me out. Has anyone seen this before, any ideas on how to fix this? Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IBM xSeries 336 dual Xeon hangs on boot when APIC enabled
2006/8/14, John Baldwin <[EMAIL PROTECTED]>: On Monday 14 August 2006 04:45, Arjan van Leeuwen wrote: > 2006/8/13, Michael Landin Hostbaek <[EMAIL PROTECTED]>: > > > > Arjan van Leeuwen (avleeuwen) writes: > > > I'm trying to boot FreeBSD 6.1-RELEASE/amd64 on an IBM xSeries 336 > > machine > > > with dual Xeons 3.2GHz installed. > > > > > > The installation was successful, but > > > if I try to boot the SMP kernel, it hangs after detection of SCSI and > > ATA > > > devices (possibly when doing the initialization of the mpt0 RAID > > controller, > > > or when it tries to start the second CPU?). > > > > > > > I've just had a similar problem with an IBM xSeries 232 - it would not > > boot with apic enabled.. I chased the problem down to the network > > adapter (fxp) - and when disabling the planar ethernet in BIOS it would > > boot with SMP. > > > Yes! Indeed, the system boots perfectly well if I disable both network > adapters (bge, see > dmesg.boot > posted earlier). However, I need at least one functioning network adapter... > > I managed to get both NIC and SMP working by disabling a bunch of stuff > > in the BIOS, fx both serial ports and also the floppy drive. > > > ... and this doesn't seem to work for me. > > So: > 1) Why does my system hang if I enable the network adapter? > 2) Why does it only hang if APIC is enabled? > > Arjan Compile DDB into your SMP kernel. When it 'hangs', break into ddb and run 'show intrcnt' to see if you are having an interrupt storm. I can't break into DDB during the hang, it's not responding. I can do it just before the hang, but that doesn't seem very helpful. Is there another way to force it to break? Arjan -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IBM xSeries 336 dual Xeon hangs on boot when APIC enabled
2006/8/13, Michael Landin Hostbaek <[EMAIL PROTECTED]>: Arjan van Leeuwen (avleeuwen) writes: > I'm trying to boot FreeBSD 6.1-RELEASE/amd64 on an IBM xSeries 336 machine > with dual Xeons 3.2GHz installed. > > The installation was successful, but > if I try to boot the SMP kernel, it hangs after detection of SCSI and ATA > devices (possibly when doing the initialization of the mpt0 RAID controller, > or when it tries to start the second CPU?). > I've just had a similar problem with an IBM xSeries 232 - it would not boot with apic enabled.. I chased the problem down to the network adapter (fxp) - and when disabling the planar ethernet in BIOS it would boot with SMP. Yes! Indeed, the system boots perfectly well if I disable both network adapters (bge, see dmesg.boot posted earlier). However, I need at least one functioning network adapter... I managed to get both NIC and SMP working by disabling a bunch of stuff in the BIOS, fx both serial ports and also the floppy drive. ... and this doesn't seem to work for me. So: 1) Why does my system hang if I enable the network adapter? 2) Why does it only hang if APIC is enabled? Arjan Your problem might not be related, but give it a shot ! /mich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IBM xSeries 336 dual Xeon hangs on boot when APIC enabled
I'm trying to boot FreeBSD 6.1-RELEASE/amd64 on an IBM xSeries 336 machine with dual Xeons 3.2GHz installed. The installation was successful, but if I try to boot the SMP kernel, it hangs after detection of SCSI and ATA devices (possibly when doing the initialization of the mpt0 RAID controller, or when it tries to start the second CPU?). boot -v doesn't give any error messages at that point. Disabling or enabling hyperthreading does not make a difference. Disabling the APIC allows it to boot, but gives me only one CPU. Apart from the missing CPU, everything seems to work fine. Doing a verbose boot with APIC disabled does generate a lot of these messages (practically continuously): SCSI IO Request @ 0xb3975880 Chain Offset 0x10 MsgFlags 0x00 MsgContext 0x000100f0 Bus: 0 TargetID 0 SenseBufferLength 32 LUN: 0x0 Control 0x0100 WRITE SIMPLEQ DataLength 0x4000 SenseBufAddr 0xcf4d91e0 CDB[0:10] 2a 00 00 b2 73 9f 00 00 20 00 SE32 0xb39fe030: Addr=0x4ee31000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xb39fe038: Addr=0x4eff2000 FlagsLength=0x94001000 HOST_TO_IOC LAST_ELEMENT CE32 0xb39fe040: Addr=0xcf4d9048 NxtChnO=0x0 Flgs=0x30 Len=0x10 SE32 0xb39fe048: Addr=0x4ec93000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xb39fe050: Addr=0x4edf4000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST Can this be related to the problem in any way? Attached is a dmesg from a successful boot with APIC disabled, with a note of where the boot hangs when APIC is enabled. Does anyone have experience with these machines, or hints on what to try next? Arjan dmesg.boot: Copyright (c) 1992-2006 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 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.14-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x2800 real memory = 4966055936 (4736 MB) avail memory = 4127162368 (3935 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 4.0 on pci0 pci3: on pcib2 pcib3: at device 0.0 on pci3 pci4: on pcib3 mpt0: port 0x4000-0x40ff mem 0xdeff-0xdeff,0xdefe-0xdefe irq 11 at device 1.0 on pci4 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.15.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) pcib4: at device 0.2 on pci3 pci5: on pcib4 pcib5: at device 6.0 on pci0 pci6: on pcib5 bge0: mem 0xdcff-0xdcff irq 11 at device 0.0 on pci6 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:14:5e:7e:a4:0c pcib6: at device 7.0 on pci0 pci7: on pcib6 bge1: mem 0xdaff-0xdaff irq 11 at device 0.0 on pci7 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:14:5e:7e:a4:0d pci0: at device 8.0 (no driver attached) uhci0: port 0x2200-0x221f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2600-0x261f irq 3 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf900-0xf90003ff irq 5 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 pci1: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x480-0x48f at device 31.2 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: unable to set the command byte. device_attach: atkbd0 attach returned 6 psm0: unable to set the command byte. sio0: <16550A-compa
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On 5/26/05, Matthias Buelow <[EMAIL PROTECTED]> wrote: > > >> Others don't see this though, and in other cases it was *definitively > >> proven* to be caused by the issue I mentioned. I'll have to think > >> more about what to try next..thanks for running the tests. > > > > Perhaps it's something SATA-related? > > Before restoring my 5.4 dumps after testing -current, I installed > fedora3 linux just to verify it isn't somehow the hardware itself. Ok, > plain installation from CDs, kernel "2.6.9-1.667smp" (default > installation kernel). There was absolutely zero noticable lag or any > effect on response time on X11 while untarring the same firefox source. > So there really seems to be something foul in FreeBSD in that regard. > And now for the dumps.. *sigh*. I have the same problem (and have had it for a long time) on both my dual Xeon 550MHz and Athlon XP 2000+ machines. I'm running 6-CURRENT (perhaps this thread should move to the -CURRENT list). I'm working on the dual Xeon right now, so here are some data points from that machine: - I only see it when there is heavy file activity, for example untarring firefox or untarring X. Probably because these have a lot of small files. - I do not see it when compiling world or doing other compiles - I don't have any shared irqs. - I don't have an excessive amount of interrupts, not on the USB irq nor on any other irq channels. I think I remember someone (Scott? Jeff? Don Lewis?) mentioning the problem on another mailing list, and noting that it is a problem with the filesystem that is difficult to fix. I'll try to find that post. Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic: icmp_error: bad length
My 5.3-RELEASE server just paniced with 'icmp_error: bad length". I have no possibilities to do any debugging on this machine, as it runs off a compactflash card with limited space. This could be caused by the crappy built-in Realtek cards, or maybe by something on my own network. Is there a known way to avoid this panic (or stop the error causing a panic)? Thanks, Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VIA M1000 mini-itx system installation woes - WRITE_DMA error - cabling?
On 4/26/05, W C <[EMAIL PROTECTED]> wrote: > Hi all, > > I am attempting to install 5.3-R from cd (iso image download) and > sysinstall is failing > to write the chosen (Auto Layout) filesystem to disk, the Toshiba 80G on the > primary ide channel as master. The error on vty1 is (from memory) ad0: > WRITE_DMA, error=84. > The drive is detected by BIOS as a UDMA100 device. There is nothing else on > this IDE channel, and only a cd drive on the other IDE slot. > > A search of -questions reveals this error is a UDMA mismatch, possible > caused by 80-pin cabling, and fixable with atacontrol ad0 udma33 pio bla bla > bla. However, I do not yet have a running system to run atacontrol from, as > I am installing. I have rooted around in the bios for an option to force > the drive to UDMA33 speed, to no avail. Does anyone know how I can work > around this problem and install FreeBSD to this neat little system? Do I > have bad cabling, a bad drive, or ??? Yes, I had the same problem. If this is a 2.5" drive, it probably doesn't have a 80-pins cable. Force PIO mode for the install by entering at the boot prompt (option 6 in the boot loader menu): set hw.ata.ata_dma="0" boot After you've installed the system, insert that line into /boot/loader.conf, and load up "atacontrol mode 0 udma33 udma33" as early as possible during the boot (try using /etc/rc.early, for example) to get it up to speed again. Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Even weirder hangs (was: FreeBSD 5.4-RC3 hangs on boot, 5.3 works)
This gets weirder every time I try to do something. The 5.3-RELEASE CD boots and installs a kernel that doesn't hang. If I do a binary update (with freebsd-update, '5.3-SECURITY' branch from Colin) to just after 5.3-RELEASE-p7, that kernel works too, and doesn't hang. If I use freebsd-update to get the newest kernel (after 5.3-RELEASE-p9, ifconf vulnerability), that kernel does _not_ work and hangs at the same place as the one on the 5.4-RC3 CD. So far so good - I thought that this meant that 5.3-RELEASE-p9 and newer didn't work. Now for the weird part. If I manually compile 5.3-RELEASE-p7, that does _not_ work! So, to summarize: - 5.3-RELEASE binary install works - 5.3-SECURITY binary update at the time of 5.3-RELEASE-p7 works - 5.3-RELEASE-p7 compiled manually does not work - 5.3-SECURITY binary update at the time of 5.3-RELEASE-p9 does not work I have absolutely no idea what causes these kernels to work or not work. I hope someone can help me! Arjan On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > > On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > > > I'm trying to install FreeBSD 5.4-RC3 on a Lex Neo system > > > (http://www.lex.com.tw, a small form factor PC with a 1GHz VIA C3 > > > processor). > > > > > > The system hangs when booting the kernel, at this point: > > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: VIA C3 Nehemiah+RNG+ACE (998.70-MHz 686-class CPU) > > > Origin = "CentaurHauls" Id = 0x698 Stepping = 8 > > > > > > Features=0x381b93f > > SE> > > > real memory = 125763584 (119 MB) > > > avail memory = 113414144 (108 MB) > > > npx0: [FAST] > > > > > (...) > > > > > > Booting in safe mode, turning off ACPI in the BIOS of the machine and > > > changing 'PNP OS' to yes or no in the BIOS does not help. > > > > I just tried changing hint.npx.0.flags to 0x07 and 0x01, which also > > doesn't help. > > I found something that looks like a solution for NetBSD on Google Groups here: > > http://groups.google.com/groups?threadm=41555.144.59.164.106.1105346400.squirrel%40144.59.164.106 > > where they use > > npx* at acpi? # Math coprocessor > > to force npx via the acpi table. Is something like this possible on FreeBSD? > > Arjan > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4-RC3 hangs on boot, 5.3 works
On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > > I'm trying to install FreeBSD 5.4-RC3 on a Lex Neo system > > (http://www.lex.com.tw, a small form factor PC with a 1GHz VIA C3 > > processor). > > > > The system hangs when booting the kernel, at this point: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: VIA C3 Nehemiah+RNG+ACE (998.70-MHz 686-class CPU) > > Origin = "CentaurHauls" Id = 0x698 Stepping = 8 > > > > Features=0x381b93f > SE> > > real memory = 125763584 (119 MB) > > avail memory = 113414144 (108 MB) > > npx0: [FAST] > > > (...) > > > > Booting in safe mode, turning off ACPI in the BIOS of the machine and > > changing 'PNP OS' to yes or no in the BIOS does not help. > > I just tried changing hint.npx.0.flags to 0x07 and 0x01, which also > doesn't help. I found something that looks like a solution for NetBSD on Google Groups here: http://groups.google.com/groups?threadm=41555.144.59.164.106.1105346400.squirrel%40144.59.164.106 where they use npx* at acpi? # Math coprocessor to force npx via the acpi table. Is something like this possible on FreeBSD? Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4-RC3 hangs on boot, 5.3 works
On 4/21/05, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > I'm trying to install FreeBSD 5.4-RC3 on a Lex Neo system > (http://www.lex.com.tw, a small form factor PC with a 1GHz VIA C3 > processor). > > The system hangs when booting the kernel, at this point: > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: VIA C3 Nehemiah+RNG+ACE (998.70-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x698 Stepping = 8 > > Features=0x381b93f SE> > real memory = 125763584 (119 MB) > avail memory = 113414144 (108 MB) > npx0: [FAST] > (...) > > Booting in safe mode, turning off ACPI in the BIOS of the machine and > changing 'PNP OS' to yes or no in the BIOS does not help. I just tried changing hint.npx.0.flags to 0x07 and 0x01, which also doesn't help. Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.4-RC3 hangs on boot, 5.3 works
I'm trying to install FreeBSD 5.4-RC3 on a Lex Neo system (http://www.lex.com.tw, a small form factor PC with a 1GHz VIA C3 processor). The system hangs when booting the kernel, at this point: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA C3 Nehemiah+RNG+ACE (998.70-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b93f real memory = 125763584 (119 MB) avail memory = 113414144 (108 MB) npx0: [FAST] A 5.3-RELEASE kernel boots fine however, and shows this in dmesg: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA C3 Nehemiah+RNG+ACE (998.70-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b93f real memory = 125763584 (119 MB) avail memory = 113414144 (108 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 Booting in safe mode, turning off ACPI in the BIOS of the machine and changing 'PNP OS' to yes or no in the BIOS does not help. Any ideas on what to try next? Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Timecounter problems on 5.3 - things take twice as long
Hey Doug, On Tue, 7 Dec 2004 12:57:01 -0800 (PST), Doug White <[EMAIL PROTECTED]> wrote: > On Tue, 7 Dec 2004, Arjan Van Leeuwen wrote: > > > > > In other words, exactly the same thing. I should also note that > > > > earlier versions of 5-CURRENT worked correctly (-CURRENT from june 7). > > > > Is there anything else I could try? > > > > > > Replace the motherboard? :) The i8254 hasn't changed in years, so I doubt > > > we're programming it wrong. Something along the way is applying a /2 > > > divisor. Maybe its been broken forever and you only recnetly noticed due > > > to the HZ change? > > > > Heh :). > > > > No, this is on 5.3-RELEASE and I've been running with HZ=1000 for a > > long time, because I use DUMMYNET. > > Good to know. Can you try booting an old kernel, or booting 5.2.1-R and > see if it shows up there too? If it works with 5.2.1, then I'd start > playing the binary-search game to find the commit(s) that broke you. Sorry for the late reply, I needed some time to try out older kernels. Looks like it's a hardware fault. Kernels that worked correctly in the past have the same problems if I boot them now. It probably had nothing to do with me upgrading to 5.3-RELEASE at all. Thanks for the help, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hw.ata.ata_dma="0": can I do this during bootup at the loader prompt?
On Thu, 9 Dec 2004 19:31:40 +0100, Christian Lackas <[EMAIL PROTECTED]> wrote: > * Scott Long <[EMAIL PROTECTED]> [041209 15:59]: > > Hello, > > > > It would be nice if I can set hw.ata.ata_dma="0" at the loader > > > prompt during bootup, so that the system at least will boot from > > > harddisk. Is that possible? > > Yes, that's possible. Drop the loader to the prompt and do the following: > > set hw.ata.ata_dma=0 > > boot > > btw: I have a similar problems, but not with the boot disc, but one of > my data drives, thus I want ata_dma enabled for the other discs. > > I have to dispatch a > > atacontrol mode 1 foo UDMA33 > > to set this drive (slave on second controller) to UDMA33 (otherwise it > would use UDMA100). But I have to do it before /etc/rc.d/fsck starts > accessing the device. Right now I've added above line to the beginning > of aforesaid script. > Is there a nicer/better place to tell the kernel (don't like editing the > rc-scripts). You can use /etc/rc.early for that. You'll have to create it if it doesn't yet exist. Put 'atacontrol mode 1 foo UDMA33' in it, and it should execute that command before mounting the drives. Best regards, Arjan > > Best regards > Christian > > -- > http://www.lackas.net/ > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hw.ata.ata_dma="0": can I do this during bootup at the loader prompt?
On Thu, 09 Dec 2004 21:04:19 +0900, Rob <[EMAIL PROTECTED]> wrote: > Arjan Van Leeuwen wrote: > > > > On Thu, 09 Dec 2004 14:24:35 +0900, Rob <[EMAIL PROTECTED]> wrote: > > > >>Hi, > >> > >>In /boot/loader.conf, I have > >> hw.ata.ata_dma="0" > >>to prevent a WRITE_DMA failure crash at bootup. > >>Unfortunately, this forces my UDMA100 harddisk to operate > >>at PIO4 speed. > >> > >>There are patches flying around on this mailing list that might > >>solve the problem. I'm very keen on testing such patches, but I > >>should remove the line in loader.conf. However, if the patch does > >>not work, I end up with an unbootable disk. > >> > >>It would be nice if I can set hw.ata.ata_dma="0" at the loader > >>prompt during bootup, so that the system at least will boot from > >>harddisk. Is that possible? > >> > > > > > > I'm not sure if I understand what you want, but you can use eg > > 'atacontrol mode udma33 udma33' to set your hard drive to > > UDMA-33 after the system has booted. > > No, that's no option. The situation is this: I have a harddisk with FreeBSD > 5.3, which fails to boot. It would boot if I had hw.ata.ata_dma="0" in > /boot/loader.conf; however, that file is empty, so the bootup crashes > with a WRITE_DMA failure when the kernel loads. > > I can get at the bootloader prompt during the boot. What I want to know is: > can I type something here that has the same effect as hw.ata.ata_dma="0" in > /boot/loader.conf? Then I can continue loading the kernel. Ah, ok, now I understand. > set hw.ata.ata_dma=0 > boot Arjan > > > > Thanks, > Rob. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hw.ata.ata_dma="0": can I do this during bootup at the loader prompt?
On Thu, 09 Dec 2004 14:24:35 +0900, Rob <[EMAIL PROTECTED]> wrote: > > Hi, > > In /boot/loader.conf, I have >hw.ata.ata_dma="0" > to prevent a WRITE_DMA failure crash at bootup. > Unfortunately, this forces my UDMA100 harddisk to operate > at PIO4 speed. > > There are patches flying around on this mailing list that might > solve the problem. I'm very keen on testing such patches, but I > should remove the line in loader.conf. However, if the patch does > not work, I end up with an unbootable disk. > > It would be nice if I can set hw.ata.ata_dma="0" at the loader > prompt during bootup, so that the system at least will boot from > harddisk. Is that possible? > I'm not sure if I understand what you want, but you can use eg 'atacontrol mode udma33 udma33' to set your hard drive to UDMA-33 after the system has booted. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Timecounter problems on 5.3 - things take twice as long
On Mon, 6 Dec 2004 19:07:05 -0800 (PST), Doug White <[EMAIL PROTECTED]> wrote: > On Mon, 6 Dec 2004, Arjan Van Leeuwen wrote: (...) > > The rate on 'clk' should be 1000, so it looks like your system doesn't > like HZ=1000. Try sticking this in loader.conf and rebooting: > > kern.hz="100" > > If that works then its like your motherboard has Issues(tm). I think it certainly has issues, but it's something else :). This is what happens with kern.hz=100: interrupt total rate irq1: atkbd0 2 0 irq6: fdc010 0 irq8: rtc 53803127 irq13: npx01 0 irq16: atapci0 14751 35 irq21: rl0 7180 17 irq24: fwohci0 1 0 irq28: sym0 30 0 irq29: sym1 30 0 irq31: fxp0 3236 7 irq0: clk 21016 49 Total 100060237 In other words, exactly the same thing. I should also note that earlier versions of 5-CURRENT worked correctly (-CURRENT from june 7). Is there anything else I could try? Thanks, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reproducible kernel panic
On Mon, 06 Dec 2004 15:48:02 -0800, Paul Saab <[EMAIL PROTECTED]> wrote: > Arjan Van Leeuwen wrote: > > > I had a panic that looked a lot like this (panic in swi, came up when > > > >I had some network traffic), and it's also been reported by other > >people than me. Turning of SACK seems to work for most people (at > >least it worked for me). Put net.inet.tcp.sack.enable=0 in > >/etc/sysctl.conf. > > > > > And how exactly is this supposed to help anyone fix the problem. If you > provide crashdumps then solving the problem becomes much easier, but > nothing will get fixed if you just turn it off. > Please read the original thread: http://lists.freebsd.org/mailman/htdig/freebsd-stable/2004-November/009307.html I couldn't get a crashdump on this machine, but I provided a lot of information (traces) in that thread. Since no one replied to my last post in that thread, I didn't know what else to do. But if you tell me what else you want, I'll get it for you immediately. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reproducible kernel panic
On Mon, 06 Dec 2004 13:19:54 -0800, Jeff Behl <[EMAIL PROTECTED]> wrote: > I'm getting a kernel panic every time I start getting traffic (~ 20Mb/s > total) to two squid processes. This was not happening with -RELEASE. I > upgraded on the advice that STABLE would decrease the %cpu spent in > system, which was much higher than that spent in user. The machine's > only fucntion is as a reverse proxy (2 separate squid processes to take > advante of both cpus). > > Let me know if a dump would be helpful, or if there's anything I can do > to help. > > Dual AMD Opteron system.. > > Jeff > ps. I don't believe the problem is with a zebra/ospfd kernel > interaction. the open port RST responses are expected; i can explain > why if it would provide insight into the problem... > I had a panic that looked a lot like this (panic in swi, came up when I had some network traffic), and it's also been reported by other people than me. Turning of SACK seems to work for most people (at least it worked for me). Put net.inet.tcp.sack.enable=0 in /etc/sysctl.conf. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Timecounter problems on 5.3 - things take twice as long
On Sat, 4 Dec 2004 16:14:35 -0800 (PST), Doug White <[EMAIL PROTECTED]> wrote: > On Thu, 2 Dec 2004, Arjan Van Leeuwen wrote: > > > > > Hi, > > > > I have a weird problem on a dual Xeon 550MHz system running > > 5.3-RELEASE. Everything takes twice as long as it should. > > > > Example: > > winston% time sleep 2 > > sleep 2 0.00s user 0.00s system 0% cpu 4.006 total > > > > The same for pings, the scsi delay when booting, etc. The time of the > > system itself doesn't seem to be affected (but maybe ntpd takes care > > of that). I tried changing the kern.timecounter.hardware sysctl from > > ACPI-safe to TSC and i8254, but that didn't help. > > TSC isn't available on SMP systems. Its possible one of the CPUs is > damaged, though. > > > Any other suggestions on how to fix this? Do I have to provide more > > information? > > 'vmstat -i' output would be handy. OK, here it is: interrupt total rate irq1: atkbd0 2 0 irq6: fdc010 0 irq8: rtc1140653127 irq13: npx01 0 irq16: atapci0129099 14 irq21: rl0345707 38 irq24: fwohci0 1 0 irq28: sym0 30 0 irq29: sym1 30 0 irq31: fxp0 140237 15 irq0: clk4456164499 Total6211934696 This is after 2.5 hours uptime. Thanks, Arjan > > -- > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Timecounter problems on 5.3 - things take twice as long
Hi, I have a weird problem on a dual Xeon 550MHz system running 5.3-RELEASE. Everything takes twice as long as it should. Example: winston% time sleep 2 sleep 2 0.00s user 0.00s system 0% cpu 4.006 total The same for pings, the scsi delay when booting, etc. The time of the system itself doesn't seem to be affected (but maybe ntpd takes care of that). I tried changing the kern.timecounter.hardware sysctl from ACPI-safe to TSC and i8254, but that didn't help. Any other suggestions on how to fix this? Do I have to provide more information? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
Just a small update: disabling SACK is a good workaround for this one, too. Arjan On Sat, 13 Nov 2004 21:38:31 +0100, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > On Wed, 10 Nov 2004 16:42:01 + (GMT), Robert Watson > > > <[EMAIL PROTECTED]> wrote: > > > > On Wed, 10 Nov 2004, Arjan Van Leeuwen wrote: > > > > > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > > > > with debug symbols or addr2line to convert the function+offsets in the > > > > trace to file and line number in the source? This is a NULL pointer > > > > dereference, so presumably somewhere there is a poor assumption about > > > > memory allocation or the like. > > > > > > dmesg is attached. > > > > Could you say a little about how ipfilter is being used on the box; would > > it be possible to test with it disabled? > > I've converted my ipfilter/ipnat system to ipfw/natd, and now the > problem is "solved". > > However, your patch still gives me a *lot* of icmp_error: n_spare != n > messages. I also noticed that if I ping from that system, it pings > every 2 seconds instead of every second. The clock doesn't seem to be > affected, and changing kern.timecounter.hardware doesn't change the > situation. > > Arjan > > > > > > > > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
On Wed, 10 Nov 2004 16:42:01 + (GMT), Robert Watson <[EMAIL PROTECTED]> wrote: > > On Wed, 10 Nov 2004, Arjan Van Leeuwen wrote: > > > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > > > with debug symbols or addr2line to convert the function+offsets in the > > > trace to file and line number in the source? This is a NULL pointer > > > dereference, so presumably somewhere there is a poor assumption about > > > memory allocation or the like. > > > > dmesg is attached. > > Could you say a little about how ipfilter is being used on the box; would > it be possible to test with it disabled? I've converted my ipfilter/ipnat system to ipfw/natd, and now the problem is "solved". However, your patch still gives me a *lot* of icmp_error: n_spare != n messages. I also noticed that if I ping from that system, it pings every 2 seconds instead of every second. The clock doesn't seem to be affected, and changing kern.timecounter.hardware doesn't change the situation. Arjan > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
On Wed, 10 Nov 2004 17:53:28 +0100, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > On Wed, 10 Nov 2004 16:42:01 + (GMT), Robert Watson > > > <[EMAIL PROTECTED]> wrote: > > > > On Wed, 10 Nov 2004, Arjan Van Leeuwen wrote: > > > > > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > > > > with debug symbols or addr2line to convert the function+offsets in the > > > > trace to file and line number in the source? This is a NULL pointer > > > > dereference, so presumably somewhere there is a poor assumption about > > > > memory allocation or the like. > > > > > > dmesg is attached. > > > > Could you say a little about how ipfilter is being used on the box; would > > it be possible to test with it disabled? > > Sure. It's a very standard setup; I block all traffic by default. I > allow all traffic on the internal network (fxp0), I allow outgoing > traffic on the external network (rl0), and I allow only selected ports > as incoming traffic on rl0 (ssh, http, https, some other things I > need). I can send you the ruleset privately if you want me to. > > What might be interesting is that I also have ipfw enabled (with > default to accept), because I use dummynet for traffic shaping. > > I'll compile a new kernel without ipfilter tonight, and I'll mail you > the results as soon as possible. I forgot that I have a small problem then... emule won't work correctly, because I can't redirect the incoming requests to the right ip address without ipnat. I probably can't invoke the panic at all without ipnat. Do you have any suggestions on how to test this? Arjan > > > > > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
On Wed, 10 Nov 2004 16:42:01 + (GMT), Robert Watson <[EMAIL PROTECTED]> wrote: > > On Wed, 10 Nov 2004, Arjan Van Leeuwen wrote: > > > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > > > with debug symbols or addr2line to convert the function+offsets in the > > > trace to file and line number in the source? This is a NULL pointer > > > dereference, so presumably somewhere there is a poor assumption about > > > memory allocation or the like. > > > > dmesg is attached. > > Could you say a little about how ipfilter is being used on the box; would > it be possible to test with it disabled? Sure. It's a very standard setup; I block all traffic by default. I allow all traffic on the internal network (fxp0), I allow outgoing traffic on the external network (rl0), and I allow only selected ports as incoming traffic on rl0 (ssh, http, https, some other things I need). I can send you the ruleset privately if you want me to. What might be interesting is that I also have ipfw enabled (with default to accept), because I use dummynet for traffic shaping. I'll compile a new kernel without ipfilter tonight, and I'll mail you the results as soon as possible. Arjan > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
On Wed, 10 Nov 2004 10:15:31 + (GMT), Robert Watson <[EMAIL PROTECTED]> wrote: > > Could you recompile your kernel with "options INVARIANTS"? It looks like > whatever is happening should be triggering one of the assertions in > m_copydata(), if not icmp_error(), and it would be helpful to track it a > little earlier before it faults. It looks like m_copydata() is alking off > of the end of an mbuf chain, since min()'s only pointer dereference is to > get the length out of an mbuf. However, under those circumstances it > shouldn't need to walk a chain. > > Another thing we may want to do for debugging purposes, subject to this > being something you can put the system through, is add an additional > warning in icmp_error() if the mbuf comes in fragmented. Something like > the following would generate a warning instead of panicking: > (...) I've applied the patch and enabled INVARIANTS. The result was that I did indeed see the warning once, but _not_ when I was trying to create a panic; I saw the warning shortly after starting the machine, I didn't yet start emule to get the panic. When I did start emule, I got a panic that looked a bit different. In this screenshot, you can see both the warning message (that appeared a lot earlier, independent of the panic) and the new panic: http://www.piwebs.com/freebsd/panic.jpg Here is what addr2line tells me: winston% addr2line -f -e kernel.debug.20041110 0xC074CF44 uma_dbg_free /usr/src/sys/vm/uma_dbg.c:308 winston% addr2line -f -e kernel.debug.20041110 0xC074BD13 uma_zfree_arg /usr/src/sys/vm/uma_core.c:2237 winston% addr2line -f -e kernel.debug.20041110 0xC0646C9A m_freem /usr/src/sys/vm/uma.h:302 winston% addr2line -f -e kernel.debug.20041110 0xC0460D11 fr_check /usr/src/sys/contrib/ipfilter/netinet/fil.c:1402 winston% addr2line -f -e kernel.debug.20041110 0xC0462052 fr_check_wrapper /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:344 winston% addr2line -f -e kernel.debug.20041110 0xC067F11D pfil_run_hooks /usr/src/sys/net/pfil.c:137 winston% addr2line -f -e kernel.debug.20041110 0xC069BE95 ip_input /usr/src/sys/netinet/ip_input.c:439 winston% addr2line -f -e kernel.debug.20041110 0xC067DB92 netisr_processqueue /usr/src/sys/net/netisr.c:229 winston% addr2line -f -e kernel.debug.20041110 0xC067DD76 swi_net /usr/src/sys/net/netisr.c:346 winston% addr2line -f -e kernel.debug.20041110 0xC06051C4 ithread_loop /usr/src/sys/kern/kern_intr.c:548 Thanks for your help, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
Never mind, I think I've figured it out. I hope this helps: winston# addr2line -f -e kernel.debug.20041109 0xc06544a0 m_copydata /usr/src/sys/sys/libkern.h:56 winston# addr2line -f -e kernel.debug.20041109 0xC06AF6A5 icmp_error ./machine/endian.h:171 winston# addr2line -f -e kernel.debug.20041109 0xC06B1AE9 ip_forward /usr/src/sys/netinet/ip_input.c:1879 winston# addr2line -f -e kernel.debug.20041109 0xC06B06F3 ip_input /usr/src/sys/netinet/ip_input.c:642 winston# addr2line -f -e kernel.debug.20041109 0xC06912AF netisr_processqueue /usr/src/sys/net/netisr.c:229 winston# addr2line -f -e kernel.debug.20041109 0xC06914AA swi_net /usr/src/sys/net/netisr.c:346 winston# addr2line -f -e kernel.debug.20041109 0xC060BED9 ithread_loop /usr/src/sys/kern/kern_intr.c:548 On Wed, 10 Nov 2004 01:41:21 +0100, Arjan Van Leeuwen <[EMAIL PROTECTED]> wrote: > On Tue, 9 Nov 2004 23:33:15 + (GMT), Robert Watson > <[EMAIL PROTECTED]> wrote: > > > > > > > > On Tue, 9 Nov 2004, Arjan Van Leeuwen wrote: > > > (...) > > > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > > with debug symbols or addr2line to convert the function+offsets in the > > trace to file and line number in the source? This is a NULL pointer > > dereference, so presumably somewhere there is a poor assumption about > > memory allocation or the like. > > dmesg is attached. > > # addr2line -e kernel.debug.20041109 0xc06544a0 > /usr/src/sys/sys/libkern.h:56 > > How do I get the function+offsets? > > Thanks, > > Arjan > > > > > > > Thanks, > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > > > > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 5.3, related to network traffic
On Tue, 9 Nov 2004 23:33:15 + (GMT), Robert Watson <[EMAIL PROTECTED]> wrote: > > > > On Tue, 9 Nov 2004, Arjan Van Leeuwen wrote: > (...) > > Could you send a copy of your dmesg? Could you also use gdb on a kernel > with debug symbols or addr2line to convert the function+offsets in the > trace to file and line number in the source? This is a NULL pointer > dereference, so presumably somewhere there is a poor assumption about > memory allocation or the like. dmesg is attached. # addr2line -e kernel.debug.20041109 0xc06544a0 /usr/src/sys/sys/libkern.h:56 How do I get the function+offsets? Thanks, Arjan > > Thanks, > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > dmesg Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in 5.3, related to network traffic
Hi, I updated my server at home from a -CURRENT from june 7 to 5.3-RELEASE, and now I'm seeing this panic whenever someone behind this gateway starts emule and opens a lot of connections: http://www.piwebs.com/freebsd/pagefault-network.jpg The panic doesn't occur with the -CURRENT kernel from june 7. Setting debug.mpsafenet=0 doesn't help. Does anyone have a suggestion on how to avoid this panic? The panic is very well reproduceable, so if you need more details, please tell me what to do. For now, I'll just downgrade to an older -CURRENT. Best regards, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
