Re: (bsd)tar is broken on 6.1
Jonathan Noack writes: Jean-Marc Zucconi wrote: # tar cf /dev/null X11R6.old # archive_write_pax_header: 'x' header failed?! This can't happen. This seems to work fine here: [EMAIL PROTECTED]:/usr] $ uname -rm 6.1-RELEASE i386 [EMAIL PROTECTED]:/usr] $ tar --version bsdtar 1.02.023, libarchive 1.02.026 Copyright (C) 2003-2005 Tim Kientzle [EMAIL PROTECTED]:/usr] $ tar cf /dev/null X11R6 [EMAIL PROTECTED]:/usr] $ Sure, but the directories are not the same. I have narrowed the problem to a specific subdirectory and I think I have the explanation: -rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg Don't ask me why the date is wrong, this is really old stuff :-) On the other hand tar has no problem extracting it. If someone wants to debug it, the archive is available as http://people.freebsd.org/~jmz/a.tar Jean-Marc -- Jean-Marc Zucconi -- PGP Key: finger [EMAIL PROTECTED] [KeyID: 400B38E9] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch, try 1] Re: Trouble with NFSd under 6.1-Stable, any ideas?
Hi! On Thu, May 25, 2006 at 05:58:09PM +0300, Konstantin Belousov wrote: Please, users who reported the problem and willing to help, try the patch (generated against STABLE) and give the feedback. I test it with RELENG_6 from 25 May 2006. It's work fine. Thank you. WBR -- Dmitriy Kirhlarov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7247 ext.203 F:+7 495 105 7246 E:[EMAIL PROTECTED] OILspace - The resource enriched - www.oilspace.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (bsd)tar is broken on 6.1
On 05/26/06 04:37, Jean-Marc Zucconi wrote: Jonathan Noack writes: Jean-Marc Zucconi wrote: # tar cf /dev/null X11R6.old # archive_write_pax_header: 'x' header failed?! This can't happen. This seems to work fine here: [EMAIL PROTECTED]:/usr] $ uname -rm 6.1-RELEASE i386 [EMAIL PROTECTED]:/usr] $ tar --version bsdtar 1.02.023, libarchive 1.02.026 Copyright (C) 2003-2005 Tim Kientzle [EMAIL PROTECTED]:/usr] $ tar cf /dev/null X11R6 [EMAIL PROTECTED]:/usr] $ Sure, but the directories are not the same. As you provided no details in your original email, I was forced to assume that the problem was in the use of /dev/null (I used the X11R6 directory for fun). I was mistaken, but remember that not *all* of us can read your mind... :) I have narrowed the problem to a specific subdirectory and I think I have the explanation: -rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg Don't ask me why the date is wrong, this is really old stuff :-) On the other hand tar has no problem extracting it. If someone wants to debug it, the archive is available as http://people.freebsd.org/~jmz/a.tar I see the same thing here. Touching supclkrd.prg to bring the date current makes the problem go away. Tim, any thoughts? -Jonathan -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: (bsd)tar is broken on 6.1
Hello! I have narrowed the problem to a specific subdirectory and I think I have the explanation: -rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg Don't ask me why the date is wrong, this is really old stuff :-) Since there cannot be a date before January 1st 1970, 0:00 on any Unix system, i guess there's something seriously broken here. Signed/unsigned overflow for the time_t value in question? Regards, Patrick M. Hausen -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kmem leak in tmpmfs?
On Thu, 2006-05-25 at 16:54 -0400, Kris Kennaway wrote: On Thu, May 25, 2006 at 06:01:30PM +0200, Arno J. Klaassen wrote: Hello, I get a very easy to reproduce panic on 6.1-STABLE : /etc/periodic/weekly/310.locate panics with panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated It looks like you are using a malloc-backed md and you do not have enough RAM to handle the size. Perhaps tmpmfs does not use swap backing, as it is supposed to? Kris First of all if there is not enough kmem (not just plain ram I think) kernel should not allow disk creation in first place, second - I think (although there could be some ... reason for that) it's stupid way to say I don't have more kmem by panicing :). Better way will be just to fail disk operation of that FS with Disk is full or something like that. At home I tried to raise kmem like that: vm.kmem_size_max=1073741824 (I got 2G of RAM) (setting vm.kmem_size directly panices kernel at boot if I remember correctly). but for my surprise kernel panices at exact same allocated md disk space with the same panic as the original poster's. Is it possible that I should rise KVA_PAGES too ? And I don't think its documented anywhere (of course I've tried googling and it's always possible that I've missed something :). All this was on FreeBSD 6.0. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE boot images: 6.1 i386/amd64
Am 25. Mai 2006 um 14:59:50 +0100 schrieb Paul Civati: For those of you wishing to PXE boot 6.1 RELEASE I have made some boot images that work easily with pxelinux (syslinux) PXE set-up. Thank you very much! First time since several years I'm able again to install a FreeBSD at my site. My PXELINUX menu looks like this now $Id: mkpxe,v 1.7 2004/07/01 18:01:02 nora Exp $ m5 INST - Mandriva Limited Edition 2005 (10.2) m6 INST - Mandriva 2006.0 mc INST - Mandriva 2006.X (Cooker) f5 INST - Fedora Core 5 Installation debian INST - Debian Installer fbsd INST - FreeBSD 6.1-RELEASE dose WORK - DOS Werkzeug-Diskette gag TOOL - GAG Boot-Manager 4.6 mem TOOL - MEM86 Speichertest, http://www.memtest86.com/ a9 AUTO - Autoinstallation Mandrake Linux 9.2 a0 AUTO - AutoInstallation Mandrake Linux 10.0 a1 AUTO - AutoInstallation Mandrake Linux 10.1 a5 AUTO - AutoInstallation Mandriva Limited Edition 2005 (10.2) a6 AUTO - AutoInstallation 2006.0 ac AUTO - AutoInstallation 2006.X (Cooker) f5ks AUTO - Fedora Core 5 Kickstart-Installation boot: I didn't need the C/H/S options in the 'append'-line for your 6.1 image. Liebe Grüße, Nora. [EMAIL PROTECTED] IM-NETZ Neue Medien, Berlin http://www.im-netz.de/ WWW von Frauen für Frauen, Hamburg http://www.w4w.net/ Lesbian Computer Networks, Helsinki http://www.sappho.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (bsd)tar is broken on 6.1
On Fri, 2006-May-26 11:34:43 +0200, Patrick M. Hausen wrote: -rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg Since there cannot be a date before January 1st 1970, 0:00 on any Unix system, i guess there's something seriously broken here. Why do you say that? time_t is signed so it can represent a date prior to 1970. In theory, a file prepared on an earlier computer could have been transferred onto a Unix system whilst retaining its original modification time. In this particular case, the date seems unlikely. That said, it is a perfectly valid date and it would be nice if tar could support it - though tar(5) states dates before the epoch are not handled consistently. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kmem leak in tmpmfs?
Iasen Kostov [EMAIL PROTECTED] wrote: On Thu, 2006-05-25 at 16:54 -0400, Kris Kennaway wrote: On Thu, May 25, 2006 at 06:01:30PM +0200, Arno J. Klaassen wrote: I get a very easy to reproduce panic on 6.1-STABLE : /etc/periodic/weekly/310.locate panics with panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated It looks like you are using a malloc-backed md and you do not have enough RAM to handle the size. Perhaps tmpmfs does not use swap backing, as it is supposed to? First of all if there is not enough kmem (not just plain ram I think) kernel should not allow disk creation in first place, second - I think (although there could be some ... reason for that) it's stupid way to say I don't have more kmem by panicing :). Better way will be just to fail disk operation of that FS with Disk is full or something like that. At home I tried to raise kmem like that: vm.kmem_size_max=1073741824 (I got 2G of RAM) (setting vm.kmem_size directly panices kernel at boot if I remember correctly). but for my surprise kernel panices at exact same allocated md disk space with the same panic as the original poster's. Is it possible that I should rise KVA_PAGES too ? And I don't think its documented anywhere (of course I've tried googling and it's always possible that I've missed something :). All this was on FreeBSD 6.0. man mdconfig mentions the problem: malloc Storage for this type of memory disk is allocated with malloc(9). This limits the size to the malloc bucket limit in the kernel. If the -o reserve option is not set, creating and filling a large malloc-backed memory disk is a very easy way to panic a system. Use a swap backed disk and the problem will disappear. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: kmem leak in tmpmfs?
On Fri, 2006-05-26 at 13:15 +0200, Fabian Keil wrote: Iasen Kostov [EMAIL PROTECTED] wrote: On Thu, 2006-05-25 at 16:54 -0400, Kris Kennaway wrote: On Thu, May 25, 2006 at 06:01:30PM +0200, Arno J. Klaassen wrote: I get a very easy to reproduce panic on 6.1-STABLE : /etc/periodic/weekly/310.locate panics with panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated It looks like you are using a malloc-backed md and you do not have enough RAM to handle the size. Perhaps tmpmfs does not use swap backing, as it is supposed to? First of all if there is not enough kmem (not just plain ram I think) kernel should not allow disk creation in first place, second - I think (although there could be some ... reason for that) it's stupid way to say I don't have more kmem by panicing :). Better way will be just to fail disk operation of that FS with Disk is full or something like that. At home I tried to raise kmem like that: vm.kmem_size_max=1073741824 (I got 2G of RAM) (setting vm.kmem_size directly panices kernel at boot if I remember correctly). but for my surprise kernel panices at exact same allocated md disk space with the same panic as the original poster's. Is it possible that I should rise KVA_PAGES too ? And I don't think its documented anywhere (of course I've tried googling and it's always possible that I've missed something :). All this was on FreeBSD 6.0. man mdconfig mentions the problem: malloc Storage for this type of memory disk is allocated with malloc(9). This limits the size to the malloc bucket limit in the kernel. If the -o reserve option is not set, creating and filling a large malloc-backed memory disk is a very easy way to panic a system. Use a swap backed disk and the problem will disappear. I ment KVA_PAGES (If it is the limit). But may be malloc bucket limit (which I don't realy understand what it means) has something to do with it ? But whatever is the cause I think it no good practice to leave such easy ways to panic the kernel unsecured/pached/fixed. And I wander why even when I set kmem_size_max to 1G kernel still panices around 350MB allocated md space ? I mean what is the real issue there ? Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI issues ? (Re: Increase in panics under 6.1)
On Thu, May 25, 2006, Fabian Keil wrote: Interestingly enough , i had some nasty issues todays on same laptop. I had 2 x 6 GB GELI vnodes, running mtree -K md5digest to compare contents. Disk IO was high as expected...but then it just died down (but the mtree hadnt finished). (swap is also GELI) Any subsequent process trying to access the encrypted mount points simply stalled for as long as I cared to wait (10 minutes). The processes even stalled a shutdown -r. I'm not sure if it's related, but I lately see this behaviour on NFS mounts if the server is not responding. Doing cd /mnt/mydeadnfsmount/[tab for autocompletion] is enough to render the current console unresponsive. Isn't that normal and desired for `hard' mounts? -- Kocia galeria - http://koty.foo.pl/ pgpLwvacqJ6dg.pgp Description: PGP signature
Re: (bsd)tar is broken on 6.1
Patrick M. Hausen wrote: I have narrowed the problem to a specific subdirectory and I think I have the explanation: -rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg Yes, libarchive in 6.1 has a broken assertion in the tar-writing code that causes it to (erroneously) reject files with very old dates. This is fixed in -CURRENT; I plan to MFC a bunch of fixes like this to 6-STABLE very soon. In the meantime, you can fix this by installing the most current libarchive from: http://people.freebsd.org/~kientzle/libarchive Or you can temporarily patch it by looking in src/lib/libarchive/archive_write_format_pax.c and changing the second call to __archive_write_format_header_ustar() so that the last argument is 0, not 1. (The 1 here enables the above-mentioned assertion checks.) Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kmem leak in tmpmfs?
On Fri, May 26, 2006 at 01:26:24PM +0300, Iasen Kostov wrote: On Thu, 2006-05-25 at 16:54 -0400, Kris Kennaway wrote: On Thu, May 25, 2006 at 06:01:30PM +0200, Arno J. Klaassen wrote: Hello, I get a very easy to reproduce panic on 6.1-STABLE : /etc/periodic/weekly/310.locate panics with panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated It looks like you are using a malloc-backed md and you do not have enough RAM to handle the size. Perhaps tmpmfs does not use swap backing, as it is supposed to? Kris First of all if there is not enough kmem (not just plain ram I think) kernel should not allow disk creation in first place, second - I think (although there could be some ... reason for that) it's stupid way to say I don't have more kmem by panicing :). Better way will be just to fail disk operation of that FS with Disk is full or something like that. At home I tried to raise kmem like that: vm.kmem_size_max=1073741824 (I got 2G of RAM) (setting vm.kmem_size directly panices kernel at boot if I remember correctly). but for my surprise kernel panices at exact same allocated md disk space with the same panic as the original poster's. Is it possible that I should rise KVA_PAGES too ? And I don't think its documented anywhere (of course I've tried googling and it's always possible that I've missed something :). All this was on FreeBSD 6.0. It's documented in the mdconfig manpage including how to make it not panic. Kris pgpOQwYT9GcFZ.pgp Description: PGP signature
Re: kmem leak in tmpmfs?
Hello, thanx to all who responded. Setting ' tmpmfs_flags=-S -o async ' survived a nightly started locate script and a day of intensive 'normal' load. YMMV, but again, merci! Arno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6-STABLE on a Dual PIII server ...
ya, I still have 3 of these :) dmesg is showing something I've never seen before though: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 ACPI-0698: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [WUES] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [WUSE] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [CSB5] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0698: *** Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to (Scope) MADT: Forcing active-low polarity and level trigger for SCI Its an Intel motherboard ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
New mobo means USB problems
I recently got a new motherboard and now I have trouble with USB. I had no problems with my two USB drives before, but now a) I can't boot with my external USB hard drive connected and powered on, and b) moving files onto my Creative MP3 player causes that file system to hang. This second problem seems to be the same as was mentioned here on 5 May, at http://docs.FreeBSD.org/cgi/mid.cgi?iiuui3-q31.ln1 The new motherboard is an ASUS P5S800-VM and the BIOS is right up to date. It comes with USB 2.0 built in. I'm running FreeBSD 6.1-STABLE, and built a new world on 6 May, after I got this new mobo home. A healthy dmesg is at the bottom of this message. I saw some talk on mailing lists about ACPI being related to this kind of thing, so I tried booting without it (with unset acpi_load at the boot prompt) and it panicked, which wasn't helpful. a) Timeouts and failures when booting with external USB hard drive plugged in and turned on. I have a Maxtor drive in an external USB 2.0 enclosure. When it's connected and turned on, I cannot boot. The different bits from dmesg look like this: [same stuff as usual up to this point; see below] uhub3: 8 ports with 8 removable, self powered [ten-second or so delay, which I don't see on a normal boot] atapci1: SiS 181 SATA150 controller port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef90-0xef9f,0xe480-0xe4ff irq 17 at device 5.0 on pci0 [continues as normal until ...] ad0: 39205MB Maxtor 6E040L0 NAR61HA0 at ata0-master UDMA133 ad1: 19092MB WDC WD200BB-00CAA0 16.06V16 at ata0-slave UDMA100 acd0: CDRW HL-DT-ST GCE-8526B/1.03 at ata1-master UDMA33 pcm0: ac97 link rate calibration timed out after 1952041 us ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=0 ad0: TIMEOUT - READ_DMA retrying (0 retries left) LBA=0 ad0: TIMEOUT - FAILURE [something] ad1: TIMEOUT - READ_DMA retrying (1 retry left) LBA=0 ad1: TIMEOUT - READ_DMA retrying (0 retries left) LBA=0 ad1: TIMEOUT - FAILUER [someting] [repeats two more times] acd0: TIMEOUT - READ_BIG retrying (1 retry left) [acd0 TIMEOUTs and FAILURES repeated many times] I usually don't see that pcm0 warning. Finally after lots of errors I have to power cycle it. I can boot with the USB hard drive turned off, and then turn it on and mount it normally, in which case I see: umass0: vendor 0x04b4 USB Mass Storage Device, rev 2.00/2.40, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Maxtor 6 L160P0 Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 156334MB (320173056 512 byte sectors: 255H 63S/T 19929C) I have no trouble moving files on or off the drive after that, so it's annoying that I have to worry about it when I boot, but it's still usable. b) USB Creative Muvo TX FM hangs: BBB reset failed, TIMEOUT I have an MP3 player that has a 1 GB flash drive, and it is no longer usable on this box. Here's what it is: umass0: CREATIVE MuVo TX FM, rev 2.00/11.91, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: CREATIVE MuVo TX FM 1191 Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 993MB (2035456 512 byte sectors: 64H 32S/T 993C) When I mount the file and moves some files onto it, after a couple of files, it stops and hangs. I can't access the file system any more, and get these errors: umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR That continues on and I have to reboot, at which point I see scores of errors like this: g_vfs_done():da0[WRITE(offset=995237848, length=4096)]error = 5 Then I get more BBB reset failed messages, and I have to power cycle. As I said, I used to be able to use this just fine with my old mobo, and my other FreeBSD 6.1-STABLE box can handle it without trouble. Bill -- William Denton : Toronto, Canada : www.miskatonic.org : www.frbr.org 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-STABLE #4: Sat May 6 22:18:56 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHERLOCK ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2653.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf49 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x651dSSE3,RSVD2,MON,DS_CPL,TM2,CNTX-ID,CX16,b14 AMD Features=0x2000LM AMD Features2=0x1LAHF real memory = 1576730624 (1503 MB) avail memory = 1535930368 (1464 MB) ioapic0 Version 1.1
