Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
Quoting Tim Kientzle [EMAIL PROTECTED]: On Monday 04 June 2007 17:46, Robin Gruyters wrote: This morning I have revert libarchive (src/lib/libarchive) and tar (src/usr.bin/tar) back to RELENG_6_1 and surprisingly (or maybe not) it works fine now. Maybe tar doesn't use the -b option when listing the content? (-t) Could you please send me details of the problem you're having? Ok, here a small setup. I create a random file with roughly size of 5MB: $ dd if=/dev/random of=archive.dmp bs=1024 count=5120 5120+0 records in 5120+0 records out 5242880 bytes transferred in 0.174116 secs (30111397 bytes/sec) Then a tar the file (with or without blocksize set) to tape: $ sudo tar -cf /dev/sa0 archive.dmp $ After that I try to read/list the tar from tape with tar -t: $ sudo mt -f /dev/sa0 rewind $ sudo tar -tf /dev/sa0 archive.dmp tar: Unrecognized archive format: Inappropriate file type or format $ I get strait away the Unrecognized archive message. But when I extract the archive from tape, it works perfectly: $ sudo tar -xvf /dev/sa0 x archive.dmp $ I have tested this with libarchive and tar from RELENG_6 and RELENG_6_2. No problems with libarchive and tar from RELENG_6_1. If you need more (debug) info, let me know Kind regards, Robin Gruyters Network and Security Engineer Yirdis B.V. I: http://yirdis.com P: +31 (0)36 5300394 F: +31 (0)36 5489119 pgp5dVyZcTE26.pgp Description: PGP Digital Signature
Re: fast rate of major FreeBSD releases to STABLE
all the problem of freebsd is that freebsd-team tries (mostly unsuccesfully) to do EVERYTHING freebsd team not just do freebsd, they doing freebsd5, freebsd6, freebsd7, ports, etc ... and nothing of this can work REALLY STABLE AND FUNCTIONAL i don't like linux, but sometimes i have to choose it i don't like openbsd, but some network features of openbsd i don't see in freebsd people, just try to do FreeBSD, not flavour ... thanx 2007/5/25, Oleg Gritsak [EMAIL PROTECTED]: Actually, I don't see how RELENG_X branch will help. %-\ I would suggest this scheme: branch . - as now, the recent versions branch sec - versions bump strictly at 1-st of january and 1-st of july, other updates fix only security issues. That would be really great improvement to ports, but not sure community has enough programmers among port maintaners, so it's just another dream :o( This looks like another call to have RELENG_x branches on ports, with which I agree. -- системный администратор ООО Сиб-ЭкоМеталл тел. (3912) 609942 (144) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
On Wednesday 06 June 2007 16:14, Robin Gruyters wrote: Then a tar the file (with or without blocksize set) to tape: $ sudo tar -cf /dev/sa0 archive.dmp $ After that I try to read/list the tar from tape with tar -t: $ sudo mt -f /dev/sa0 rewind $ sudo tar -tf /dev/sa0 archive.dmp tar: Unrecognized archive format: Inappropriate file type or format $ I get strait away the Unrecognized archive message. But when I extract the archive from tape, it works perfectly: $ sudo tar -xvf /dev/sa0 x archive.dmp $ I have tested this with libarchive and tar from RELENG_6 and RELENG_6_2. No problems with libarchive and tar from RELENG_6_1. I did.. tar -zcvf /dev/sa0 /boot tar -ztvf /dev/sa0 tar -b 1 -zcvf /dev/sa0 /boot tar -b 1 -ztvf /dev/sa0 tar -b 20 -zcvf /dev/sa0 /boot tar -b 20 -ztvf /dev/sa0 tar -b 128 -zcvf /dev/sa0 /boot tar -b 128 -ztvf /dev/sa0 And they work. The example you gave failed however, so do.. tar -b 1 -cvf /dev/sa0 /boot tar -b 1 -tvf /dev/sa0 tar -b 20 -cvf /dev/sa0 /boot tar -b 20 -tvf /dev/sa0 tar -b 128 -cvf /dev/sa0 /boot tar -b 128 -tvf /dev/sa0 Using dd to feed tar does work though. (I think this agrees with Robin's findings although the fact that it works with -z is curious) [cain 17:05] ~ mt status Mode Density Blocksize bpi Compression Current: 0x40 variable 0disabled -available modes- 0:0x40 variable 00x1 1:0x40 variable 00x1 2:0x40 variable 00x1 3:0x40 variable 00x1 - Current Driver State: at rest. - File Number: 0 Record Number: 0Residual Count 0 This is a Tandberg TS400 (LTO2 drive, LTO1 tape) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp7meTFFccA9.pgp Description: PGP signature
Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
Quoting Daniel O'Connor [EMAIL PROTECTED]: On Wednesday 06 June 2007 16:14, Robin Gruyters wrote: Then a tar the file (with or without blocksize set) to tape: $ sudo tar -cf /dev/sa0 archive.dmp $ After that I try to read/list the tar from tape with tar -t: $ sudo mt -f /dev/sa0 rewind $ sudo tar -tf /dev/sa0 archive.dmp tar: Unrecognized archive format: Inappropriate file type or format $ I get strait away the Unrecognized archive message. But when I extract the archive from tape, it works perfectly: $ sudo tar -xvf /dev/sa0 x archive.dmp $ I have tested this with libarchive and tar from RELENG_6 and RELENG_6_2. No problems with libarchive and tar from RELENG_6_1. I did.. tar -zcvf /dev/sa0 /boot tar -ztvf /dev/sa0 tar -b 1 -zcvf /dev/sa0 /boot tar -b 1 -ztvf /dev/sa0 tar -b 20 -zcvf /dev/sa0 /boot tar -b 20 -ztvf /dev/sa0 tar -b 128 -zcvf /dev/sa0 /boot tar -b 128 -ztvf /dev/sa0 And they work. The example you gave failed however, so do.. tar -b 1 -cvf /dev/sa0 /boot tar -b 1 -tvf /dev/sa0 tar -b 20 -cvf /dev/sa0 /boot tar -b 20 -tvf /dev/sa0 tar -b 128 -cvf /dev/sa0 /boot tar -b 128 -tvf /dev/sa0 Using dd to feed tar does work though. (I think this agrees with Robin's findings although the fact that it works with -z is curious) [cain 17:05] ~ mt status Mode Density Blocksize bpi Compression Current: 0x40 variable 0disabled -available modes- 0:0x40 variable 00x1 1:0x40 variable 00x1 2:0x40 variable 00x1 3:0x40 variable 00x1 - Current Driver State: at rest. - File Number: 0 Record Number: 0Residual Count 0 This is a Tandberg TS400 (LTO2 drive, LTO1 tape) idd, same problem here. When using -z option, works perfectly. Without it, it fails. Here is mine 'mt status' output: $ sudo mt status Mode Density Blocksize bpi Compression Current: 0x47 variable 0DCLZ -available modes- 0:0x47 variable 0DCLZ 1:0x47 variable 0DCLZ 2:0x47 variable 0DCLZ 3:0x47 variable 0DCLZ - Current Driver State: at rest. - File Number: 0 Record Number: 0Residual Count 0 Our tapedrive is a HP C7438A V312. (DAT) Kind regards, Robin Gruyters Network and Security Engineer Yirdis B.V. I: http://yirdis.com P: +31 (0)36 5300394 F: +31 (0)36 5489119 pgpUmqzKSinmP.pgp Description: PGP Digital Signature
cvsup error
hi, recently i tried to update my fresh install machine of 6.2RELEASE to 6.2STABLE, but alway failed with these error msgs: proxy2# /usr/local/bin/cvsup -g -L 2 /etc/stable-supfile Parsing supfile /etc/stable-supfile Connecting to cvsup.id.FreeBSD.org Connected to cvsup.id.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information *** *** runtime error: ***ASSERT failed ***file /work/a/ports/lang/ezm3/work/ezm3-1.2/libs/m3core/src/runtime/common/RTHeapMap.m3, line 35 *** use option @M3stackdump to get a stack trace Abort (core dumped) proxy2# could anyone tell me what is the problems?? it AM2 X2 proc build on amd64 arch TIA ZeN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
Niki Denev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 zen wrote: hi, recently i tried to update my fresh install machine of 6.2RELEASE to 6.2STABLE, but alway failed with these error msgs: proxy2# /usr/local/bin/cvsup -g -L 2 /etc/stable-supfile Parsing supfile /etc/stable-supfile Connecting to cvsup.id.FreeBSD.org Connected to cvsup.id.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information *** *** runtime error: ***ASSERT failed ***file /work/a/ports/lang/ezm3/work/ezm3-1.2/libs/m3core/src/runtime/common/RTHeapMap.m3, line 35 *** use option @M3stackdump to get a stack trace Abort (core dumped) proxy2# could anyone tell me what is the problems?? it AM2 X2 proc build on amd64 arch TIA ZeN Have you tried csup(1) ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZm3PHNAJ/fLbfrkRAsvUAJ98xCLSiKGHqK4JF6KU2zkWlV42dwCeMmNx L5OBvM3+C5j6qFn41Yssv8c= =CCVh -END PGP SIGNATURE- not yet, what is the different?? TIA ZeN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
zen wrote: Niki Denev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 zen wrote: hi, recently i tried to update my fresh install machine of 6.2RELEASE to 6.2STABLE, but alway failed with these error msgs: proxy2# /usr/local/bin/cvsup -g -L 2 /etc/stable-supfile Parsing supfile /etc/stable-supfile Connecting to cvsup.id.FreeBSD.org Connected to cvsup.id.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information *** *** runtime error: ***ASSERT failed ***file /work/a/ports/lang/ezm3/work/ezm3-1.2/libs/m3core/src/runtime/common/RTHeapMap.m3, line 35 *** use option @M3stackdump to get a stack trace Abort (core dumped) proxy2# could anyone tell me what is the problems?? it AM2 X2 proc build on amd64 arch TIA ZeN Have you tried csup(1) ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZm3PHNAJ/fLbfrkRAsvUAJ98xCLSiKGHqK4JF6KU2zkWlV42dwCeMmNx L5OBvM3+C5j6qFn41Yssv8c= =CCVh -END PGP SIGNATURE- not yet, what is the different?? nevermind, i`m trying it right now, TIA ZeN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 zen wrote: hi, recently i tried to update my fresh install machine of 6.2RELEASE to 6.2STABLE, but alway failed with these error msgs: proxy2# /usr/local/bin/cvsup -g -L 2 /etc/stable-supfile Parsing supfile /etc/stable-supfile Connecting to cvsup.id.FreeBSD.org Connected to cvsup.id.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information *** *** runtime error: ***ASSERT failed ***file /work/a/ports/lang/ezm3/work/ezm3-1.2/libs/m3core/src/runtime/common/RTHeapMap.m3, line 35 *** use option @M3stackdump to get a stack trace Abort (core dumped) proxy2# could anyone tell me what is the problems?? it AM2 X2 proc build on amd64 arch TIA ZeN Have you tried csup(1) ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZm3PHNAJ/fLbfrkRAsvUAJ98xCLSiKGHqK4JF6KU2zkWlV42dwCeMmNx L5OBvM3+C5j6qFn41Yssv8c= =CCVh -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fast rate of major FreeBSD releases to STABLE
On Wed, Jun 06, 2007 at 10:50:23AM +0400, Alexey Karagodov wrote: all the problem of freebsd is that freebsd-team tries (mostly unsuccesfully) to do EVERYTHING freebsd team not just do freebsd, they doing freebsd5, freebsd6, freebsd7, ports, etc ... and nothing of this can work REALLY STABLE AND FUNCTIONAL i don't like linux, but sometimes i have to choose it i don't like openbsd, but some network features of openbsd i don't see in freebsd people, just try to do FreeBSD, not flavour ... thanx Uh thanks for your input! thx, Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel ignores kenv comconsole_speed?
On 10/25/06, Stefan Bethke [EMAIL PROTECTED] wrote: Am 25.10.2006 um 10:57 schrieb Stefan Bethke: I'm not sure that would be so easy. However, CONSPEED is/was the setting to be used if the actual setting cannot be determined when sio initializes. The code is there to determine the currently set speed (around line 2440 in sio.c in stable), but it seems it's not triggered on my system. Since you can't just printf some debug info there, I'm not sure which condition is not met, or if something else has since reset the sio to 9600. This piece of loader.conf works for me on latest current. Variations may or may not fail. console=comconsole,vidconsole boot_multicons=yes boot_serial=yes verbose_loading=yes boot_verbose=yes beastie_disable=yes comconsole_speed=115200 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
iSCSI initiator tester wanted
Hi all, I'm in the last mile before crossing the beta-release line, so I'd like to get some input, and update the list of targets it supports. you can obtain the driver from: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.0.92.tar.gz Cheers, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fast rate of major FreeBSD releases to STABLE
and sorry for my english! :) 2007/6/6, Kris Kennaway [EMAIL PROTECTED]: On Wed, Jun 06, 2007 at 10:50:23AM +0400, Alexey Karagodov wrote: all the problem of freebsd is that freebsd-team tries (mostly unsuccesfully) to do EVERYTHING freebsd team not just do freebsd, they doing freebsd5, freebsd6, freebsd7, ports, etc ... and nothing of this can work REALLY STABLE AND FUNCTIONAL i don't like linux, but sometimes i have to choose it i don't like openbsd, but some network features of openbsd i don't see in freebsd people, just try to do FreeBSD, not flavour ... thanx Uh thanks for your input! thx, Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
calcru: runtime went backwards, RELENG_6, SMP
Dear colleagues, on a newly built Supermicro with Pentium D 2.8 (Dual core) with SMP kernel I got zillions of 'runtime went backwards' errors, both on i386 and amd64 kernels. Upd: on GENERIC/amd64 kernel I got the same errors. Any hints to eliminate this? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Booting Supermicro 6015V-M3 on SAS drive with LSI 1068E
I have this machine and I'm just trying to get it to boot from an SAS drive that's all. I'm not trying to use the LSI 1068E for RAID. See here if you're curious about specs: http://www.supermicro.com/products/system/1U/6015/SYS-6015V-M3.cfm Booting from the FreeBSD 6.2 install CD is not a problem; and the install kernel is, interestingly, able to see the drives attached to the LSI 1068E controller and use them. The problem is that the machine's BIOS can not seem to see the drives plugged into the LSI 1068E (raid controller), and thus those drives can not be selected in the BIOS for booting. operating system not found. It seems the only way to get drives bootable from the BIOS that are plugged into the LSI is to put them into a raid. Once a logical disk is configured in the RAID bios one can see in the system bios PCI SCSI: Software Raid. However, even if i did want to use this RAID device, FreeBSD doesn't see/support it (or, it doesn't support FreeBSD). As an experiment I configured the LSI raid to contain one drive (RAID0) (stripe being the size of the drive). I then installed FreeBSD on this drive, and, wonderfully enough, it worked. The BIOS was set to use the PCI SCSI: Software raid, and the MBR was picked up from the single drive, and FreeBSD took over from there. I don't know how safe this is, but it seemed to still work after multiple reboots, and installing a bunch of software. Problems arose however when i installed a gmirror label onto the drive. Suddenly there was no more logical drive in the RAID bios on my next reboot; so i was back to operating system not found: so it seems the LSI RAID also uses the same area as gmirror to store metadata. We want the gmirror on the SAS drives but not the LSI RAID... Other interesting ideas I had included trying to create a boot CD-ROM that would instruct the boot loader to do whatever it needs to do to load gmirror and then continue booting (using vfs.root.mountfrom?). Another idea was using a USB flash key for this. (Not really sure how to create a bootable CDRom to do this, but i'm sure it's possible. Any pointers here might be helpful.) Another idea is it seems we could possibly switch a couple of the cables currently plugged into the LSI ports to the ESB2 SATA ports (this board has both the LSI 1068E controller supporting SAS/SATA, and an ESB2 controler supporting SATA) and use gmirrored SATA drives for booting. This is just a bit of a pain because the existing cables probably aren't long enough... and everything is very tightly packed. Also it means we have to use a couple of SATA drives. And it makes my boss nervous to start moving cables... (though perhaps not as nervous as using a USB flash to boot). Anyhow, anyone played with this hardware? Any recommendations on how to handle this seemingly weird situation? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
On Wed, Jun 06, 2007 at 03:33:52PM +0700, zen wrote: Niki Denev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 zen wrote: hi, recently i tried to update my fresh install machine of 6.2RELEASE to 6.2STABLE, but alway failed with these error msgs: proxy2# /usr/local/bin/cvsup -g -L 2 /etc/stable-supfile Parsing supfile /etc/stable-supfile Connecting to cvsup.id.FreeBSD.org Connected to cvsup.id.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information *** *** runtime error: ***ASSERT failed ***file /work/a/ports/lang/ezm3/work/ezm3-1.2/libs/m3core/src/runtime/common/RTHeapMap.m3, line 35 *** use option @M3stackdump to get a stack trace Abort (core dumped) proxy2# could anyone tell me what is the problems?? it AM2 X2 proc build on amd64 arch TIA ZeN Have you tried csup(1) ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZm3PHNAJ/fLbfrkRAsvUAJ98xCLSiKGHqK4JF6KU2zkWlV42dwCeMmNx L5OBvM3+C5j6qFn41Yssv8c= =CCVh -END PGP SIGNATURE- not yet, what is the different?? The difference is that csup is written in C and included in the base. The only lacking feature in csup is that it doesn't work in checkout mode, which shouldn't be a problem for your average use. I may be wrong about checkout mode, but that was a caveat when it went into the tree IIRC. If that is no longer the case I apologize for the misinformation. -- WXS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
Hi, Have you tried csup(1) ? what is the different?? csup is a rewrite of cvsup in C instead of relying on Modula 3, that seems to cause some troubles on your system. Hth. Kind regards, Robert PS: a happy csup user pgpZ9DybmS5Wu.pgp Description: PGP signature
Re: Booting Supermicro 6015V-M3 on SAS drive with LSI 1068E
On Wed, Jun 06, 2007 at 09:20:55AM -0400, T. Middleton wrote: It seems the only way to get drives bootable from the BIOS that are plugged into the LSI is to put them into a raid. Once a logical disk is configured in the RAID bios one can see in the system bios PCI SCSI: Software Raid. However, even if i did want to use this RAID device, FreeBSD doesn't see/support it (or, it doesn't support FreeBSD). As an experiment I configured the LSI raid to contain one drive (RAID0) (stripe being the size of the drive). I then installed FreeBSD on this drive, and, wonderfully enough, it worked. The BIOS was set to use the PCI SCSI: Software raid, and the MBR was picked up from the single drive, and FreeBSD took over from there. I don't know how safe this is, but it seemed to still work after multiple reboots, and installing a bunch of software. I see this same behaviour with one of my Promise SATA RAID 0/1 controllers. If I put a disk on the controller and *do not* define an array (e.g. drives are in JBOD), FreeBSD can see the drive (as ad4) and install onto it, but the Promise BIOS will not boot the disk. The system BIOS boot order is Floppy, CD-ROM, IDE, then SCSI (which is what these controllers claim to be from a BIOS perspective). The Boot Other option is also set to Yes. The Promise controller also states something about not installing interrupt handler, which I'm pretty sure is needed for the controller to be used to boot the disk. I forget which interrupt it is, but the method is fairly normal (seen it on Adaptec controllers too). Not until I go into the Promise BIOS and define a RAID array (I picked RAID 0 with only 1 disk associated with it) will the controller boot the disk. FreeBSD then comes up and sees two available disks: ad4 (the standalone disk in JBOD) and ar0 (the RAID 0 array). I'm positive this part is normal behaviour (for FreeBSD), but the fact I have to define an array to get the disk bootable is just silly. Then again, I suppose most people buying RAID controllers are doing so to use the actual benefits of RAID, so I'll likely be branded as someone who's crying over spilled milk. If I had two disks in the system and was using RAID 1, safe to say the instant I defined the RAID 1 array, the system would boot and FreeBSD would see both disks and ar0. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator tester wanted
Quoting Danny Braniss [EMAIL PROTECTED]: I'm in the last mile before crossing the beta-release line, so I'd like to get some input, and update the list of targets it supports. you can obtain the driver from: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.0.92.tar.gz Looks great! I've done some basic testing against our cluster of three LeftHand Networks NSM 160's running SAN/iQ 6.6SP1. My machine is running -CURRENT as of a couple days ago (with gcc 4.2 and symbol versioning). I've tested previous snapshots of the driver against the same SAN on this and another machine running -STABLE with good results. Is there anything specific you'd like tested? What connection interruption scenarios does the driver try to recover from? I'm running some backups to an iSCSI mount now. When that finishes (and my machine is otherwise unoccupied) I'll play around with temporarily yanking the ethernet cable and other fun tricks. Thanks for the Makefiles. Your blurb text incorrectly directs the reader to run make in sys/dev/iscsi_initiator (which doesn't exist, and there's no Makefile in sys/dev/iscsi). Obviously you meant sys/modules/iscsi_initiator. Also, a line about running make in iscontrol/ would be helpful, as would an install target in that Makefile. Do you have any suggestions on startup integration (rc script, fstab magic, etc)? I know you said once before that that was hopefully coming soon.. Thanks again. I'll post again if I manage to break something. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator tester wanted
Quoting Danny Braniss [EMAIL PROTECTED]:
I'm in the last mile before crossing the beta-release line,
so I'd like to get some input, and update the list of targets it supports.
you can obtain the driver from:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.0.92.tar.gz
Looks great! I've done some basic testing against our cluster of three
LeftHand Networks NSM 160's running SAN/iQ 6.6SP1. My machine is
running -CURRENT as of a couple days ago (with gcc 4.2 and symbol
versioning). I've tested previous snapshots of the driver against the
same SAN on this and another machine running -STABLE with good results.
so i'm updating my Targets file.
Is there anything specific you'd like tested? What connection
interruption scenarios does the driver try to recover from? I'm running
some backups to an iSCSI mount now. When that finishes (and my machine
is otherwise unoccupied) I'll play around with temporarily yanking the
ethernet cable and other fun tricks.
it 'should' recover from network disconects, like pulling out cable, or
rebooting the target, but I think that this will only work if there is no
major activity - I better test this one again.
it should also flush buffers when you shut down the host, this was a major
pain with the old versions.
Thanks for the Makefiles. Your blurb text incorrectly directs the
reader to run make in sys/dev/iscsi_initiator (which doesn't exist, and
there's no Makefile in sys/dev/iscsi). Obviously you meant
sys/modules/iscsi_initiator. Also, a line about running make in
iscontrol/ would be helpful, as would an install target in that
Makefile.
ok, fixed the 'typos', I also forgot the sample rc.d/iscsi,
Do you have any suggestions on startup integration (rc script, fstab
magic, etc)? I know you said once before that that was hopefully coming
soon..
this is an attempt:
#!/bin/sh
# PROVIDE: iscsi
# REQUIRE: NETWORKING
# BEFORE: DAEMON
# KEYWORD: nojail shutdown
#
# Add the following lines to /etc/rc.conf to enable iscsi:
#
# iscsi_enable=YES
# iscsi_fstab=/etc/fstab.iscsi
. /etc/rc.subr
name=iscsi
rcvar=`set_rcvar`
command=/usr/local/sbin/iscontrol
iscsi_enable=${iscsi_enable:-NO}
iscsi_fstab=${iscsi_fstab:-/etc/fstab.iscsi}
iscsi_exports=${iscsi_exports:-/etc/exports.iscsi}
start_cmd=iscsi_start
faststop_cmp=iscsi_stop
stop_cmd=iscsi_stop
iscsi_wait()
{
dev=$1
trap echo 'wait loop cancelled'; exit 1 2
count=0
while true; do
if [ -c $dev ]; then
break;
fi
if [ $count -eq 0 ]; then
echo -n Waiting for ${dev}': '
fi
count=$((${count} + 1))
if [ $count -eq 6 ]; then
echo ' Failed'
return 0
break
fi
echo -n '.'
sleep 5;
done
echo '.'
return 1
}
iscsi_start()
{
#
# load needed modules
for m in iscsi_initiator geom_label; do
kldstat -qm $m || kldload $m
done
sysctl debug.iscsi=2
#
# start iscontrol for each target
if [ -n ${iscsi_targets} ]; then
for target in ${iscsi_targets}; do
${command} ${rc_flags} -n ${target}
done
fi
if [ -f ${iscsi_fstab} ]; then
while read spec file type opt t1 t2
do
case ${spec} in
\#*|'')
;;
*)
if iscsi_wait ${spec}; then
break;
fi
echo type=$type spec=$spec file=$file
fsck -p ${spec} mount ${spec} ${file}
;;
esac
done ${iscsi_fstab}
fi
if [ -f ${iscsi_exports} ]; then
cat ${iscsi_exports} /etc/exports
#/etc/rc.d/mountd reload does not work, why?
kill -1 `cat /var/run/mountd.pid`
fi
}
iscsi_stop()
{
echo 'iscsi stopping'
while read spec file type opt t1 t2
do
case ${spec} in
\#*|'')
;;
*)
echo iscsi: umount $spec
umount -fv $spec
# and remove from the exports ...
;;
esac
done ${iscsi_fstab}
}
load_rc_config $name
run_rc_command $1
--
problems with the above script:
- no background fsck
- restart will mess the exports file
- the wait loop should be replaced by something more deterministic.
Thanks again. I'll post again if I manage to break something.
Ok, but can't say I look forward to hear from you :-)
danny
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator tester wanted
Quoting Danny Braniss [EMAIL PROTECTED]:
Quoting John Nielsen [EMAIL PROTECTED]:
Do you have any suggestions on startup integration (rc script, fstab
magic, etc)? I know you said once before that that was hopefully coming
soon..
this is an attempt:
A couple comments just from reading through this, see below.
#!/bin/sh
# PROVIDE: iscsi
# REQUIRE: NETWORKING
# BEFORE: DAEMON
# KEYWORD: nojail shutdown
#
# Add the following lines to /etc/rc.conf to enable iscsi:
#
# iscsi_enable=YES
# iscsi_fstab=/etc/fstab.iscsi
The iscsi_exports knob should also be documented here.
. /etc/rc.subr
name=iscsi
rcvar=`set_rcvar`
command=/usr/local/sbin/iscontrol
Assuming this gets commited this will want to be /sbin/iscontrol.
iscsi_enable=${iscsi_enable:-NO}
iscsi_fstab=${iscsi_fstab:-/etc/fstab.iscsi}
iscsi_exports=${iscsi_exports:-/etc/exports.iscsi}
start_cmd=iscsi_start
faststop_cmp=iscsi_stop
stop_cmd=iscsi_stop
iscsi_wait()
{
dev=$1
trap echo 'wait loop cancelled'; exit 1 2
count=0
while true; do
if [ -c $dev ]; then
break;
fi
if [ $count -eq 0 ]; then
echo -n Waiting for ${dev}': '
fi
count=$((${count} + 1))
if [ $count -eq 6 ]; then
echo ' Failed'
return 0
break
fi
echo -n '.'
sleep 5;
done
echo '.'
return 1
}
iscsi_start()
{
#
# load needed modules
for m in iscsi_initiator geom_label; do
kldstat -qm $m || kldload $m
done
Good thinking making geom_label a pseudo-requirement. Examples and
documentation for fstab.iscsi should strongly recommend its use, since
device names will vary.
sysctl debug.iscsi=2
Maybe make this another rc variable that could be set in /etc/rc.conf.
You'll probably also want to change the module's default verbosity
level once it becomes more official.
#
# start iscontrol for each target
if [ -n ${iscsi_targets} ]; then
for target in ${iscsi_targets}; do
${command} ${rc_flags} -n ${target}
done
fi
if [ -f ${iscsi_fstab} ]; then
while read spec file type opt t1 t2
do
case ${spec} in
\#*|'')
;;
*)
if iscsi_wait ${spec}; then
break;
fi
echo type=$type spec=$spec file=$file
fsck -p ${spec} mount ${spec} ${file}
;;
esac
done ${iscsi_fstab}
fi
if [ -f ${iscsi_exports} ]; then
cat ${iscsi_exports} /etc/exports
#/etc/rc.d/mountd reload does not work, why?
kill -1 `cat /var/run/mountd.pid`
fi
}
Look at how Pawel handled this with ZFS (mostly in the zfs and mountd
rc.d scripts), and use the fact that mountd can take multiple exports
files on its command line to your advantage. i.e. appending to the
normal exports file is not really what you want to do.
iscsi_stop()
{
echo 'iscsi stopping'
while read spec file type opt t1 t2
do
case ${spec} in
\#*|'')
;;
*)
echo iscsi: umount $spec
umount -fv $spec
# and remove from the exports ...
See above; this could be a no-op.
;;
esac
done ${iscsi_fstab}
}
load_rc_config $name
run_rc_command $1
--
problems with the above script:
- no background fsck
It would be nice not to re-invent the wheel here, and there are other
reasons it would be nice to just use /etc/fstab instead of adding a new
file -- a number of utilities use /etc/fstab to map between mountpoints
and device names even if the device isn't mounted. Did you try this
approach, and if so what obstacles did you encounter? I will play
around with this if I have time. The late fstab/mount option will
probably be useful here.
- restart will mess the exports file
- the wait loop should be replaced by something more deterministic.
JN
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: Plan to MFC new em driver
I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. I wanted a chance for any concerns to be aired before I did it, issues that anyone has had with the driver in CURRENT? Regards, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: carp patch - will this ever be in releng_6?
On Sat, May 19, 2007 at 04:35:49PM +0300, Stefan Lambrev wrote: S Bruce M. Simpson wrote: S Stefan Lambrev wrote: S S Are there any chances for this: S http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_carp.c.diff?r1=1.46;r2=1.47 S to be MFCed to RELENG_6 before 6.3-release ? S S It fixes quite annoying bug - destroying carpX (when having at least 2 S carp interfaces) will panic immediately. S This bugfix is from 3+ months ago. S S Sadly it is unlikely the failure condition you describe will be fixed in S -STABLE, as resolving it requires far more work to be merged than the link S to the diff you post above. S The attached patch worked for me - it is based on the posted URL. S At least I didn't notice bad effects and it fixes the bug. Bruce misinformes you ;) I've just merged the patch. Thanks for reminder. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
Wesley Shields wrote: The difference is that csup is written in C and included in the base. The only lacking feature in csup is that it doesn't work in checkout mode, which shouldn't be a problem for your average use. You have it backwards. csup _only_ works in checkout mode, what it can't do is mirror a repository. This is fine for the average FreeBSD user however, since checking out the current version of the src or ports tree is what the vast majority do anyway. I may be wrong about checkout mode, but that was a caveat when it went into the tree IIRC. If that is no longer the case I apologize for the misinformation. If you are going to offer advice on the lists, please take the time to verify that what you're saying is correct. Otherwise it's just a waste of time for all concerned. I'm picking on your post here a little because it's a good example of a disturbing trend, please don't take it personally. Regards, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup error
On Wed, Jun 06, 2007 at 10:20:11AM -0700, Doug Barton wrote: Wesley Shields wrote: The difference is that csup is written in C and included in the base. The only lacking feature in csup is that it doesn't work in checkout mode, which shouldn't be a problem for your average use. You have it backwards. csup _only_ works in checkout mode, what it can't do is mirror a repository. This is fine for the average FreeBSD user however, since checking out the current version of the src or ports tree is what the vast majority do anyway. You're right, my apologies. Not working in checkout mode defeats the purpose for the vast majority of the people using it. I guess I just wasn't thinking straight. I may be wrong about checkout mode, but that was a caveat when it went into the tree IIRC. If that is no longer the case I apologize for the misinformation. If you are going to offer advice on the lists, please take the time to verify that what you're saying is correct. Otherwise it's just a waste of time for all concerned. I'm picking on your post here a little because it's a good example of a disturbing trend, please don't take it personally. Don't worry, I'm not taking it personally. It just goes to show that I should think twice and double check things before sending anything. :) Thank you for the clarification. -- WXS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Plan to MFC new em driver
On 6/6/07, David Christensen [EMAIL PROTECTED] wrote: I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. Is something broken with TSO? I just added TSO support to bce on CURRENT and was planning on MFC'ing to RELENG_6 within the next week. TSO support is not present in RELENG_6. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: calcru: runtime went backwards, RELENG_6, SMP
Dmitry Morozovsky wrote: Dear colleagues, on a newly built Supermicro with Pentium D 2.8 (Dual core) with SMP kernel I got zillions of 'runtime went backwards' errors, both on i386 and amd64 kernels. Upd: on GENERIC/amd64 kernel I got the same errors. Do you perhaps run with TSC timecounter? (that's the only cause I've notice that can generate this message). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: HEADS UP: Plan to MFC new em driver
I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. Is something broken with TSO? I just added TSO support to bce on CURRENT and was planning on MFC'ing to RELENG_6 within the next week. Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Plan to MFC new em driver
On 6/6/07, Jack Vogel [EMAIL PROTECTED] wrote: I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. I wanted a chance for any concerns to be aired before I did it, issues that anyone has had with the driver in CURRENT? I think it would be a good idea to have some testing done before the MFC, so I will try and get a driver tarball put together shortly and post that here, I would appreciate any volunteers that could install and 'kick the tires' a bit :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: calcru: runtime went backwards, RELENG_6, SMP
On Wed, 6 Jun 2007, Ivan Voras wrote: IV on a newly built Supermicro with Pentium D 2.8 (Dual core) with SMP kernel IV I got zillions of 'runtime went backwards' errors, both on i386 and amd64 IV kernels. IV IV Upd: on GENERIC/amd64 kernel I got the same errors. IV IV Do you perhaps run with TSC timecounter? (that's the only cause I've notice IV that can generate this message). Nope: [EMAIL PROTECTED]:~ sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.nsetclock: 3 kern.timecounter.ngetmicrotime: 6118 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 463500 kern.timecounter.ngetnanouptime: 1013 kern.timecounter.ngetbinuptime: 3833 kern.timecounter.nmicrotime: 13971 kern.timecounter.nnanotime: 407 kern.timecounter.nbintime: 14378 kern.timecounter.nmicrouptime: 7486 kern.timecounter.nnanouptime: 0 kern.timecounter.nbinuptime: 6194861 kern.timecounter.stepwarnings: 0 kern.timecounter.smp_tsc: 0 Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator tester wanted
Quoting Ivan Voras [EMAIL PROTECTED]: Danny Braniss wrote: I'm in the last mile before crossing the beta-release line, so I'd like to get some input, and update the list of targets it supports. you can obtain the driver from: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.0.92.tar.gz I think I can test in on our SAN but the only machine attached to it runs 6-STABLE. Will your iSCSI intiator work in -STABLE? This is actually the first snapshot of the initiator that I've tried that works on -CURRENT. Previous ones have always worked on -STABLE and I don't see any reason that this one wouldn't. Also, do you plan to finish it in time to get it included in 7.0? I can't comment on that, but I agree it would be nice.. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: calcru: runtime went backwards, RELENG_6, SMP
:IV Upd: on GENERIC/amd64 kernel I got the same errors. :IV :IV Do you perhaps run with TSC timecounter? (that's the only cause I've notice :IV that can generate this message). : :Nope: : :[EMAIL PROTECTED]:~ sysctl kern.timecounter :kern.timecounter.tick: 1 :kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) :kern.timecounter.hardware: ACPI-fast :... kgdb your live kernel and 'print cpu_ticks'. See what the cpu ticker is actually pointing at, because it might not be the time counter. It could still be TSC. The TSC isn't synchronized between the cores on a SMP box, not even on multi-core parts. It can't be used to calculate delta times for any thread that has the possibility of migrating between cpu's. Not only will the absolute offset be off between cpus, but the frequency will also be slightly different (at least on SMP multi-core parts), so you get frequency drift too. There is also possibly an issue with tc_cpu_ticks(), which seems to be using a static 64 bit variable to handle rollover instead of a per-cpu variable. I don't see how that could possibly be MP safe, especially if the timecount is not synchronized between cpus and causes multiple rollover events. In fact, I can *barely* use the TSC on DragonFly for KTR logging, and even then I have to have some kernel threads sitting there doing nothing but figuring out the drift between the cpus so it can correct the TSC values when it logs information... and even with all of that I can't get them synchronized any closer then around 500ns from each other. I'd recommend that FreeBSD do what we did years ago with calcru ... stop trying to calculate the time down to the nanosecond and just do it statistically. It works just fine and takes the whole mess out of the critical path. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Western Digital MyBook 250GB USB takes *really* long to be recognized
Hiho! ;-) I just bought a Western Digital MyBook 250GB external USB 2.0 drive and I stumbled upon the problem mentioned in: kern/107495: Fix long wait before WD My Book 250GB (USB) is recognized There's a patch attached to that PR, which I applied, but it didn't help. FreeBSD version is FreeBSD ubm.mine.nu 6.2-STABLE FreeBSD 6.2-STABLE 4: Wed Jun 6 19:58:12 CEST 2007 Symptoms are as follows: when I plug the drive in, it is immediately recognized by umass as: umass0: Western Digital External HDD, rev 2.00/1.08, addr 2 About 10 to 15 minutes later, cam kicks in and recognizes it as: da0 at umass-sim0 bus 0 target 0 lun 0 da0: WD 2500BB External 0108 Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) From that point onwards, everything works fine, I just finished rsyncing my entire home directory (about 40gb) to the disk with ehci enabled. I'm just curious if there is anything to be done about the long delay? (not that I care that much, drive is attached to my server, so it won't be unplugged or be turned off very soon :-)) Thanks in advance! :-) Bye Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI hanging shutdown
Hi all, Sometime between the beginning of April and May 14(?) there appears to have been a change in ACPI which is causing my IBM R51 to hang when shutting down. I see syslog exit and then nothing. I need to do a hard shutdown with the partitions still mounted for it to turn off. I booted without ACPI and the problem has gone away. Successive updates have not solved this. Anyone know what could be causing this? Thanks. tom dmesg with ACPI: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Mon Jun 4 19:46:26 EDT 2007 root@:/usr/obj/usr/src/sys/GENERIC_ULE Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1500MHz (1498.74-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE Features2=0x180EST,TM2 real memory = 1073020928 (1023 MB) avail memory = 1041027072 (992 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: IBM TP-1R on motherboard acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82855 host to AGP bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801DB (ICH4) USB controller USB-A 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: Intel 82801DB (ICH4) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801DB (ICH4) USB controller USB-B 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 uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xc000-0xc3ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: Intel 82801DB/L/M (ICH4) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 cbb0: PCI-CardBus Bridge mem 0xb000-0xbfff irq 11 at device 0.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 fwohci0: 1394 Open Host Controller Interface mem 0xc0215000-0xc02157ff,0xc021-0xc0213fff irq 11 at device 0.2 on pci2 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:06:1b:03:24:02:2a:68 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:06:1b:02:2a:68 fwe0: Ethernet address: 02:06:1b:02:2a:68 fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x8000-0x803f mem 0xc022-0xc023,0xc020-0xc020 irq 11 at device 1.0 on pci2 em0: Ethernet address: 00:11:25:85:e4:fc iwi0: Intel(R) PRO/Wireless 2200BG mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 iwi0: Ethernet address: 00:12:f0:00:ae:1e isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) pcm0: Intel
Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
After that I try to read/list the tar from tape with tar -t: $ sudo tar -tf /dev/sa0 archive.dmp tar: Unrecognized archive format: Inappropriate file type or format But when I extract the archive from tape, it works perfectly: $ sudo tar -xvf /dev/sa0 Using dd to feed tar does work though. (I think this agrees with Robin's findings although the fact that it works with -z is curious) This is a Tandberg TS400 (LTO2 drive, LTO1 tape) idd, same problem here. When using -z option, works perfectly. Without it, it fails. Our tapedrive is a HP C7438A V312. (DAT) Please try the following: sudo ktrace tar -tf /dev/sa0 Then run 'kdump | less' and see if you can find a pair of 'lseek' calls, which will probably look something like this: 53127 bsdtar CALL lseek(0x3,0,0,0,0x1) 53127 bsdtar RET lseek 6656000/0x659000 53127 bsdtar CALL lseek(0x3,0,0x70800,0,0x1) 53127 bsdtar RET lseek 7116800/0x6c9800 Note: The third argument is the amount to seek; the return value is the new offset. This sequence (first seek '0' to get the current offset, then seek by more than zero) is how tar asks the driver if it supports seeking. This example is reading from a disk file, so the file offset does change; the seek worked. I believe you'll find that the SCSI tape driver in 6.2 lies: It does not actually seek, but the two lseek calls return different values. As a result, tar believes that the body of the tar entry has been skipped when it hasn't. This doesn't occur with tar from 6.1 because the seek optimization was added after that; it doesn't happen with compressed archives because you cannot seek in compressed files. I believe the right fix is to get the driver fixed. If it does not seek, it shouldn't claim that it does. A bad hack is to break the file_skip() function in libarchive/archive_read_open_filename.c, as below: Index: lib/libarchive/archive_read_open_filename.c === --- lib/libarchive/archive_read_open_filename.c(revision 124) +++ lib/libarchive/archive_read_open_filename.c(working copy) @@ -165,6 +165,8 @@ struct read_file_data *mine = (struct read_file_data *)client_data; off_t old_offset, new_offset; + return (0); + /* Reduce request to the next smallest multiple of block_size */ request = (request / mine-block_size) * mine-block_size; /* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
This morning I have revert libarchive (src/lib/libarchive) and tar (src/usr.bin/tar) back to RELENG_6_1 and surprisingly (or maybe not) it works fine now. After that I try to read/list the tar from tape with tar -t: $ sudo tar -tf /dev/sa0 archive.dmp tar: Unrecognized archive format: Inappropriate file type or format But when I extract the archive from tape, it works perfectly: $ sudo tar -xvf /dev/sa0 x archive.dmp What SCSI controller are you using? This could conceivably be an issue with a particular SCSI controller. A few lines from 'dmesg' could help here. If I must, I suppose I could make 'tar' never try to seek if it's talking directly to a device. That would penalize devices that can seek, so I'd rather find an alternate solution. Tim Kientzle P.S. In the meantime, of course, tar from 6.1 and gtar should both work in this situation. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
