Headless install with 5.X floppies not possible?
--- Doug White [EMAIL PROTECTED] wrote: On Thu, 31 Mar 2005, Rob wrote: However, I need a little advice/help: the handbook is still out-of-date for making serial console install floppies. Chapter 2.12 of the handbook talks about kern.flp and mfsroot.flp, whereas we have three floppies with 5.X install. Which one(s) of the three floppies of 5.X needs to be modified by the procedure of chapter 2.12 ? The instructions there are outdated. There aren't special floppies to activate serial console. You drop to the loader command prompt (type '6' at the beastie menu) and type set console=comconsole and you should get an OK prompt on the serial console host. I used to install 4.X on headless boxes, by creating floppies that immediately install over the serial port. Are you saying this is not possible anymore with the 5.X install floppies? Do I need the monitor at least for just typing the set-console command? Pity of that's the case, though. Rob __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Headless install with 5.X floppies not possible?
I used to install 4.X on headless boxes, by creating floppies that immediately install over the serial port. Are you saying this is not possible anymore with the 5.X install floppies? Do I need the monitor at least for just typing the set-console command? Pity of that's the case, though. I haven't tried it with 5.x, but here's how I modify the CD to allow headless installs for 4.x http://www.hempeldesigngroup.com/embedded/stories/bdgFreeBSDHeadless.html Ralph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Headless install with 5.X floppies not possible?
On Apr 2, 2005, at 09:45, Ralph Hempel wrote: I haven't tried it with 5.x, but here's how I modify the CD to allow headless installs for 4.x http://www.hempeldesigngroup.com/embedded/stories/ bdgFreeBSDHeadless.html Wouldn't is be better to simply use the -P option instead of -h? From boot(8) on my FreeBSD 4.x system: -Pprobe the keyboard. If no keyboard is found, the -D and -h options are automatically set. The following is in the BUGS section of boot(8): Due to space constraints, the keyboard probe initiated by the -P option is simply a test that the BIOS has detected an ``extended'' keyboard. If an ``XT/AT'' keyboard (with no F11 and F12 keys, etc.) is attached, the probe will fail. This way if there's a keyboard, then there's presumably a screen, so the 'regular' way of using the console will be used. If there's no keyboard then serial console will be activated. This is how Sun hardware works by default and it works quite well I find. Are there any major issues with making this the default for x86 (and amd64?) for future releases? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Headless install with 5.X floppies not possible?
David Magda wrote: On Apr 2, 2005, at 09:45, Ralph Hempel wrote: I haven't tried it with 5.x, but here's how I modify the CD to allow headless installs for 4.x http://www.hempeldesigngroup.com/embedded/stories/ bdgFreeBSDHeadless.html Wouldn't is be better to simply use the -P option instead of -h? From boot(8) on my FreeBSD 4.x system: -Pprobe the keyboard. If no keyboard is found, the -D and -h options are automatically set. snip Are there any major issues with making this the default for x86 (and amd64?) for future releases? Dave, great suggestion! I'm glad you took the time to read my little article and coment on it. It's things like this that keep the list interesting! Cheers, Ralph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4-PRERELEASE pccard problem
After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem
with my wireless card that has worked fine before.
When I insert it I get an instant panic like this:
#0 doadump () at pcpu.h:159
#1 0xc04feb42 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc04fedd8 in panic (fmt=0xc068de12 %s)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0666400 in trap_fatal (frame=0xc8333bd0, eva=4294966015)
at /usr/src/sys/i386/i386/trap.c:809
#4 0xc066616b in trap_pfault (frame=0xc8333bd0, usermode=0, eva=4294966015)
at /usr/src/sys/i386/i386/trap.c:727
#5 0xc0665dcd in trap (frame=
{tf_fs = 24, tf_es = -936181744, tf_ds = -1068433392, tf_edi =
-1052027392, tf_esi = 1, tf_ebp = -936166384, tf_isp = -936166404, tf_ebx =
-1066683360, tf_edx = -1281, tf_ecx = -1054120947, tf_eax = -335814834,
tf_trapno = 12, tf_err = 0, tf_eip = -1068110692, tf_cs = 8, tf_eflags = 66178,
tf_esp = -936166332, tf_ss = -1069088243}) at /usr/src/sys/i386/i386/trap.c:417
#6 0xc06594fa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0xc8330010 in ?? ()
#9 0xc0510010 in blst_radix_init (scan=0xfaff,
radix=-4527414809764076532, skip=-1054120915, count=Unhandled dwarf
expression opcode 0x93
)
at /usr/src/sys/kern/subr_blist.c:881
#10 0xc047020d in pccard_do_product_lookup (bus=0xc137ad00, dev=0x10282,
tab=0xc0687fe0, ent_size=32, matchfn=0)
at /usr/src/sys/dev/pccard/pccard.c:381
#11 0xc06405b8 in fdc_pccard_probe (dev=0xc14b5600) at card_if.h:194
#12 0xc05118cc in device_probe_child (dev=0x0, child=0xc14b5600)
at device_if.h:105
#13 0xc0511f35 in device_probe_and_attach (dev=0xc14b5600)
at /usr/src/sys/kern/subr_bus.c:2173
#14 0xc046fd4c in pccard_attach_card (dev=0xc137ad00)
at /usr/src/sys/dev/pccard/pccard.c:274
#15 0xc045bc0b in exca_insert (exca=0xc1338804) at card_if.h:82
#16 0xc0475ae5 in cbb_insert (sc=0xc1338800)
at /usr/src/sys/dev/pccbb/pccbb.c:537
#17 0xc0475931 in cbb_event_thread (arg=0xc1338800)
at /usr/src/sys/dev/pccbb/pccbb.c:488
#18 0xc04ea6e8 in fork_exit (callout=0xc04757ec cbb_event_thread,
arg=0xc1338800, frame=0xc8333d48) at /usr/src/sys/kern/kern_fork.c:790
#19 0xc065955c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
The dmesg of the machine:
Copyright (c) 1992-2005 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.4-PRERELEASE #23: Sat Apr 2 03:50:24 CEST 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/VULCAN
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x66a Stepping = 10
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory = 134086656 (127 MB)
avail memory = 121556992 (115 MB)
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: TOSHIB 750 on motherboard
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0
cpu0: ACPI CPU (2 Cx states) on acpi0
acpi_throttle0: ACPI CPU Throttling on cpu0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: display, VGA at device 4.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 UDMA33 controller port
0xfff0-0x,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
uhci0: Intel 82443MX USB controller port 0xff80-0xff9f irq 11 at device 7.2
on pci0
usb0: Intel 82443MX USB controller 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
pci0: bridge, PCI-unknown at device 7.3 (no driver attached)
pci0: unknown at device 9.0 (no driver attached)
cbb0: ToPIC95B PCI-CardBus Bridge irq 11 at device 11.0 on pci0
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0
pcm0: ESS Technology Maestro-2E port 0xfc00-0xfcff irq 11 at device 12.0 on
pci0
pcm0: SigmaTel STAC9721/23 AC97 Codec
pci0: simple comms at device 13.0 (no driver attached)
fxp0: Intel 82559 Pro/100 Ethernet port 0xfb40-0xfb7f mem
0xfea0-0xfeaf,0xfebff000-0xfebf irq 11 at device 14.0 on pci0
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:00:39:3e:43:16
acpi_lid0: Control Method Lid Switch on acpi0
acpi_cmbat0: Control Method Battery on acpi0
acpi_acad0: AC Adapter on acpi0
acpi_tz0: Thermal Zone on acpi0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID
5.4-PRERELEASE usb audio problem
When I plug in my Logitech USB headset I get the following: uaudio0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2 uaudio_add_selector: NOT IMPLEMENTED uaudio0: audio rev 1.00 pcm1: USB Audio on uaudio0 pcm1: chn_init(pcm1:play:0) failed: err = 19 pcm1: pcm_chn_create(ua_chan, 1, 0xc1974780) failed uhid0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2, iclass 1/1 With 5.3 and earlier it used to at least work for playback but now it seems to be completely broken. I saw a lot of commits to uaudio, including recording support. Does something need to be merged from -CURRENT for it to work properly? Thank you. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apache+mod_ssl signal 4
On Sat, 2 Apr 2005, Barney Wolff wrote: On Fri, Apr 01, 2005 at 06:59:11PM -0800, Doug White wrote: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Apr 1 11:48:45 www kernel: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Signal 4 is SIGABRT, which is a software-initiated abort. Well, no, it's ILL, indicating perhaps code compiled for a different cpu model than it's being run on, or a trashed library. oops. heh. I really need to get into the habit of checking signal(3) more often. Yeah, SIGILL would imply the library was improperly compiled. Since libcrypto will generate CPU-specific assembly based on the CPUTYPE setting, setting it to the wrong CPU type will cause Wierd Problems. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Headless install with 5.X floppies not possible?
On Sat, 2 Apr 2005, David Magda wrote: On Apr 2, 2005, at 09:45, Ralph Hempel wrote: I haven't tried it with 5.x, but here's how I modify the CD to allow headless installs for 4.x http://www.hempeldesigngroup.com/embedded/stories/ bdgFreeBSDHeadless.html Wouldn't is be better to simply use the -P option instead of -h? From boot(8) on my FreeBSD 4.x system: -Pprobe the keyboard. If no keyboard is found, the -D and -h options are automatically set. The following is in the BUGS section of boot(8): Due to space constraints, the keyboard probe initiated by the -P option is simply a test that the BIOS has detected an ``extended'' keyboard. If an ``XT/AT'' keyboard (with no F11 and F12 keys, etc.) is attached, the probe will fail. This way if there's a keyboard, then there's presumably a screen, so the 'regular' way of using the console will be used. If there's no keyboard then serial console will be activated. This is how Sun hardware works by default and it works quite well I find. Are there any major issues with making this the default for x86 (and amd64?) for future releases? May BIOSes lie and always report extended keyboards, even if there is none connected. Others lie and don't reliably set this bit. So this cannot be trusted in the general case. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
On Sat, 2 Apr 2005, Christian Laursen wrote:
After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem
with my wireless card that has worked fine before.
When I insert it I get an instant panic like this:
#0 doadump () at pcpu.h:159
#1 0xc04feb42 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc04fedd8 in panic (fmt=0xc068de12 %s)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0666400 in trap_fatal (frame=0xc8333bd0, eva=4294966015)
at /usr/src/sys/i386/i386/trap.c:809
#4 0xc066616b in trap_pfault (frame=0xc8333bd0, usermode=0, eva=4294966015)
at /usr/src/sys/i386/i386/trap.c:727
#5 0xc0665dcd in trap (frame=
{tf_fs = 24, tf_es = -936181744, tf_ds = -1068433392, tf_edi =
-1052027392, tf_esi = 1, tf_ebp = -936166384, tf_isp = -936166404, tf_ebx =
-1066683360, tf_edx = -1281, tf_ecx = -1054120947, tf_eax = -335814834,
tf_trapno = 12, tf_err = 0, tf_eip = -1068110692, tf_cs = 8, tf_eflags =
66178, tf_esp = -936166332, tf_ss = -1069088243}) at
/usr/src/sys/i386/i386/trap.c:417
#6 0xc06594fa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0xc8330010 in ?? ()
#9 0xc0510010 in blst_radix_init (scan=0xfaff,
radix=-4527414809764076532, skip=-1054120915, count=Unhandled dwarf
expression opcode 0x93
)
at /usr/src/sys/kern/subr_blist.c:881
#10 0xc047020d in pccard_do_product_lookup (bus=0xc137ad00, dev=0x10282,
tab=0xc0687fe0, ent_size=32, matchfn=0)
at /usr/src/sys/dev/pccard/pccard.c:381
#11 0xc06405b8 in fdc_pccard_probe (dev=0xc14b5600) at card_if.h:194
This makes no sense. What version of src/sys/dev/pccard/pccard.c do you
have? Line 381 is a comparison in RELENG_5:
381 if (matches ent-pp_cis[0]
382 (vendorstr == NULL ||
383 strcmp(ent-pp_cis[0], vendorstr) != 0))
384 matches = 0;
pccard.c does not call any of the radix functions.
I'd suggest blowing away your kernel source and obj dir and rebuilding
your kernel + modules from scratch. This looks like you have a mismatched
module somewhere, or memory corruption, or worse. Be sure to follow the
instructions in UPDATING explaining how to track -STABLE and build the
world and kernel correctly.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Fri, Apr 01, 2005 at 07:06:30PM -0800, Doug White wrote: # On Fri, 1 Apr 2005, Shaun Jurrens wrote: # # Hi guys, # # I'm resending this mail again with the hopes of finding someone who is also # seeing this problem. I know that mail isn't the best method perhaps, but # before I open a PR, I thought I'd try again... # # My last recent update revealed a bug perhaps. I'm now running: # # FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 # 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 # # The system seems to have problems with filedescriptors. It's not otherwise # loaded and it's happed enough that I thought I should mention it before 5.4 # goes out the door (around 50% of the time). # # How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple # list of .mp3 files) # # I get this error message: # Could not resync/reset buffers: Interrupted system call # # and the program simply hangs using 90%+ cpu # # Try upgrading mpg123, for starters. Not handling ERESTART is generally a # bug. That said, I wonder if some syscall that was uninterrupible before # is now not. Can you ktrace mpg123 and try to capture one of the ERESTART # returns? I've recompiled mpg123 but cannot repoduce the hang if I start the program with the same arguments via ktrace (and if I start ktrace after the fact, I just get what I posted in the last mail). It seems to happen about 100% of the time now. I just upgraded world as well: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #29: Fri Apr 1 23:55:02 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The trace doesn't look too wierd, otherwise. There was a warning about having libm.so.2 and libm.so.3 causing a potential conflict during compile... It seems to find the correct lib, but later also opens libm.so.2 After we get all the libs loaded (or not, not using esd and friends) An excerpt of the ktrace: 3107 mpg123 CALL write(0x3,0x7fffe2a0,0x80) 3107 mpg123 GIO fd 3 wrote 128 bytes mpg123\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 3107 mpg123 RET write 128/0x80 3107 mpg123 CALL setsockopt(0x3,0x,0x1001,0x7fffe27c,0x4) 3107 mpg123 RET setsockopt 0 3107 mpg123 CALL setsockopt(0x3,0x,0x1002,0x7fffe27c,0x4) 3107 mpg123 RET setsockopt 0 3107 mpg123 CALL sigaction(0xd,0x7fffe250,0x7fffe230) 3107 mpg123 RET sigaction 0 3107 mpg123 CALL close(0x3) 3107 mpg123 RET close 0 3107 mpg123 CALL sigaction(0x2,0x7fffe3f0,0x7fffe3d0) 3107 mpg123 RET sigaction 0 3107 mpg123 CALL open(0x7fffe827,0,0x7fffe827) 3107 mpg123 NAMI 11_Wishlist.mp3 3107 mpg123 RET open 3 3107 mpg123 CALL lseek(0x3,0,0,0x2) 3107 mpg123 RET lseek 4943025/0x4b6cb1 3107 mpg123 CALL lseek(0x3,0,0xff80,0x2) 3107 mpg123 RET lseek 4942897/0x4b6c31 3107 mpg123 CALL read(0x3,0x7fffe350,0x80) 3107 mpg123 GIO fd 3 read 128 bytes 0x 5441 4757 6973 686c 6973 7400 |TAGWishlist.| 0x0010 || 0x0020 0050 6561 726c 204a 616d |.Pearl Jam..| 0x0030 0052 |...R| 0x0040 6561 7276 6965 776d 6972 726f 7220 2867 |earviewmirror (g| 0x0050 7265 6174 6573 7420 6869 7473 2032 3030 |reatest hits 200| 0x0060 3465 7820 4772 6970 2076 6961 2063 6464 |4ex Grip via cdd| 0x0070 6132 7761 7620 616e 6420 6c61 6d65 0b11 |a2wav and lame..| 3107 mpg123 RET read 128/0x80 3107 mpg123 CALL lseek(0x3,0,0,0) 3107 mpg123 RET lseek 0 3107 mpg123 CALL mmap(0,0x4b6c31,0x1,0x1,0x3,0,0) 3107 mpg123 RET mmap 13312000/0x800cb2000 3107 mpg123 CALL write(0x2,0x7fffdba0,0x3b) 3107 mpg123 GIO fd 2 wrote 59 bytes Title : WishlistArtist: Pearl Jam 3107 mpg123 RET write 59/0x3b 3107 mpg123 CALL write(0x2,0x7fffdba0,0x36) 3107 mpg123 GIO fd 2 wrote 54 bytes Album : Rearviewmirror (greatest hits Year : 2004 3107 mpg123 RET write 54/0x36 3107 mpg123 CALL write(0x2,0x7fffdba0,0x36) 3107 mpg123 GIO fd 2 wrote 54 bytes 0x 436f 6d6d 656e 743a 2065 7820 4772 6970 |Comment: ex Grip| 0x0010 2076 6961 2063 6464 6132 7761 7620 616e | via cdda2wav an| 0x0020 6420 6c61 6d65 0b20 2047 656e 7265 203a |d lame. Genre :| 0x0030 2052 6f63 6b0a | Rock.| 3107 mpg123 RET write 54/0x36 3107 mpg123 CALL write(0x2,0x7fffdc90,0x2e) 3107 mpg123 GIO fd 2 wrote 46 bytes
Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Sun, Apr 03, 2005 at 01:39:50AM +0200, Shaun Jurrens wrote: The trace doesn't look too wierd, otherwise. There was a warning about having libm.so.2 and libm.so.3 causing a potential conflict during compile... It seems to find the correct lib, but later also opens libm.so.2 That's a problem on your system that you should fix, then. It may not be the cause of this problem, but it can definitely cause problems and you need to rule it out. Kris pgpp0oXwytuGd.pgp Description: PGP signature
Recent NDIS Panics Appear To Be Solved
I recently experienced panics with dhclient ndis0 (ndis swi), and I saw that others had noticed similar problems. There is a PR or two about it at the moment. CVSUPping today solved the problem for me. So for those who had the problems, you may find them solved now. Ciao, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent NDIS Panics Appear To Be Solved
On Sat, Apr 02, 2005 at 04:22:34PM -0800, Evan Dower wrote: I recently experienced panics with dhclient ndis0 (ndis swi), and I saw that others had noticed similar problems. There is a PR or two about it at the moment. CVSUPping today solved the problem for me. So for those who had the problems, you may find them solved now. Thanks for the report. I'll update the PRs I can find to request that people check recent versions. Hopefully most of these issues are fixed. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpVCfIXIQKYn.pgp Description: PGP signature
5.4-prerelease - hanging under load
Since I upgraded from 5.3-stable to 5.4-prerelease, I've noticed that my computer is hanging badly under load. I've a P4 2.53 GHz without hyperthreading (no SMP). I use the same kernel configurations than before. Now when I compile a port for example, the mouse pointer hangs in Fluxbox and Mozilla takes forever (meaning ~5 sec) to refresh the screen. Even vi hangs. I do not see any warning/error message. Is it a known problem with 5.4? Thanks Pierre-Luc Drouin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-prerelease - hanging under load
Pierre-Luc Drouin wrote: Since I upgraded from 5.3-stable to 5.4-prerelease, I've noticed that my computer is hanging badly under load. I've a P4 2.53 GHz without hyperthreading (no SMP). I use the same kernel configurations than before. Now when I compile a port for example, the mouse pointer hangs in Fluxbox and Mozilla takes forever (meaning ~5 sec) to refresh the screen. Even vi hangs. I do not see any warning/error message. Is it a known problem with 5.4? Not quite as dramatic here, but when, say, the firefox source gets untarred, my machine becomes quite unresponsive, including audio decoding (xmms) stuttering and the mouse cursor jumping around. Haven't seen the likes since the 486 days. This is 5.4-PRERELEASE on a P4 3GHz. Perhaps some badly balanced scheduler stuff? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-prerelease - hanging under load
On Sun, Apr 03, 2005 at 04:33:49AM +0200, Matthias Buelow wrote: Pierre-Luc Drouin wrote: Since I upgraded from 5.3-stable to 5.4-prerelease, I've noticed that my computer is hanging badly under load. I've a P4 2.53 GHz without hyperthreading (no SMP). I use the same kernel configurations than before. Now when I compile a port for example, the mouse pointer hangs in Fluxbox and Mozilla takes forever (meaning ~5 sec) to refresh the screen. Even vi hangs. I do not see any warning/error message. Is it a known problem with 5.4? Not quite as dramatic here, but when, say, the firefox source gets untarred, my machine becomes quite unresponsive, including audio decoding (xmms) stuttering and the mouse cursor jumping around. Haven't seen the likes since the 486 days. This is 5.4-PRERELEASE on a P4 3GHz. Perhaps some badly balanced scheduler stuff? You both forgot to mention which scheduler ;-) Kris pgpyl7SA9ofnP.pgp Description: PGP signature
Re: 5.4-prerelease - hanging under load
Kris Kennaway wrote: You both forgot to mention which scheduler ;-) Uhm, how should I know? The default thingy, I haven't changed anything. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-prerelease - hanging under load
On Sun, Apr 03, 2005 at 07:00:35AM +0200, Matthias Buelow wrote: Kris Kennaway wrote: You both forgot to mention which scheduler ;-) Uhm, how should I know? Check your kernel config. The default thingy, I haven't changed anything. SCHED_4BSD, then. Kris pgpxzgu1YCV8G.pgp Description: PGP signature
Re: 5.4-prerelease - hanging under load
Kris Kennaway wrote: Check your kernel config. SCHED_4BSD, then. options SCHED_4BSD # 4BSD scheduler yes. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-prerelease - hanging under load
Matthias Buelow wrote: Kris Kennaway wrote: Check your kernel config. SCHED_4BSD, then. options SCHED_4BSD # 4BSD scheduler yes. mkb. I have this option too. Do I have to change it for something else? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-prerelease - hanging under load
On Sun, Apr 03, 2005 at 12:22:30AM -0500, Pierre-Luc Drouin wrote: Matthias Buelow wrote: Kris Kennaway wrote: Check your kernel config. SCHED_4BSD, then. options SCHED_4BSD # 4BSD scheduler yes. mkb. I have this option too. Do I have to change it for something else? No, but it's important to know to complete the bug report. Kris pgpBtGg1Qiwi1.pgp Description: PGP signature
