Re: Buildworld failure on 5.1-REL
Hi. On Sat, Nov 29, 2003 at 11:42:36AM +0300, Odhiambo Washington wrote: Hoping against hope! Still trying to fight out a problem which could possibly be a simple one compared to the others that I have seen. I have put a bzipped error text at the following URL. http://ns2.wananchi.com/~wash/FreeBSD/ Is there some clue in that file that can help me get a successful buildoworld? If you're using cvsup to check out the source tree, are you sure you have `*default delete' line in the supfile? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR or panic with ips driver (was Re: cvs commit: src/sys/dev/ips ips.c ips.h ips_commands.c)
Hello. On 2003/11/27 00:37:36, Martin Blapp wrote: mbr 2003/11/27 00:37:36 PST FreeBSD src repository Modified files: sys/dev/ips ips.c ips.h ips_commands.c Log: ServeRaid (at least 5i) didn't initialize correctly. To get them working (cache, automatic rebuild and hotswap) the FFDC info (First Failure Data Capture) on the adapter must be initialised. Logical drives in critical/degraded states weren't added to the drive list. FreeBSD was not able to see a degraded array after a reboot. Degraded drives are now also added to the drivelist and the state of the logical drive is given at boottime. The adapter type is detected from informations in nvram page 5 and displayed at boottime. Change IPS_OS_FREEBSD definition from 10 to 8 according to IBM specs. Submitted by: Patrick Guelat [EMAIL PROTECTED] Reviewed by:mbr, scottl Approved by:re Revision ChangesPath 1.6 +64 -2 src/sys/dev/ips/ips.c 1.5 +57 -2 src/sys/dev/ips/ips.h 1.7 +90 -0 src/sys/dev/ips/ips_commands.c After seeing this commit message, I've upgraded -CURRENT installed on NetFinity 6000R(with ServeRAID 4H) to catch up with the recent changes. However, LOR or panic still persists. You can panic your -CURRENT machine by creating a log of files in a directory. You can do it with a simple shell script like this: $ mkdir foo; i=0; while :; do echo $i foo/$i; i=$(($i+1)); done - If you have WITNESS_* options in the kernel config file, you'll see a lot of LOR messages on the console or in /var/log/messages, along with a bunch of `iobuf error 5', but the kernel doesn't panic(or takes very long time before it panics). - If you don't have WITNESS_* options in the kernel config file and run the code above, the kernel panics in a few minutes after seeing `iobuf error 5' messages. I've already submitted a PR for this as kern/57832, but still have no idea how to fix this. The traceback looks almost the same as it was a few months ago. Regards. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
Hello. On Sat, Nov 29, 2003 at 12:36:22AM -0400, Marc G. Fournier wrote: What hardware, kernel configuration, etc? Do you have a misconfigured ntpd/timed that is manually flapping the time around? Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 processes running on it currently ... kernel config is at the bottom, but I don't think there is anything 'abnormal' about it ... and note that I've had others be able to reproduce the problem on both 4.x and 5.x systems ... as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59), but that is it as far as playing with the clock is concerned ... What does `sysctl kern.timecounter' show? Also, does changing kern.timecounter.hardware (TSC, i8254, ACPI-safe, ...) affect the results from your test program? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lots of exclusive sleep mutex
On 2003/10/31 10:09:04, YONETANI Tomokazu wrote:
On 2003/10/30 00:16:47, Clive Lin wrote:
On Sat, Oct 04, 2003 at 02:00:33AM +0800, Clive Lin wrote:
Hi,
I've seen lots of messages on rescent -CURRENT
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
Many of above are still seen on the latest current.
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
Perhaps it's a ServeRAID specific glitch?
dmesg|grep ips
ips0: IBM ServeRAID Adapter mem 0xf000-0xf3ff irq 16 at device 1.0 on
pci4
ips0: logical drives: 1
ipsd0: Logical Drive on ips0
GEOM: create disk ipsd0 dp=0xc6b25310
ipsd0: Logical Drive (69430MB)
Does this fix?
Index: ips.c
[snipped]
Of course it doesn't. Hmm, I didn't realize that I've removed WITNESS* from
the kernel config file months ago. Anyway, this is the backtrace of
the above warnings from witness code(by manually setting a breakpoint
inside witness_warning and issuing panic command from DDB):
Script started on Fri Oct 31 12:47:51 2003
# gdb -k /usr/obj/home/source/freebsd/current/src/sys/MAIL/kernel.debug vmcore.0
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: from debugger
panic messages:
---
---
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/usb.ko...done.
Loaded symbols for /boot/kernel/usb.ko
Reading symbols from /boot/kernel/nfsclient.ko...done.
Loaded symbols for /boot/kernel/nfsclient.ko
#0 doadump () at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:240
#1 0xc0576346 in boot (howto=260)
at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:372
#2 0xc0576677 in panic ()
at /home/source/freebsd/current/src/sys/kern/kern_shutdown.c:550
#3 0xc045d1c2 in db_panic ()
at /home/source/freebsd/current/src/sys/ddb/db_command.c:450
#4 0xc045d122 in db_command (last_cmdp=0xc073e460, cmd_table=0x0,
aux_cmd_tablep=0xc0709cec, aux_cmd_tablep_end=0xc0709d04)
at /home/source/freebsd/current/src/sys/ddb/db_command.c:346
#5 0xc045d265 in db_command_loop ()
at /home/source/freebsd/current/src/sys/ddb/db_command.c:472
#6 0xc0460265 in db_trap (type=3, code=0)
at /home/source/freebsd/current/src/sys/ddb/db_trap.c:73
#7 0xc069765c in kdb_trap (type=3, code=0, regs=0xd77e5b3c)
at /home/source/freebsd/current/src/sys/i386/i386/db_interface.c:171
#8 0xc06a7fe8 in trap (frame=
{tf_fs = -1065877480, tf_es = -1065877488, tf_ds = -679608304, tf_edi =
-1065836412, tf_esi = -1065836416, tf_ebp = -679584872, tf_isp = -679584920, tf_ebx =
0, tf_edx = 0, tf_ecx = -1056882688, tf_eax = 19, tf_trapno = 3, tf_err = 0, tf_eip =
-1067865189, tf_cs = 8, tf_eflags = 514, tf_esp = -1066450495, tf_ss = -679584852}) at
/home/source/freebsd/current/src/sys/i386/i386/trap.c:582
#9 0xc0699048 in calltrap () at {standard input}:102
#10 0xc0674b34 in uma_zalloc_arg (zone=0xc078a080, udata=0x0, flags=0)
at /home/source/freebsd/current/src/sys/vm/uma_core.c:1385
#11 0xc056bd05 in malloc (size=0, type=0xc07235c0, flags=0)
at /home/source/freebsd/current/src/sys/vm/uma.h:234
#12 0xc04e5d44 in ips_add_waiting_command (sc=0xc479f000,
callback=0xc04e8050 ips_send_io_request, data=0xc7ea9a18, flags=0)
at /home/source/freebsd/current/src/sys/dev/ips/ips.c:147
#13 0xc04e5f1e in ips_get_free_cmd (sc=0x0,
callback=0xc04e8050 ips_send_io_request, data=0xc7ea9a18, flags=0)
at /home/source/freebsd/current/src/sys/dev/ips/ips.c:222
#14 0xc04e813e in ips_start_io_request (sc=0xc7ea9a18, iobuf=0x0)
at /home/source/freebsd/current/src/sys/dev/ips/ips_commands.c:168
#15 0xc04e7b62 in ipsd_strategy (iobuf=0x0)
at /home/source/freebsd/current/src/sys/dev/ips/ips_disk.c:100
#16 0xc0546036 in g_disk_start (bp=0xc8798110)
at /home/source/freebsd/current/src/sys/geom/geom_disk.c:272
---Type return to continue, or q return to quit---
#17 0xc0547fcc in g_io_schedule_down (tp=0xc1d17000)
at /home/source/freebsd/current/src/sys
Re: lots of exclusive sleep mutex
On 2003/10/30 00:16:47, Clive Lin wrote:
On Sat, Oct 04, 2003 at 02:00:33AM +0800, Clive Lin wrote:
Hi,
I've seen lots of messages on rescent -CURRENT
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:351
Many of above are still seen on the latest current.
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
malloc() of 16 with the following non-sleepable locks held:
exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
/usr/src/sys/geom/geom_io.c:355
Perhaps it's a ServeRAID specific glitch?
dmesg|grep ips
ips0: IBM ServeRAID Adapter mem 0xf000-0xf3ff irq 16 at device 1.0 on pci4
ips0: logical drives: 1
ipsd0: Logical Drive on ips0
GEOM: create disk ipsd0 dp=0xc6b25310
ipsd0: Logical Drive (69430MB)
Does this fix?
Index: ips.c
===
RCS file: /home/cvs/freebsd/src/sys/dev/ips/ips.c,v
retrieving revision 1.5
diff -u -6 -r1.5 ips.c
--- ips.c 24 Aug 2003 17:49:13 - 1.5
+++ ips.c 30 Oct 2003 08:45:32 -
@@ -147,12 +147,13 @@
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc-state IPS_OFFLINE){
splx(mask);
+ free(waiter, M_DEVBUF);
return EIO;
}
command = SLIST_FIRST(sc-free_cmd_list);
if(command !(sc-state IPS_TIMEOUT)){
SLIST_REMOVE_HEAD(sc-free_cmd_list, next);
(sc-used_commands)++;
By the way, does this panic your machine?
$ exec sh
$ mkdir foo
$ i=0; while :; do echo $i foo/$i; i=$(($i+1)); done
Regards.
--
YONETANI Tomokazu / Ergo-Brains Inc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: softdep_deallocate_dependencies: dangling deps
Hello. On 2003/10/13 02:09:54, Oliver Fischer wrote: My notebook was a little bit panic this night. After rebooting I found this message in my system log: panic: softdep_deallocate_dependencies: dangling deps I've been seeing this panic on NetFinity 6000R since end of September. -CURRENT is installed on a RAID partition, and the partition is controlled by ips driver, so it's possible that the root of my problem is completely different from yours, but anyway... To reproduce it, enable dump device and create many files in a directory: # mkdir foo; i=0; while :; do echo -n $i foo/$i; i=$(($i + 1)); done and go to bed and you'll get a kernel dump in the crash dump directory in the next morning. At first I thought that the hard disk is damanged, but the following dd command doesn't panic the machine, just fills up the partition many times. # while :; do dd if=/dev/zero of=BIG bs=1048576; done With -CURRENT built from source as of D2003.10.21.00.00.00, I'm still able to reproduce this panic, together with new one: panic: handle_written_inodeblock: live inodedep Backtraces are available on request. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore: first and last dump headers disagree on /dev/ad0b
On 2003/10/07 18:11:30, Doug White wrote: On Tue, 7 Oct 2003, YONETANI Tomokazu wrote: The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. You could optionally set hw.ata.ata_dma=0 in loader.conf to disable UDMA rather than apply the patch. Yes, setting hw.ata.ata_dma=0 allowed me to dump a usable core file. Thanks. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
savecore: first and last dump headers disagree on /dev/ad0b
Hello. -CURRENT as of yesterday can't save kernel dump: savecore: first and last dump headers disagree on /dev/ad0b savecore: unsaved dumps found but not saved Is this a known issue? I need to be able to dump to this device because I've seen reliably reproducible panics to be reported, and saving kernel dumps is not supported by ips(4). /dev/ad0 is an IDE hard disk capable of UDMA33 and dedicated to saving kernel dumps, and is not used as a swap device, so I think misc/55933 is not relavant. How can I force it to save the kernel dump; I've tried -f optition, but it didn't work. I've seen no odd messages while it's dumping, just the numbers counted up from 16 to 512. The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. Please tell me if I missed any information you need. Regards. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] incorrect mediasize calculation in ips driver
Hello. While trying to install recent snapshot of -CURRENT on Netfinity 6000R, sysinstall and other tools reported the size of RAID partition much smaller than expected. After looking into source code, I noticed a small bug in calculation of d_mediasize: Index: ips_disk.c === RCS file: /home/cvs/freebsd/src/sys/dev/ips/ips_disk.c,v retrieving revision 1.3 diff -u -r1.3 ips_disk.c --- ips_disk.c 24 Aug 2003 17:49:14 - 1.3 +++ ips_disk.c 22 Sep 2003 07:19:46 - @@ -139,7 +139,7 @@ dsc-ipsd_disk.d_fwsectors = IPS_COMP_SECTORS; } dsc-ipsd_disk.d_sectorsize = IPS_BLKSIZE; - dsc-ipsd_disk.d_mediasize = totalsectors * IPS_BLKSIZE; + dsc-ipsd_disk.d_mediasize = (off_t)totalsectors * IPS_BLKSIZE; disk_create(dsc-unit, dsc-ipsd_disk, 0, NULL, NULL); device_printf(dev, Logical Drive (%dMB)\n, Regards. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] incorrect mediasize calculation in ips driver
While trying to install recent snapshot of -CURRENT on Netfinity 6000R, sysinstall and other tools reported the size of RAID partition much smaller than expected. After looking into source code, I noticed a small bug in calculation of d_mediasize: Please disregard this message, it's already been reported by another person and committed several hours ago. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
