ACPI causes kernel panic on compaq evo n1020v
hi I'm getting kernel panic on Compaq evo n1020v notebook when trying to boot with ACPI enabled. Last message from kernel is psm0: unable to allocate IRQ without acpi it gets assigned IRQ without problems. Panic is however probably unrelated to psm problem - it paniced the same way when I disabled psm0 device. kernel is current from 05 jan. sources with acpica-20021118-20021122-test20021128 patch, however I got same panics from DP1 & DP2 without any additional patches so the bug is not new here is all the debugging information I could think of: dmesg & panic with acpi & boot -v: http://bsd.ee/~hadara/evo_acpi_debug/dmesg.boot.acpi ( transcribed by hand, because this machine doesn't have any serial ports.. so it probably contains some typos ) dmesg (boot -v) without acpi: http://bsd.ee/~hadara/evo_acpi_debug/dmesg.boot kernel configuration file: http://bsd.ee/~hadara/evo_acpi_debug/IKALDUS only difference between acpi and non acpi kernels were device acpi options ACPI_DEBUG output of acpidump: http://bsd.ee/~hadara/evo_acpi_debug/acpi_dump.txt hints file: http://bsd.ee/~hadara/evo_acpi_debug/device.hints To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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: Kernel halt when connecting re0 to the lan
On Monday 10 November 2003 17:10, Nils Segerdahl wrote: > Problem: > when connecting my laptop (Compaq evo N1020v) to the network, the kernel > halts right after execution of re_diag() in the re-device driver. > The loopback test fails. > The interface works ok if I remove the test from the driver, or if I use > another operating system. It used to work perfect with 4.8-STABLE. > > Any suggestions? hmm I have the very same laptop model and it runs current from last week (06.11.2003 i believe) without any trouble, so probably there is something different in our configuration... do you use re as module or is it compiled in ? (I have it compiled in) probably full dmesg and kernel config would be helpful so we can see what are the differences and trace the cause down better. here are my dmesg and kernel config: http://www.bsd.ee/~hadara/dump/dmesg_04.11.2003.txt http://www.bsd.ee/~hadara/dump/IKALDUS_NODEBUG You probably should cc Bill Paul too, he was asking for testers when he separated support for 8139C+ from rl driver but since it so rare, noone answered and bugs might have very well gone in unnoticed. > > From dmesg: > > re0: port 0x9000-0x90ff mem > 0xf0019800-0xf00198ff > irq 11 at device 11.0 on pci0 > re0: Ethernet address: 00:08:02:d6:bf:cd > miibus0: on re0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > I don't see differences in this part of dmesg's ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Post-KSE disaster with libc_r
hi I tried those libc_r test programs under about a month old CURRENT, and output seems to be identical to yours (didn't try gdb on it but it gives same guard_b segfaults and same programs fail) here's the output: Test static library: -- Test c_user c_system c_total chng passed/FAILEDh_user h_system h_total % chng -- hello_d 0.00 0.100.10 passed -- hello_s 0.00 0.120.12 passed -- join_leak_d 2.50 1.453.95 passed -- mutex_d 2.21 116.36 118.57 passed -- sem_d 0.02 0.120.14 passed -- sigsuspend_d0.01 0.120.12 passed -- sigwait_d User defined signal 1 0.01 0.120.13 *** FAILED *** -- guard_s.pl 1.23 6.918.14 *** FAILED *** (30/30 failed) -- propagate_s.pl 3.68 0.774.45 *** FAILED *** (1/1 failed) -- Totals 4.74 118.26 123.00 0.00 6 / 9 passed (66.67%) 0.00 0.000.000.00% -- *** Error code 1 and lots of guard_b segfault messages to console Stop in /usr/src/lib/libc_r/test. On Tuesday 02 July 2002 05:15, Julian Elischer wrote: > I think that gets us a LOT closer! > > > Total tests 212, passed 212, failed 0 > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on > signal 11 (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 334 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 342 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 346 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 350 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 354 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 358 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 362 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 366 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 370 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 374 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 378 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:53 ref4 kernel: pid 382 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:54 ref4 kernel: pid 386 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:54 ref4 kernel: pid 390 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:54 ref4 kernel: pid 394 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:54 ref4 kernel: pid 398 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:54 ref4 kernel: pid 402 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 kernel: pid 406 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 kernel: pid 410 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 kernel: pid 414 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 kernel: pid 418 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 kernel: pid 422 (guard_b), uid 0: exited on signal 11 > (core dumped) > Jul 2 01:52:55 ref4 ke
